On 08/19/2014 03:24 PM, Alexander Larsson wrote:
> On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote:
>> On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
>>> Because every time we try to clean up GtkTreeView, we break some random
>>> application. It's a widget that has twenty th
On Tue, Aug 19, 2014 at 6:52 AM, Emmanuele Bassi wrote:
> hi;
>
> On 18 August 2014 19:09, Paul Davis wrote:
>
> > On Mon, Aug 18, 2014 at 1:55 PM, Emmanuele Bassi
> wrote:
> > [ .. ]
> >
> > realistically, by comparison with other platforms and with many
> home-grown
> > GUI toolkits, there's
On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote:
> On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
> > Because every time we try to clean up GtkTreeView, we break some random
> > application. It's a widget that has twenty three gazillion use cases, and
> > so we have to keep i
hi;
On 18 August 2014 19:09, Paul Davis wrote:
> On Mon, Aug 18, 2014 at 1:55 PM, Emmanuele Bassi wrote:
> [ .. ]
>
> realistically, by comparison with other platforms and with many home-grown
> GUI toolkits, there's really only one sane design for any toolkit in 2014:
>
>* recursively nest
hi;
On 18 August 2014 19:49, Colomban Wendling wrote:
> Hi,
>
> Le 18/08/2014 19:55, Emmanuele Bassi a écrit :
>> [...]
>>
>> when we introduced GL in the pipeline through the compositor 5 years
>> ago, stuff that was 5 years old *at the time* already could run
>> decently.
>
> Not completely, no
I hope I can still run gtk 4 applications on a virtual machine in the cloud
somewhere that can present its display in a X server on my local
machine--the VM probably would run Red Hat Linux or CentOS, and its can
present a GNOME desktop via VNC in the fallback mode, or GNOME terminal via
Xpra
This
Hi,
Le 18/08/2014 19:55, Emmanuele Bassi a écrit :
> [...]
>
> when we introduced GL in the pipeline through the compositor 5 years
> ago, stuff that was 5 years old *at the time* already could run
> decently.
Not completely, no. I had (and still have) a really decent '07 card
(non-integrated 6
On Mon, Aug 18, 2014 at 1:55 PM, Emmanuele Bassi wrote:
[ .. ]
realistically, by comparison with other platforms and with many home-grown
GUI toolkits, there's really only one sane design for any toolkit in 2014:
* recursively nested objects with a common "draw" virtual method that
renders on
On 18 August 2014 18:32, Andy Tai wrote:
> Would this new layer have performance implications? On older computers that
> would not be GPU accelerated
what "older computers" are we talking about? 10 years old? unsupported
GPUs with no drivers?
when we introduced GL in the pipeline through the co
Would this new layer have performance implications? On older computers
that would not be GPU accelerated, would gtk 4 still work using CPU
rendering, and with comparable performance to gtk+3 (or better, gtk+ 2)?
On Mon, Aug 18, 2014 at 2:00 AM, Emmanuele Bassi wrote:
___
On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
> Because every time we try to clean up GtkTreeView, we break some random
> application. It's a widget that has twenty three gazillion use cases, and
> so we have to keep it a mess, because removing the mess means removing one
> use case,
On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet wrote:
> On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
> > On 16 August 2014 16:23, Sébastien Wilmet wrote:
> >
> > > With GskLayerContent, will it be possible to unify cell renderer and
> > > widget drawing models? To simplify signif
On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
> On 16 August 2014 16:23, Sébastien Wilmet wrote:
>
> > With GskLayerContent, will it be possible to unify cell renderer and
> > widget drawing models? To simplify significantly the GtkTreeView
> > implementation, for example, and be able
hi;
On 16 August 2014 16:23, Sébastien Wilmet wrote:
> With GskLayerContent, will it be possible to unify cell renderer and
> widget drawing models? To simplify significantly the GtkTreeView
> implementation, for example, and be able to insert a GtkWidget in a
> GtkTreeView.
not without breakin
Hi,
Another question.
With GskLayerContent, will it be possible to unify cell renderer and
widget drawing models? To simplify significantly the GtkTreeView
implementation, for example, and be able to insert a GtkWidget in a
GtkTreeView.
See: https://bugzilla.gnome.org/show_bug.cgi?id=619017
Reg
On Sun, Aug 3, 2014 at 6:08 AM, Sébastien Wilmet wrote:
> Thanks for the explanation.
>
> On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
> >
>
> > yes, it was considered, and no: "depth" (or similar terms) won't be used.
> >
> > people using a canvas with 3D transformations intuitivel
hi;
On 3 August 2014 11:08, Sébastien Wilmet wrote:
> Thanks for the explanation.
>
> On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
>>
>
>> yes, it was considered, and no: "depth" (or similar terms) won't be used.
>>
>> people using a canvas with 3D transformations intuitively grasp
Thanks for the explanation.
On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
>
> yes, it was considered, and no: "depth" (or similar terms) won't be used.
>
> people using a canvas with 3D transformations intuitively grasp the
> concept of a Z axis, as well as that of a coordinate on t
hi;
On 2 August 2014 22:14, Sébastien Wilmet wrote:
> Hi,
>
> Some questions about the GTK+ scene graph ([1]).
>
> Why not reusing the height-for-width and width-for-height sizing
> requisition type? Will it Just Work with the constraint-based layouts?
first of all, GSK sit
Hi,
Some questions about the GTK+ scene graph ([1]).
Why not reusing the height-for-width and width-for-height sizing
requisition type? Will it Just Work with the constraint-based layouts?
For functions like gsk_layer_set_z_position() having 'z' in the name,
have you considered naming
20 matches
Mail list logo
