Re: [Gal-hackers] Re: [Nautilus-list] Re: What about gal && eel into GNOME 2.0?

[Havoc Pennington <hp redhat com>]

Ettore Perazzoli <ettore ximian com> writes: 
>   I didn't mean to attack the GTK maintainers here.  I just wanted to
> express a personal feeling.

Certainly, I don't want to take it as an attack. I just want to
address the issue.

>   I think a big part of the problem is that too many things were changed
> from 1.2 to 2.0 and it became impossible to add widgets to GTK for a
> long time, because of the migration to 2.0.  And while the GTK
> maintainers kinda lived in a happy 2.0-only world and rejected any
> non-trivial changes to 1.2, application developers had to write their
> own widgets and work around the various problems of 1.2 all by
> themselves.

Right. So a reasonable solution to that might have been a 1.4 that
just added widgets to 1.2, similar to the 2.2 we are planning. I think
1.4 didn't exist simply because there were higher priorities and lack
of time.

I think GAL, eel, etc. were decent solutions as well, though.

>   Now, it still looks like the barrier for getting widgets into 2.0 is
> pretty high, though.  For one, I proposed getting GnomeDock into GTK 2 a
> long while ago, when 2.0 was just started, and it was rejected.  In all
> the time that has passed since then, we could have ported GnomeDock to
> GTK 2 and ironed out all the rough edges.  Likewise with the color combo
> box.

I can give you the rationale for these two. Both are in fact high
priorities for 2.2, and we didn't really want to punt them, but we had
to punt something.

For GnomeDock, we want to come up with a unified solution for:

 - an "app" toplevel (GnomeApp)
 - menubar that properly handles out-of-space
 - toolbar that does same, and has non-sucky API
 - menu/toolbar convenience API (like itemfactory, app-helper)
 - dock widget that works with those
 - MDI with menu merge stuff
 - integration with statusbar

this stuff is all interrelated; adding GnomeDock would potentially be
wrong, and leave us with a deprecated widget. So we punted this whole
block of changes to 2.2, to be handled as a whole.

I don't remember what rationale if any was given at the time you
suggested GnomeDock, if it wasn't this one then I apologize.

For color combo. We actually had Kristian kindly working on
integrating this, but decided to postpone to 2.2.

Basically we want to have the difference between combo and option menu
be a function of the theme, so in a Windows theme all option menus
have that combo look.

This means in essence that the GAL combo widget is entirely the wrong
thing, because it exposes all sorts of implementation child widgets
much as current GtkCombo does, while we want to leave that up to the
theme.

The use-cases we've seen for the GAL color combo could mostly be
addressed with an API that allowed simply pixtext in the combo, and a
way to toggle "tabular" format vs. "list" - one approach to this is to
just make GtkMenu allow table layouts, since people often want e.g. a
tabular submenu of colors in their menus as well as in a combo.

This works for e.g. Gnumeric formats, the color combo, and also all
current uses of option menu and GtkCombo. (Note that there'd be a
concept of an "editable" flag that would give you the text entry as
with GtkCombo.)

Anyway, it's possible that use-cases such as the funny button in the
Gnumeric combo are important, and this design wouldn't work for
that. But we could maybe sort out a way to handle it. 

In any case the issue isn't closed and is still up for discussion, but
we didn't think we could get it right with available hackers for GTK
2. Since one of the big goals we had was to get rid of the stupidity
of having some people use GtkCombo and some use GtkOptionMenu for
choosing an option from a list.

This is pretty similar to the GnomeDock situation; the combo widget
needs to be designed/revised in light of a bigger picture, which is
cleaning up GtkOptionMenu and GtkCombo and maybe merging those. There
wasn't really time to do this before GTK 2 by the time we had someone
to work on it.

Anyhow, I think in both of these cases basically we postponed them
because there are reasonable-working solutions available for the short
term, either in GTK or other libraries, and when replacing stuff that
already works reasonably well it's worth going slow and getting it
more correct. Whereas an emergency situation may justify putting in a
crappy stopgap widget (e.g. GtkCList was probably a good idea for 1.2,
even though it wasn't very good in retrospect, because otherwise we
would have lacked really crucial functionality).

2.2 development should start soon and then we can really hash out how
to do these widgets and get them in CVS.
 
>   I still think the shortcut bar makes sense as a general-purpose
> widget, but maybe it's just me.

Maybe it does, I haven't thought about it in too much detail.

> > Anyhow, I would genuinely like to make GTK more open to contributed
> > widgets. What do you think of the idea of doing 2.2 as a
> > "libgtk-prototypes" library that would have less strict review
> > requirements before putting things in, and that people could start
> > using with GTK 2.0? Would that help with this problem?
> 
>   I like this idea.
> 

I hope we can do this, I think it'd be a nice approach, and help keep
the 2.2 release cycle pretty short.

Havoc