Re: [gtk-list] map/unmap optimization



On Mon, 20 Jul 1998, Patrice Fortier wrote:

> 
> After some months I'd at last some time to look back at the 
> gtk sources.
> And each time I see a *_map or *_unmap function I wonder if
> there is a difference between the gtk_*_(un)map and the X
> (un)map calls.
> 
> A big advantage of the X (un)map calls is that they can handle
> the subwindows map/unmap.
> For example to unmap a container widget with other widgets inside
> you just make a call to XUnmap (or whatever) and it unmaps your
> container (handling the children). Want to remap it?
> Just call Xmap (or whatever bis :)), and it remaps your widget
> with its children mapped, if they were already mapped before
> the unmap call.
> 
> In the gtk container unmap functions we _explicitly_ unmap
> the children too. Why?
> Is there a special reason not to use the X features and 
> duplicate the work?
> 
> 
> BTW, I sent a patch to gimp.org for the dev tree (1.1?) to add
> a widget->window to the *frame widgets, as these widgets
> are drwing in their parent window (which can not be considered
> a good thing, IMHO).

why not? there are two type of widgets wrt the windows the use:
widgets that don't need an own xwindow i.e. NO_WINDOW widgets like
GtkArrow or GtkBox, and the widgets that introduce at least one
own x/gdk window i.e. GTK_WIDEGT_NO_WINDOW(widget)==FALSE.
GtkFrame is a NU_WINDOW widget, and thus it is supposed to draw
into its parent's window. also it needs to unmap its child if
itself gets unmapped, because its child might be a !NO_WINDOW
widget.

> 
> 
> Patrice.
> 

---
ciaoTJ



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]