Re: Getting libgnome* into shape
- From: Michael Meeks <michael ximian com>
- To: George <jirka 5z com>
- Cc: <gnome-2-0-list gnome org>
- Subject: Re: Getting libgnome* into shape
- Date: Wed, 29 Aug 2001 03:20:48 -0400 (EDT)
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
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
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
> 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
> 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
> 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
> 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
> 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 ...
and turn on TRACE_DEBUG, and make inst-lib in orb-core
Then oaf-slay, and manauly kill gconfd-
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
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
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
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev