Re: Getting libgnome* into shape

[Michael Meeks <michael ximian com>]

Hi George,

On Mon, 27 Aug 2001, George wrote:
> It's not actually that much deprecated code.

        For example bonobo-dock* vs. gnome-dock*, wonderful news - at
least, can we make that gnome-dock.h set a macro mapping.

>  Not to mention that without a miracle happening, most applications
> would link against libgnome1-compat.

        So - why should one want to link to libgnomeui anymore; it begins
to look like a bloated pain in the backside of a library again. Simply use
libbonoboui and forget the libgnomeui pain.

> Adding more code to a library is much lower in overhead then a new
> library.

        Not for the code that doesn't link to that library.

        Yes I understand that perhaps for Gnome 2.0 we will need to link
to libgnome1-compat everywhere - but I hold out high hopes that while we
will never ( possible _ever_ cf. your allusion to X ) be able to change
the Gnome 2.0 core APIs - we _will_ be able to change the applications on
top for Gnome 2.0.1 2.0.2, 2.2, 2.3 etc. to progressively remove any
libgnome1-compat staleness.

        Of course - if we glup the whole load of cruft together - we're
just scuppered forever; not clever.

> Another thing is that we do drop some stuff on the way to libgnome/ui
> from libcompat.  And it will be easier to drop things in the future
> this way. Not to mention that it reduces the work in maintaining the
> thing by quite a bit.

        Not at all, I think it just allows evil hacks with using
deprecated code internaly, and kills some of the cleanliness of separation
of stale crud into another module - this seems to be happening already. Of
course, it's always far easier to pile vile hack on vile hack - sometimes
it's even quicker; but it's not good for the long term.

> There are many other reasons for the _DISABLE_DEPRECATED macros rather
> then an extra lib which Owen mentioned in his mail.  We don't need to
> list them here again.

        I don't find any of Owen's points very convincing - but I'll reply
to them later.

> We have release gnome-libs 1.x.  That is a supported API.  We have
> repeatadly said we will fully support this API.

        That's just nonsense - in no way do we 'fully support this API'
and you know it - what tripe :-) there are loads of minor changes to be
made to port to Gnome 2.0. It'd be a really nice argument if it was true
though.

> We cannot, in order to have some holy grail of clean APIs, screw over
> the developers.

        And this is the reason for the libgnome1-compat library - please
engage with the real arguments.

> I find the Xlib API utterly repulsive in places.  And I'm sure the
> Xlib developers do as well.  However one of the reasons for X being so
> popular is that porting in between versions is utterly simple.
> Usually just a matter of recompiling.  And also the API has pretty
> much not changed in the last few years.

        So your thesis is we should be ugly like X ? or that there are no
API changes between Gnome 1.4 / Gnome 2.0 ? both statements are totaly
bogus.

> Oh I bet they'd shed a whole bunch of API/libs if they could.

        We're in a totaly non analagous situation, and we have a chance,
and so far - mostly have, a fairly clean break; your argument is specious.
I'm not arguing that we shouldn't provide good compat where we can - just
that we shouldn't cause acute and obscene breakage and vileness to try and
do so.

> 1)  It's an implementation detail anyways.  This does not break the API.

        As long as there is no include gconf.h in the installed headers, I
can cope with this with a whole load of mental screaming about horrendous
lack of taste, and general brokenness; preferably no GErrors would be nice
as well.

>     I thought we decided initially that we were going to use
> bonobo-conf as a wrapper around gconf, but that gconf was going to be
> a backend

        And indeed, that's how it should be used; so ?

> 2)  All three of us are a lot more comfortable with the gconf API

        Oh please; this is just feebleness. It may be slightly less taxing
on the brain but it is a terminal evolutionary dead end; tragic.

> 3)  GConf is already required by the platform so if we have the
>     "manifestly broken gconf C client headers" we'll have those anyway

        Yes - but there's no need to include them; make people explicitely
ask to use broken code, don't give it to them by default.

> 4)  We are trying to get a stable library out sooner.  So it seems to
>     me that adding an extra layer (and one that has NOT been tested
>     out in the wild yet) seems not quite a way to go.

        Um - another way of looking at it might be to realise that the
code is currently there - and it works; so there is no "adding an extra
layer" - that's just bleating, you are effectively wasting time by
changing things that don't need to be changed, and slowing down the
release of a stable API. - But as Maintainer that is your perogative I
suppose.

> 5)  I think some of the startup time is related to this.  Though I'm
> not completely sure of that, that will need investigation.

        And again ... please do the following for me ...

        edit ORBit2/src/orb/orb-core/orbit-debug.h

        and turn on TRACE_DEBUG, and make inst-lib in orb-core

        Then oaf-slay, and manauly kill gconfd-[12]

        Now run your app ... see where the slowness is ? perhaps it's not
clear, try doing a tail -f /var/log/messages & [ so you can see gconf
which syslog's it's messages as it delays the whole startup process by
several ~3 seconds ] on my machine. Now tell me that bonobo-conf is the
performance culprit !

>  That said GNOME2 startup time is incredibly horrid.  Taking out any
> layer which happens on startup (the configuration does) will speed
> things up.

        This is balmy too - abstraction and cleanliness is nice; breaking
it is bad unless there is a good performance reason; and there just isn't.

> Also many apps don't really have maintainers.  I don't want to have to
> port them to BonoboWindow anytime soon.  Mostly because lack of time.

        Then link vs. libgnome1-compat; why is this so hard to understand?

> We also need a help API.  We cannot have libraries with such large
> missing holes.  We cannot release GNOME2 without a help API.  We must
> remember the users, at least every once in a while.

        Ok - reasonable; however this doesn't sound like the most
horrendously complicated thing to do - requiring 2 weeks work. AND as you
are so fond of saying we must have 1000% compatibility with Gnome 1.4 so
why don't we just copy the old gnome-help API ?: 2 minutes.

> So at this point I think the most sensible thing to do would be to
> punt gnome-stock altogether and just put some good instructions in the
> porting guide.

        Having a standard set of extra icons that we can expand in
gnome-libs [ And yes - using the gtk-stock API ] seems like a sensible
plan to me; the needs of Gtk+ and GNOME are not always coincident, pwrt to
the size of icon sets.

> > One could make arguments for this I'm sure - but privatizing it
> > would be good.
>
> For one widget?  Making more shared libs will just kill our startup
> time.

        By privatizing I imply that the object should not be exposing its
internals via public members; but instead using a private (opaque) data
structure - to allow it to be changed in future without ABI breakage.
Nothing to do with shared libraries.

        As Martin suggests - this API would be far more appropriate in
gnome-games where it is actualy used.

> And I will end up using them ad infinitum in some programs.  It is not
> a deprecated API.  If it were I'd have to write a new one to replace
> it.

        Oh please - Havoc; can you wade into George - or at least have
some plan to deal with the gnome_config API.

> George (With some spliced in opinions of Anders and Jonathan, meaning,
> we pretty much all agree on this stuff)

        Sigh, this is really sad, why can't these guys speak for
themselves.

        Regards,

                Michael.

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