Re: none

[Owen Taylor <otaylor redhat com>]

Patrice Fortier <Patrice.Fortier@aquarel.fr> writes:

> This patch is for the develpment tree and was made against the 1.0.4
> version.
> 
> This patch replace all the NO_WINDOW container widgets with window
> widgets. It also removes some code duplication in the window that
> already had a window.
> Note that it includes the patch I sent a few days ago where I did
> the same thing with the *frame widgets.

Hi Patrice,

Thanks for the patch. However, I have to say, that I don't
think this is the direction we want to go, at least in the
near future.

First, I haven't been convinced that there is any real benefit
in such a change, except for the elimination of a bit of
complexity that we already have the code to handle, and this
idea that there is something inelegant about NO_WINDOW
widgets.

But, more concretely, this is going in exactly the opposite
direction from raster's work on theming. The crucial concept
is "transparency". The user perceives some areas of some
widgets as being transparent. Examples of such widgets
are the Label, RadioButton and Frame widgets. 

There are three ways of achieving transparency:

 - Use a shaped window. This works pretty well when the window 
   has a simple shape, but, because of the way X handles shapes,
   is horribly inefficient when you have something like text
   drawn on a "transparent" background. (Like the Frame widget)

 - Use a parent-relative backing pixmap. This is OK in some
   circumstances, but only when the child widget is on top
   of the parent's background. This is not always the case -
   for an example, look at the tabs on a notebook. With themes,
   examples of widgets having backgrounds that are neither
   backing pixmaps nor solid background colors will multiply.

 - Draw on the parent window.

So NO_WINDOW widgets are from this standpoint, a good thing.
In fact, the RadioButton widget is probably going to require
an extension of the concept to widgets that have a window,
yet draw on their parent's background as well.

(There are two different ways I can think of doing this:

 1) A flag PARENT_DRAW, that tell's GTK that a widget with
    a window draws on its parent's window as well.
 
 2) A flag NO_REPARENT, that tell's GTK+ that a NO_WINDOW
    widget should be reparented by unrealizing and realizing
    it again. This should allow a NO_WINDOW widget with
    subwindows to work correctly.

 The first is a bit cleaner, but doesn't handle widgets
 that want to have multiple non-nested windows and draw
 on their parent's window as well. The second is simpler
 to implement and handles that case, but sort of ugly)

I hope the above hasn't horrified you too much. ;-)

Regards,
                              Owen