Re: profterm's eel usage ...

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> 		* eel is not an unmaintainable dumping ground, so there
> 		  should be no objection to depending on it.
>

I don't agree. Stuff goes in Eel anytime it's possibly of general
interest and used in at least two places in Nautilus. That's too loose
a criterion IMO.

It still contains plenty of dead-end code even now, that has no chance
of moving to the platform libraries. This is _after_ about 50% of it
has been blown away for 2.0.

Sure we could blow away still more of eel, and reconfigure it to be
this new library, but that would cause Nautilus a bunch of pain for no
particularly good reason. And Eel seems to be useful to the Nautilus
hackers in its current form, I see no reason to mess things up for
them.

If we can get "sponsors" for some stuff in Eel and nuke the rest and
the Nautilus hackers are in favor of that then I don't mind, of
course. The name of the prototype lib isn't the issue, the issue is
its clear functional scope: prototyping things that are genuinely
being considered for addition to the platform.

We could also do this transformation on GAL if the GAL maintainers
want to do that, I don't care. But this would e.g. nuke ETable.

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

This is a very specific tangent, but the basic idea is a 
pango_layout_set_ellipsize_mode() combined with a GtkLabel feature
that uses this Pango feature.

Remember that GtkLabel is just a "view" for PangoLayout these days.
  
> 	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 ?

We need to agree on ground rules or guidelines for the prototype
library, or I at least will not touch it. The guidelines don't have to
be the ones I suggested but unless some guidelines exist that impose
meaningful limits I'm not personally willing to use the library,
either to prototype my stuff or in my apps.

All libraries should have clear functional scope that meaningfully
limits what's in the library. Otherwise you get endless bloat, and
tons of libraries that overlap each other in incoherent ways.

Havoc