Re: [gtk-list] map/unmap optimization
- From: Tim Janik <timj gtk org>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] map/unmap optimization
- Date: Mon, 20 Jul 1998 22:25:02 +0200 (CEST)
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]