Re: profterm's eel usage ...

[Sander Vesik <sv117949 ireland sun com>]

On 24 Feb 2002, Havoc Pennington wrote:

> 
> Sander Vesik <sv117949 ireland sun com> writes:
> > This sounds like "libwnck" all over again - code gets copied and pasted to
> > multiple places, and even if it doesn't get editied is a pain an
> > uneccessary duplication.
> 
> I don't get the comparison to libwnck at all - libwnck is neither a
> duplication of anything else nor a copy-and-paste. Neither is it
> copy-and-pasted, it's an installed shared lib. (Though I believe
> Michael wanted it to be cut-and-pasted!)
>  

Well, no - the parts that make up libwnck *used* to be copy-and-pasted in
several places. 

> > 	* get eel to the point where it is just a normal stable libarry so
> > 	  people don't have much qualms on depending on it
> > 
> 
> Clearly bogus - any library without a clear functional goal is
> automatically a non-candidate for stability and platform
> inclusion. e.g. gtk is a gui toolkit, bonobois a component system,
> pango is i18n, libzvt is a terminal widget - eel is "some stuff that
> used to be in nautilus." Non-starter.
> 

I wasn't proposing it to become a platform library. 

> > 	* create a library called "proto-gnome" into which code can be
> > 	  moved from other upstream libraries under a review and a promise
> > 	  to move the code into libgngnome{ui} at the next api addition
> > 	  round. Would need to be discouraged to be used by anything but
> > 	  gnome components so is a bit painful.
> 
> Eel, GAL, gnome-desktop are all essentially prototype libraries. The
> only issue is that there are too many of them. I'm undecided on
> whether that's bad though. Having more than one sort of minimizes the
> "damage"
> 
> Perhaps you're suggesting a more stable prototype library - APIs which
> have already been reviewed and slated for inclusion in a stable lib -
> this has been discussed before. The end target should not be
> libgnome{ui} though but the library whose clear functional goal

No, the end target does not always have to be a single library like
libgnome{ui}. 

> overlaps the nature of the feature being added. e.g. label
> ellipsization clearly belongs in GtkLabel, not GnomeLabelHack. GTK 2.2
> and 2.4 will be absorbing some of the features from other libs that
> "belong" in the GUI toolkit.
> 

Yes, of course.

> Personally I think the combination of the unstable libs and the
> occasional temporary c-n-p is OK, assuming we can make 2.2/2.4 type of
> releases with enough frequency, and I think we can.
> 

This very much depends on the frquency (we are still very busy with 2.0)
and how extensively the features are used. It probably also gets at least
those pieces of code more tested before inclusion in actual platfom
libraries. No, it does not mean all inclusions would need to be developed
that way.

>
> Havoc
> 

	Sander

	I see a dark sail on the horizon
	Set under a dark cloud that hides the sun
	Bring me my Broadsword and clear understanding