Re: Getting libgnome* into shape

[Michael Meeks <michael localhost localdomain>]

Hi Guys,

On Sun, 26 Aug 2001, George wrote:
> Anders, Jonathan and I have been discussing what to do to bring
> libgnome* into shape quickly.  Our current thoughts are that this
> could be finished within a fortnight and then frozen.

	A fortnight ! this seems like an incredibly long time to me; and
for what gain ? what precicely is going to take a fortnight ?

	It seems to me that forcing people to link against a load of
deprecated code - when we already have a clean separation into
libgnome1-compat is just a gobsmacking idea ? I mean ... I can see no
possible benefit from it whatsoever - apart from re-integrating a load of
crufty code that is best left outside.

>  What this consists of is mostly rolling back some changes and
> bringing back things that went away for the moment, until viable
> replacements are finished.

	There are indeed some places where this is most useful, I agree
entirely with the following:

> *  bring back entries, remove selectors non-deprecated (george, anders)
>    (done: gnome-entry, gnome-file-entry)
>    (not-done: gnome-pixmap-entry, gnome-icon-entry)
>
> *  finish gnome-about (anders)

	As for the rest of the stuff - we deliberately confuse a load of
modules, add complex dependencies on deprecated stuff, slow down link
times etc. etc. I can't comprehend why this should be neccessary:

> *  whack libgnome1-compat and use GNOME_DISABLE_DEPRECATED,
>    following the gtk+ scheme

	Simply because Gtk+ does it is no good reason for us to; we are
talking a big chunk of duplicated code here. Linking against
libgnome1-compat has no intrinsic shame - simply that you are most likely
to get screwed by Gnome 3.0, and it would be good to start moving now.

	I also propose that libgnome1-compat is marked as a separate
help library for which we have no long term plans for keeping API
compatibility. I have real worries that the extraordinarily anal backwards
compatibility people are going to be arriving rsn. and we don't want to be
shooting ourselves in the API foot - indeed a lot of work as gone in to
try and stop this happening.

	Consequently I propose that some of the stuff that has been
proposed to be 'added' to libgnome should be put in libgnome1-compat,
since it is simply to help porting - and not an API we are happy with in
the longer term.

> *  finish gnomedruid stuff (jrb)

	Sounds good too.

> *  s/bonobo_config/gconf/

	Why !? rational ? this has been hammered out extensively - I
really object to this change - very strongly - are there any substantial
reasons for this ( large ) change ? this will consume considerable time
for precicely 0 gain - why delay freezing everything, and introduce the
manifestly broken gconf C client headers into the project again ? sigh,
this is really a very tedious suggestion.

> *  gnome-mdi 1.0, re-port, deprecated (george)

	Why !? leave it in compat; peripheraly it's a broken concept
anyway.

> *  GnomeApp and friends, bring back non-deprecated
>    using bonobo-dock and gtk-dialog
>    (partly done)

	GnomeApp adds a large amount of ugly, code that is not only huge
and complex, but duplicated by the bonobo work; leave it in
libgnome1-compat where it belongs.

> *  help stuff (jrb is working on a proposal)

	Sounds great - but does this add more API breakage - we want to
freeze now.

> *  deprecated:  gnome-dialog, gnome-propertybox (george)

	The gnome-propertybox API is so fundamentaly broken ( in a
GtkFileSel sort of 'please poke inside my structures' sort of way ) that
it's a libability to have outside libgnome1-compat ).

> *  deprecated:  gnome-stock, gnome-pixmap

	gnome-stock is useful; and I think we should have the option to
expand the set outside of that provided by Gtk+.

> *  bring back gnome-triggers, gnome-sound (non-deprecated)
>    (done)

	This should be in libgnome1-compat - we don't want this API in
libgnome IHMO - it's not something we should be supporting ad nauseum.

> *  bring back gnome-score (non-deprecated)

	One could make arguments for this I'm sure - but privatizing it
would be good.

> * bring back gnome-config (non-deprecated, but with a big
>    comment explaining when it's appropriate to be used)
>    (done, the comment needs to be put in place)

	That seems reaonable - but put it in compat; I'd also suggest that
it generates a runtime warning unless you explicitely disable it;
gnome_config calls tend to get scattered everywhere.

> *  bring mostly back gnome-i18n (non-deprecated)
>    (done)

	Sounds ok I suppose.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot