Subject: Re: [linux-audio-dev] User Interface
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Jul 26 2001 - 17:32:49 EEST
>> If you have any suggestion on how to reduce the library set, or
>> improve on the functionality offered by each part, or package Ardour
>> for easier compilation, or whatever, I'd love to hear about it. And
>> I'm not being sarcastic.
>
>Include your custom libs into the ardour CVS / tarball. Or at least
>provide a means to do a single ./configure && make.
Well, that's very hard to do, because the complete step is really:
./configure && make && make install
because you can't build each library until the ones it depends upon
are built *and* installed. the only way around that is to build+link
against the uninstalled versions, which is potentially buggy after a
later install step is done.
however, the basic problem is that ardour is not the only application
that uses these libraries, and so they really are *not* part of
ardour. when other applications package libraries into their source
trees, they tend to used only by the application itself. i can't think
of a single application that comes with a library in its source tree
that is also used by another application. [ i know someone is going to
come up with an example now ]
the ardour-dev list has been over this many times, and in fact for a
while, the libraries were part of the source tree. this turned out to
be even more of a pain than having them outside, so i changed back
again.
>libgnomeui provides the canvas widget which is very nice, and stuff
agreed. its a delightful piece of work. thats why i use the backport,
"GtkCanvas", which avoids all GNOME connectivity :) I like it even
more for that reason ...
>for common message/error dialogs. Also automated menu and toolbar
>management.
Yeah, I've been highly critical of the GNOME people for putting these
things in GNOME and not GTK+ where they belong. Its partly politics
(they wanted to provide more reasons for people to use GNOME) and
partly development issues (GTK+ was under a feature freeze).
>libgnome (or gnomesupport, dont know) provides a way to store application
>config stuff, also I think the gnome help functionality is hooked there.
Once again, I am mostly critical of the GNOME people for building each
of these very useful things into a set of libraries whose dependencies
cannot be shrunk down from the complete suite of GNOME libraries. This
is part of the creaping featurism that until recently Linux was
relatively free of; these days, it seems you can't use a help library
without requiring XML parsers, CORBA support, libinet, gzip
compression, image drawing libraries and the rest.
The problem, of course, is that just like with my libraries, there
*is* a reason for all this inter-connectedness: functionality. And
this is a very difficult tradeoff. On the one hand, having a library
that works with text but also with XML-defined network-remote
compressed CORBA image objects is a very nice thing. But on the other
hand, it creates lots of headaches when the size of all the libraries
needed to build the web of dependencies is so large that upgrading is
not a simple matter. If the libraries within GNOME were all stable and
unchanging, or at least changing at the same rate as those from
XFree86 or even GTK+, it wouldn't be a problem. But as it is, trying
to do development of an application against a library base that
changes quite often is very difficult.
And I should know :)
--p
This archive was generated by hypermail 2b28 : Thu Jul 26 2001 - 17:31:46 EEST