Re: Order of widgets when displayed on top of each other

[Paul Davis <paul linuxaudiosystems com>]

>> From: J. Davison de St. Germain [mailto:dav cs utah edu] 
>> > use the GnomeCanvas, which has z-order stacking. its not so cool for
>> > widgets as it it for native canvas items, but it will work.
>> 
>> My understanding is that this would require us to be dependent on yet
>> another library (libgnome? or some such) and to learn another API.
>
>libgnomecanvas. It's a small API-stable library.

and to expand: it was once part of libgnomeui, but it has since been
split off into its own library that has no dependencies other than
those that GTK+ itself has. its really just politics and/or inertia
that makes it GnomeCanvas and not GtkCanvas at this point.

(as a parenthetical note, i find it rather sad how few new widgets
have been incorporated into GTK+ over the years it has been around. i
don't think i have seen a single example of a new widget entering the
toolkit in the 4+ years i've worked with it.)

>However, libgnomecanvas is less than perfect (see the archivs). There are
>other canvases that you might use instead, such as foocanvas.

and indeed, the main distinction between foocanvas and gnomecanvas is
that the latter includes support for an "antialiased mode", in which
the primary purpose is to do alpha-blended, z-stacked rendering of
non-widgets. the foocanvas ripped the whole alpha rendering part out,
and is just for stacking non-alpha'ed objects, with slightly more of
an emphasis on widgets.

>> Is the lack of z-order stacking for GTK widgets a bug,
>
>I think GTK+ is really for providing widgets, and I can't see a need to have
>one button half-way overlapping another button.

and indeed, owen has confirmed that the design of GTK+ includes a
fairly central assumption that widgets do not overlap within
containers, although you can (as you've probably seen) make this
happen without terrible consequences, most of the time.

>> or a known issue, or something that the only fix is to use the Gnome
>> canvas?  I assume that implementor of the Gnome canvas somehow "worked
>> around" the GTK problem.
>
>I think the canvas is meant to solve a different set of problems.

AFAIK, the canvas was meant to solve (1) the stacking problem (2) the
motion problem and (3) originally, alpha-blending.

--p