Re: [gtk-list] Re: allocate/requisition handling

[Tim Janik <timj gtk org>]

On Wed, 23 Feb 2000, John Cupitt wrote:

> Havoc Pennington wrote:
> > John Cupitt <john.cupitt@ng-london.org.uk> writes:
> > > As far as I can see, I need to be able to refuse an allocation (I have
> > > more items than I can fit in), and make another requisition (I'll accept
> > > that width, but can I have more height please). 
> > 
> > It doesn't have this unless the container supports it. For example the
> > scrolled window container will sometimes give the child a second
> > allocation. So you could do some sort of custom container.
> 
> Hi, thanks for the reply ... I've made a version of gtkmenubar that
> wraps, by calling gtk_container_queue_resize( self ) inside the
> size_allocate method. Working out the geometry almost made my head
> explode :/

gtk_container_queue_resize() is an internal function, never use it directly.
instead, you either want gtk_widget_queue_resize (menu_bar->child) (this
pretty much amounts to gtk_container_queue_resize (menu_bar)) or
gtk_widget_queue_resize (menu_bar);

> It flickers like mad (my fault), but it does seem to work. Is this the
> approved technique, or is there a safer call?

i've got to have a look at your code to actually figure your exact needs.
the general rule of thumb is, always queue the resize on the widget that
actually changed, not its parents.
i.e. a GtkHBox would, when a new child is added to it, do
gtk_widget_queue_resize (new_child), instead of
gtk_widget_queue_resize (hbox), since resizing of the hbox will automatically
be taken into account when processing the resize needs of new_child.

how do you handle right justified menu items with the wrapping code btw?
(though there actually can only be *one* right justified item currently,
regardless of its visibility state even, another thing that needs fixing
with the menu code.)

> 
> John
> 

---
ciaoTJ