Re: [linux-audio-dev] User Interface

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] User Interface
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Thu Jul 26 2001 - 17:55:21 EEST


On Thu, 26 Jul 2001, Paul Davis wrote:

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

Ok, it was just ranting about you blaming GLAME to use the GNOME libs...

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

But - GtkCanvas is nowhere installed, yeah, we could include it in our
tree, but... its EASIER to depend on gnome for that.

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

Of course. But its not really a GNOME vs GTK+ but the lack of a standard
GTK+extra lib.

> Its partly politics
> (they wanted to provide more reasons for people to use GNOME) and
> partly development issues (GTK+ was under a feature freeze).

I dont think so.

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

Mostly annoying gnome-dev libs depend on installed esd development...
But today requiring GNOME (we're happy with 1.0 up to a CVS snapshot,
compatibility is not an issue) is not a problem at all as all
distributions ship with gnome libs, so basically before compiling
GLAME do an
apt-get install gnome-dev
or
rpm -i gnomed
(or whatever the names are). This is easier than going through your
6 homegrewn libs.

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

Yes, so you dont develop against a moving target, but against the
stable version (we're not building against gtk2.0 f.i.) - or you at
least dont _depend_ on such libs, but only support them, if available
(like we do with certain alsa versions or liblameenc to mention two).

Richard.

--
Richard Guenther <richard.guenther_AT_uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 26 2001 - 17:56:49 EEST