[gtk-list] Re: _foreach behaviour (was: Re: known bug still

[Patrice Fortier <Patrice Fortier aquarel fr>]

> > >   The gtk_scrolled_window_foreach function is buggy. It only does
> > > one third of its job:
> > > calling this function only send the callback to the viewport widget,
> > > and not to the scrollbars.
> > > What's the need of a foreach function if you don't send the callback
> > > for each widget in this widget???
> > 
> > It is used to provide the default method of doing many things
> > for container widgets. I'm not sure if we want to make the
> > _default_ method required to be the only method.
> > 
> > For instance, one consequence of your patch is that if you
> > gtk_widget_set_sensitive(...,FALSE) a ScrolledWindow, you not only
> > make all its children insensitive, you also make the window
> > non-scrollable. That might be the correct behavior, but the 
> > current behavior is also somewhat useful.

This _is_ the correct behaviour.

If I make the widget insensitive, I don't want that the user can
toy with it as if it was sensitive :).

<snip>

> > The natural question is, what other default actions are affected:
> > 
> >  show/hide_all: 
> [...]
> 
> i think the point merely is (at least for Patrice and me) that there
> shopuld be a mechanism to iterate through *all* widgets of a tree
> (that is needed by GUI bulders as well).

The standard user expects that this function is *_foreach().
At least, this is what I did :).


> > The other widget that would be affected (CList already does
> > things the way your want them), is the Notebook widget. It
> > exhibits the unparenting problem, and also doesn't show
> > its tabs as disabled when it is made insensitive.
> 
> which is "the right thing", imho. having scrollbars enabled when
> the scrolledwindow is really insensitive is a *special feature*
> that should also be possible to be disabled.
> 
> > I think there are really three questions
> > 
> >  - Should the ScrolledWindow's foreach() do the scrollbars?
> >  
> >  - Should the Notebook's foreach do the tabs? (Only problem
> >    I see with this is that exisiting code may well be
> >    using gtk_container_foreach() to iterate over the pages
> >    of a notebook)
> > 
> >  - Should every container widget have to include foreach()
> >    in all of its children.
> > 
> >    Advantage: makes things simpler, less chance of hidden bugs.
> > 
> >    Disadvantage:
> >      If this is done, there will be _no_ way to do things like 
> >      a ScrolledWindow that allows its area to be scrolled when 
> >      not sensitive.
> 
> that could be worked around by connecting to GtkWidget::state_changed of
> the scrolled window and providing
> void gtk_scrolled_window_keep_sensitive_scrollbars(, boolean-value);
> or something the like (i'm not too good at inventing function names, you know;)

Or simply call the set_sensitive function with the viewport (the
child of scrolled_window)? :)

> >      (Imagine a CList with some cells containing embedded 
> >       widgets)
> > 
> >      Yes, this functionality could be separated out, but that
> >      would require either:
> > 
> >       - Specific functions on a widget-by-widget basis (bad
> >         when you consider the _full variant of foreach(), which
> >         is used by language bindings)

A function that's applied only to the entries like
gtk_clist_foreach_entry() sounds to be an intuitive solution.

> >       - Modifiying the foreach signal
> >     
> >       - Creating a whole new signal "foreach_user".

Ripping away the scrollbars from clist so we don't have to problem
anymore.:)

> > So, not to make a mountain out of a molehill, but some more
> > explainaition why I didn't just go ahead and apply the patch.  Yes, it
> > does fix some (fairly rare) bugs, but it also raises some non-trivial
> > issues.
> > 
> > Regards,
> >                                         Owen
> > 
> 
> ---
> ciaoTJ


Patrice.