Re: profterm's eel usage ...
- From: Havoc Pennington <hp redhat com>
- To: Sander Vesik <sv117949 ireland sun com>
- Cc: Michael Meeks <michael ximian com>, desktop-devel-list gnome org, Darin Adler <darin bentspoon com>
- Subject: Re: profterm's eel usage ...
- Date: 24 Feb 2002 15:30:03 -0500
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!)
> * 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.
> * 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
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.
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.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]