Re: 2.3 Proposed Features

[Malcolm Tredinnick <malcolm commsecure com au>]

This gets more distressing the longer it goes on. It sounds like people
want to make GTK+ the top of the dependency chain, at which point it
loses its benefit as a lightweight (well, medium- to heavyweight)
library on which more advanced widgets can be built (e.g. libgnomeui)
for specialised situations.  Still, I expect to be shouted down on this
point, so let's get to the real problem...

On Tue, Feb 04, 2003 at 01:05:13PM -0500, Havoc Pennington wrote:
[...]
> I don't believe that. libgnomeui can be realistically deprecated by
> GTK 2.6. Once we do menu/toolbar API, the remainder of libgnomeui
> worth caring about is trivial to move (icon themes, session
> management, and some way to display help). I have a plan for kicking
> gconf below the GTK level, and even failing that we have a way to
> proxy gconf settings to gtk-only apps that we are already using in
> places.

If you're going to argue (as you seem to do later) that there should be
One True Widget Library, then make it just that -- only a widget
library. Why does GTK+ need to have a dependency on gconf at all? Surely
they are orthogonal. Just as gnome-vfs is orthogonal to both of them. I
must be missing something here.

> The only real unresolved issue is gnome-vfs, which is quite hard to
> get on the right level of the dependency stack, and would be a
> nightmare to try to standardize with KDE.  gnome-vfs has lots of loose
> semantics, and kioslave even looser, and they're both heavily bound up
> with file manager internals. But thankfully all the core libs need it
> for is the filesel, and we can make that work.

There has previously been discussions about making the file selector
pluggable in some way so that it can use whatever backends and
configurations systems are available. This makes sense; it
again keeps the dependencies low and keeps things flexible. Having to
supply a method which is used to retrieve the files is not really a pain
when creating the file selector. Then you can have a sensible
libgnomeui-like library that wraps it at the GNOME level to provide a
gconf + gnome-vfs + GTK implementation. KDE can have their own wrapper
and so on.

Trying to solve every problem in one library just leads to the "but our
web browser is part of our operating system, your Honour" line of
reasoning.

> libgnomeui had some value for encouraging innovation when it was more
> prototype-like but we put it in the platform, and in the platform it's
> just bloat and confusing.

Make it a wrapper library for pulling together other libraries for
top-level GNOME stuff (a la the file selector scenario above). Don't
force _everything_ to be GNOME-like right down at the GTK level. If you
do that, you remove the possibility of using GTK in lighter-weight
scenarios, along with essentially making everything compulsory just to
get a couple of widgets.

And don't remove the ability to be GNOME-like just because you suddenly
want things to work with KDE. Cross-desktop specifications is nice;
compulsory "one-ness" is going to be terrible. Of course, one of the
paragraphs I have deleted claims there is nothing "GNOME-like" left at
this point. I would say that using gnome-vfs + gconf + gtk + libgnome
makes it GNOME-like. If I want to use KDE's underlying libraries and
their widget set, then it becomes KDE-like. Similarly, if I want to add
wxWindows' widget set in, I get something else.

[...]
> > Shortening the GTK release cycle and syncing it up with the GNOME
> > release is even better than that.
> 
> You may be right here.

Another drawback of pushing everything down to one level -- you
completely lose the possibility to do incremental releases of small
components. Suddenly the entire release blocks on GTK (or some other
library). In the past, you have had problems getting everybody to agree
on single release points, which is why GTK is on a different schedule
(and I think that the current situation is entirely appropriate). But
when it all comes down to GNOME being only three or four libraries, the
liklihood of having a few more libegg style libraries to get around some
blockages will be increased.

[Unfortunately, I expect at least some replies to this will be along the
lines of "but we shouldn't require or permit flexibility, we should just
get it right". Needless to say, I still don't subscribe to that school
of thought.]

Malcolm

-- 
The hardness of butter is directly proportional to the softness of
the bread.