Re: 2.3 Proposed Features

[Malcolm Tredinnick <malcolm commsecure com au>]

On Wed, Feb 05, 2003 at 05:04:58PM +1100, Jeff Waugh wrote:
> <quote who="Malcolm Tredinnick">
> 
> > I am, instead, talking about orthogonal components that can live without
> > the others, but also work with them if available.
> 
> > 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).
> 
> Yes, but instead we have a lower-level library that upper-level libraries
> provide pluggable modules for. This is similar to how librsvg provides GTK+
> with an SVG pixmap module, or fontconfig/totem provide thumbnailers for
> Nautilus.

Not "instead", that is exactly what I am talking about. Except that I
think you have "lower" and "upper" reversed from my usage or you are
using a Northern Hemisphere version of the dependency diagram or
something. The Pluggable Portions(tm) model seems good.

I am, by the way, aware of how the current GNOME development environment
fits together. Both the limitations and benefits. The turnip truck I
rode in on yesterday had an article floating around that I read. :)

> The basics are available in GTK+ and Nautilus, but stuff that depends on
> them can provide more features through modules.

More or less the same as what we are all saying, yes.

In passing, I would dispute that the Nautilus place in the heirarchy is
at any "basic" level -- it provides a visual container for presenting
for a bunch of things, but the things exist in isolation even though
wrapped up as Nautilus components. To me, it sits atop functionality
provided elsewhere. Again, this altered viewpoint could be because our
mental pictures have "this way up" written at different ends.

My responses today have been addressed solely the various portions of
this thread that seemed to be moving towards advocating pushing more and
more into GTK or, more specifically, into required (non-optional)
dependencies of GTK. Since parts of this thread have become a highly
constructive discussion of future development direction and since it is
something that I have thought a lot about, this is the appropriate time
for me to raise these points. We are not going to resolve everything in
a few days, but I am trying to avoid the scenario, as has happened
before, of sitting back and then when somebody raises it later, they get
told "this has all been discussed before and we decided ...", when
actually the conversation just petered out with a lot of "proof by
repeated assertions" on various sides and then snide comments towards
people who dare to raise it again later. I hope I have achieved my aim
and have presented another side of the argument that reasoned heads will
hopefully bear in mind when weighing options.

Malcolm

-- 
The problem with the gene pool is that there is no lifeguard.