Re: profterm's eel usage ...

[Alex Larsson <alexl redhat com>]

On 25 Feb 2002, Michael Meeks wrote:

> Hello,
> 
> On Mon, 2002-02-25 at 15:50, Jody Goldberg wrote:
> > > There are inevitable tradeoffs here... to me the a big win is to avoid
> > > "unmaintainable dumping ground syndrome" by ensuring that everything
> > > in the proto lib is on its way into a real lib.
> 
> 	I have a few points from the last several mails:
> 
> 		* my libwnck proposal was to have a virtual CVS link,
> 		  thus having 1 maintained codebase, and no new APIs

Having it cvs included does not mean it's not API. If several other 
projects uses it any change to it's API needs to immediately be changed in 
all the projects that use it, or they will stop building. This is 
certainly an API, although not one that is exported "publically".

> 		* eel is not an unmaintainable dumping ground, so there
> 		  should be no objection to depending on it.

It is not an unmaintainable dumping ground, but it is certainly not a 
stable API. Changes to eel are basically done as if they were changes to 
nautilus, and nautilus nearly always requires the latest eel to work. Very 
little of the code in Eel is interesting to other apps, except perhaps the 
elipsizing lables stuff.

We're trying to delete as much unused code as we can from nautilus and 
eel, and that would be a lot harder if other apps depend on eel. See 
Darins post about this.
 
> 		* GtkLabel is too specific a place for a string
> 		  ellipsizing API IMHO - perhaps a lower level such as 
> 		  pango is a better place for it.

In a perfect world it would be done by PangoLayout. Unfortunately the API 
freeze prohibits this. Having it in GtkLabel would satisfy most users, but 
it's not optimal.
 
> 		* I can see no reasons given as to why profterm should
> 		  not depend on eel, and/or why we need a new library
> 		  with a new name to full the 'proto-lib' gap that
> 		  people seem to see.

I don't see having to rebuild gnome-terminal every time we release a new 
eel/nautilus as a good thing, and this is basically what you'd have to do 
if profterm linked to eel. The other solution would be what we (RH) have 
with gal. We have to keep a large amount of backwards compat libraries 
since app links agains the old ones and the soname changes on each relase. 
I have 5 versions of libgal installed on my desktop machine.

I'd much rather have some cut'n'paste action than seeing a core app like 
gnome-terminal being "unstable" in that way.
 
> 		* Eel would seem to me a good, well maintained, working
> 		  example of such a library in practice, and as such I'd
> 		  like to see modules use it, starting with profterm.

I don't see this. Eel1 didn't even have a soname, much less bump up 
the major numbers on every ABI incompat release. Eel2 bumps the micro 
number on each release, but this is not actually enough, since we often 
break binary compat.

This is not meant to crack down on the maintainers of Eel, since it has 
worked well for it's primary user, Nautilus.
 
> 		* There is no massive problem with having fairly 
> 		  transient 'unstable' module dependencies, they can
> 		  be removed fairly painlessly when the next lower level
> 		  library release comes out.

Yeah.
 
> 	Apart from that the proposals sound good, to me at least, I don't think
> we need any official proposal / procedure here - apart from people
> agreeing and just getting on with it, without creating a whole new array
> of modules under 'eclectic maintainership[1]' and a dumping ground, when
> we have a goodish, clean and well maintained 'eel' to build on - Yes ?

Yeah. A good start would be to get some gal people and some eel people to 
and look at current gal and eel, and see what code in there is heavily 
used and have a good API. Try to find good final place for these, talk 
to the maintainers of that and then move the code.

/ Alex