Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Wed, Feb 05, 2003 at 11:23:45AM +1100, Malcolm Tredinnick wrote:
> 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...

I don't think you're understanding what I'm proposing. I may not be
explaining it enough, since it's an old discussion we've had many
times in the past.

What GTK should be is a GUI toolkit that contains the things most apps
will need to use. It isn't going the Qt route; it doesn't and won't
contain a database API, and data-aware widgets, and tons of other
things that are special-purpose. Those should stay separate.
 
> 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.

GTK dependencies on son-of-gconf/gnome-vfs would almost surely be
runtime-optional rather than a linktime dependency. But even if they
are hard dependencies, son-of-gconf/gnome-vfs would not be in the gtk+
tarball, they would be separate packages.

It makes some sense to have a libgnomeui that simply glues other
libraries together, for example, provides the gnome-vfs backend for
the GTK filesel, and provides the gconf plugin for the GTK "get
settings" vtable, or whatever. If libgnomeui just does that it will
just be an init() function and little else. That would be fine, though
in general I don't think it's necessary if we design the code
properly.
 
> 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.

You don't want to do it with wrappers; you want to do it with runtime
modules. Because then you have a single API, vs. two APIs that share
some implementation.

> 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.

No. GTK has clearly defined scope, which is to provide the GUI
toolkit.  Other things go in other libraries. For example font
configuration is in fontconfig, font rendering in Xft, general utility
stuff in GLib, i18n text layout in Pango, configuration in GConf, and
so on.

The whole reason libgnomeui sucks and has always sucked is that it
doesn't have a clearly defined functional scope. It has always been a
dumping ground defined by accidents of module dependencies. Go back 2
years in the archives and you'll find me saying exactly the same
thing.

Incidentally, if you want to be competitive: we can do much better
than KDE here. They duplicate Qt on a massive scale. We copied this in
GNOME 1.x but mostly cleaned it up in GNOME 2.0.

> Make it a wrapper library for pulling together other libraries for
> top-level GNOME stuff (a la the file selector scenario above).

That's a fine goal for it, it leads to libgnomeui just being an init()
function, and that's fine. But other than gnome-vfs I don't expect
there will be a lot to pull together that isn't already pulled, and in
most cases an init() function should not even be needed.  A config
file causing GTK to load certain modules should be enough.
 
> And don't remove the ability to be GNOME-like just because you suddenly
> want things to work with KDE.

"suddenly"? Read a few years of archives. I started freedesktop.org in
March 2000.

> 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.

If you want to have gratuitous library bloat just so you have a tribal
flag to rally around, then go ahead, but it sounds pretty silly to
me. ;-) Perhaps I don't understand what you mean.

We are not unifying GTK/Qt/wxWindows. The desktop standards are on the
level of file formats etc., i.e. sharing backends that aren't user
visible.

"GNOME-like" should never be about which libraries you link to. 
If so, GnuCash is the ultimate GNOME application, since it uses the
most libraries.

"GNOME-like" IMHO should be about whether you follow the HIG and have
a good UI design.  And there's no reason GTK+ can't support an app
that does that.

> Another drawback of pushing everything down to one level 

Not one level. Just the same number of levels we have already, but in
the proper dependency order.

"GTK" in this conversation has been sort of shorthand for everything
currently below it in the layer cake: fontconfig, Xft, Xlib, pango,
atk, glib, etc.

Havoc