Re: 2.3 Proposed Features

[Malcolm Tredinnick <malcolm commsecure com au>]

On Tue, Feb 04, 2003 at 11:38:05PM -0500, Jody Goldberg wrote:
> On Wed, Feb 05, 2003 at 11:23:45AM +1100, Malcolm Tredinnick wrote:
> > 
> > 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.
> 
> While the core of these components may be orthogonal they do overlap
> eventually.

In the common cases. Sometimes the config information required can be
supplied by the programmer and so they just use the light-weight widget.
I'm not disputing that a common case simplifying layer is required.

> - Widgets want config information.
> - File browsing needs to know about vfs to be useful
>  
> > 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.
> While its nice in priciple it also greatly increases the complexity
> of the damn thing.
> eg
>     it would be nice to support recently browsed urls
> or
>     to help manage ssh keys
> and so on.
> 
> It is also a dependency nightmare.  As an application writer I need
> to be able to rely on the underlying libraries to support certain
> features.  If every installation has different things we get a mess.

This seems to again be the case of "the widget must offer the same
functionality everywhere and they do a lot". I am pitching the case for
finer-grained widgets. Probably I am not explaining myself well.

As an application writer, you can set your dependencies -- your
application depends upon gtk and gconf and gnome-vfs, or whatever takes
your fancy. That is why I was suggesting that something at the
libgnomeui level provides, for example, a wrapper of the generic file
browser which wraps the intialisation code required to include gconf and
gnome-vfs. Something else that want to use different back-ends would
construct the file selector differently. So the file selector has to be
pluggable and at the bare bones level, its constructor is a bit
parameter-laden, but in practice you use a wrapper one level up.

> > 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.
> 
> Modularity is not impossible, but there are limitations.  There is
> a cost to having lots of libraries.  I regularly get complaints that
> gnumeric's library stack is too large, and the poor gnucash folk got
> pilloried in the press not so long ago for doing the right thing and
> reusing existing libraries.

Well, that's the eternal argument of lots of small libraries or one very
large library. I prefer the former case. Also, to be fair, a lot of
ranting that went on back in the GNOME 1.x days was because a number of
the library versions that were outside the platform but popular would
have incompatible upgrades. The current understandings within the group
of GNOME developers about when it is reasonable to break API and,
particularly, ABI compatibility has improved that a lot.

> > Another drawback of pushing everything down to one level -- you
> > completely lose the possibility to do incremental releases of small
> > components.
> 
> We lost that long ago.

No. You lost the ability to do incompatible releases. But you can do bug
fix, improved code, optimising, etc, releases at any point because of
the compatibility guarantees. If everything devolves to a couple of
large libraries, then "small improvement" releases of this nature
become harder to coordinate because there are more vested parties.

I think we are talking at cross-purposes here: I am not proposing
orthogonal components that can be developed willy-nilly with no
consideration for the others. I am, instead, talking about orthogonal
components that can live without the others, but also work with them if
available.

> Once something is in the gnome platform there are requirements for
> api/abi stability.  We can't pop out releases as quickly as we used
> to.  Before it goes in releases are simpler, but fewer people can
> rely on things if there is rapid change (witness gal's popularity)

Yes, libgal was a perfect example of why madly developing without
consideration of others does not work. The version tracking requirements
were a nightmare. But that is not what I am discussing here -- I think
we both agree that is not a good experience to repeat.

> I would not advocate making gtk into the all singing all dancing
> library to do everything.  However, there definitely seems like lots
> of room to grow.

As I mentioned somewhere else, I am concerned about fulfilling the "not
all singing and dancing" goal by semantic -- i.e. moving things to a
bunch of absolutely required dependency libraries. At that point, you
_still_ can't have gtk (or other library of choicei -- this line of
reasoning is valid across the board) without having all of the things
below it.

To summarise: I am aware of the need for compatibility. I am aware of
the need to leverage functionality from other libraries. But I would
like the dependency chains to look like "can use this feature from
library X", rather than "must have library X installed in all
circumstances". Then we can have some top-level libraries that require
everything as wrappers (or pluggable modules, with respect to Havoc's
idea of a single API).

Malcolm

-- 
A clear conscience is usually the sign of a bad memory.