[gtk-list] Re: Widgets Vs Gadgets (Was : map/unmap optimization)

[Patrice Fortier <Patrice Fortier aquarel fr>]

> OK Guys - here's my humble opinion :
> 
> Why have Gadgets at all ?

[a lot of things I agree with]

> So - Does anyone out there have any hard figures comparing widgets and
> gadgets -  I would be interested to know.

There was a couple of tests made with list and clist with a _lot_ of
children. But I really don't know if the list widget is efficient and/or
optimized.

I'd be interesred by tests with "normal" widgets too :)


> If Gadgets do prove to be lighter in certain situations (I think in Motif the
>  idea was to use them in menus),

This was the case for motif, athena & co some years ago, but I don't think
the problem comes from the menu. The number of entries in a menu is not
that large (usually < 100). Anyway, as far as I remember the menu items
are widgets, not gadgets (I'm not at home, so I can hardly check this).

The problem may occur with widgets with a huge amount of children, like
clist (or even ctree?), which can have +10.000 entries.
But I think there are few cases like these (and I hope so, for my 
computer memory :)).

>  then my solution would be for those widgets
>  involved to dynamically chose whether or not to use a window (perhaps the
>  programmer could supply a hint before initial realisation), but revert to using
>  windows as soon as e.g. enter/leave signal handlers where attached, or e.g.
>  their background colour became different from their parents.

How would you change this dynamically? I'm not really sure that when
the widget is realized it already knows its resources or its future 
behaviours...
At least the programmer do know this (but may not know how to implement
it efficiently) :).


Regards,
Patrice.