Re: 2.3 Proposed Features

[Malcolm Tredinnick <malcolm commsecure com au>]

On Tue, Feb 04, 2003 at 08:19:34PM -0500, Havoc Pennington wrote:
> 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.

That is what I hope it will be and what I had previously understood the
goal to be. However this thread and a couple of others had been
seemingly drifting away from this.

> > 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 has to be runtime. If it is not, then whether or not GTK actually
contains the other code, it will depend on it so you need to have it
installed. So from the application execution (and installation) point of
view, there is no difference as to whether it is included in the same
library or not. This is not always ideal.

To pick a real example:right now, I know of use cases where gconf is
insufficient and where there are no plans to changes things. This is
just a matter of priorities and needs and is not a problem with gconf.
But it does mean that there are situation where I might want to build an
application that has a nice GUI, but uses a more appropriate
configuration backend. If I have to drag in all the gconf stuff even in
that case, something has gone wrong.  But runtime module detection /
configuration is fine.

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

Whatever. There are arguments both ways, but it's small fish.

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

That's the code layout and maintainers viewpoint. But it's not keeping
the dependencies orthogonal. To install GTK, I have requirements on
pango, glib, fontconfig and Xft. So they are really one big bunch. Now,
admittedly, GTK has some facilities to have some of this stuff left out
or substituted, but not a lot of it.

However, I would expect to be able to install GTK + GLib + friends
without requiring gconf or gnome-vfs, since they provide disparate
functionality.

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

Yes, I'm aware of the history. But this list is now coming very
closing to settling on concrete solutions, so getting it right becomes
important.

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

Which brings me back to why should GTK know about gconf for example. But
we can go around in circles here forever, so let's leave this.

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

Doesn't sound like you do, because I have never, ever pitched for
gratuitous library bloat. Please be serious.

You have views about what GNOME should be. I personally do not care what
"GNOME" should mean any more, since my views are different from the
vocal and larger code-contributing participants so I have no right or
capacity to influence the ball of wax. But I would like to be able to
use some of the libraries in my code, since it is still a fantastic
developer platform. I am also aware of the pain that long, unnecessary
and inflexible dependency chains bring, as are most people in this
thread.

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

As explained above, I am using "level" to mean a group of essentially
inseparable components (you can't have GTK without a lot of other
baggage, so it's all one level, really).

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

Yes.

Malcolm

-- 
Despite the cost of living, have you noticed how popular it remains?