Re: Getting libgnome* into shape

[George <jirka 5z com>]

On Wed, Aug 29, 2001 at 03:20:48AM -0400, Michael Meeks wrote:
> 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.

I don't think that's even necessary.  You can port very quickly using any
editors search and replace functionality :)

Plus most people used the dock through GnomeApp so they wouldn't notice the
difference.

> >  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.

There are still things there worth using it for.  Not as many, but in fact in
martins plan there is even less use for libgnome*.  The biggest reason is
that app writers can worry about writing their apps and not drastically
changing APIs all the time.

> > 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.

We can progressively get rid of the staleness this way just as well.
When 2.2 comes along, we can wipe a few of the deprecated things.  Just as if
we got rid of something from libgnome1-compat.  Or we could drop all
deprecated stuff at that point.  The choice is ours.

>         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.

I can do internal evil hacks with libgnome1-compat just as well.  (And
believe me I will have to do evil hacks in several things I maintain)  That
is not at all an argument for libgnome1-compat.

> > 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.

Another issue is that we already used _DISABLE_DEPRECATED in libgnomeui,
in 1.x and actually even in 2.0.  To deprecate single methods.  So we in fact
had BOTH methods, because libgnome1-compat alone couldn't cut it.

> > 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.

Well with the libgnome* before our proposals it would basically mean
ripping appart ALL gnome support in your apps.  With our proposed changes,
most apps should mostly just compile.

The fact that we just dropped the API is what I'm arguing is bad.  We HAVE
comitted to the 1.x API.  Like it or not.  So if we just now drop it, because
we think it's not 'perfect' or 'nice' or doesn't follow the 'in-vogue'
concepts.  Then we lied.  I know people that dropped gnome support because I
told them what was dropped from libgnome*.  They don't want to deal with it
again.  And let's face it.  We'll do this all over again in a few years
because the 'in-vogue' stuff will be different then.

> > 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.

Huh?  How is this a reason against _DISABLE_DEPRECATED and for
libgnome1-compat?  Yes we do need to include deprecated stuff.  But the above
sentence also implied that we can't deprecate stuff so easily as well.

> > 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.

Well.  Since you think X is so ugly.  Why are we still using it.  YES, you
have it.  Because it doesn't change.  If Xlib changed completely twice since
we started on GNOME.  We'd probably be looking for another solution.

> > 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.

Huh?  How is this not the same situation.  We have people using the old API.
They have people using the old API.  Why don't they drop the old API?
Because people are using it.  Same here.  Except we ignore people and drop
it.

> > 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.

There are two pieces of API which are just as applicable to if you use GConf
or if you're using bonobo_config with the gconf monicker.  (or not, they're
just for getting paths).  They could be for all I care dropped as well.
Else, it's actually bonobo-conf that's adding API to libgnome*, not the other
way around.  And I can't see a reason for removing that.  Though I suppose it
would make a lot more sense to make that initialization optional.  So that
only people that use it actually init it.

> > 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.

That's a subjective call.  I don't think so.  You do.  No point in arguing
here, we won't get anywhere.

> > 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.

They are included in libgnome* not in the libgnome* headers.  There is no
need to include them there.  If people want to use gconf they'll include
them.

> > 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.

Anyway, we're wasting our time.  And we feel like it's a good idea, and it's
not an API issue and thus I don't see what's the argument.

>         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 !

And so that needs to be fixed either way.

> >  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.

Abstraction is good, up to a certain point.  My opinion that with this
abstraction we got into the realm of diminished returns.  Anyway a semantic
argument.  Both of these points 'abstraction and cleanliness' are things
where people have very different opinions.

> > 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?

I want to be able to go without deprecated stuff, since I want these apps to
link in say GNOME 2.2 or later when the deprecated stuff might disappear.  If
I'm not writing a full bonobo app right now, there is no reason to go with
BonoboWindow for now.  Deprecated means 'will go away soon'.  I don't want to
use such API except for perhaps the initial release of 2.0 before we get
enough time to clean everything up.  GnomeApp in our opinion is not something
that can easily go away that soon.  GnomeDialog on the other day could 
go away very quickly, it's very easy to port to GtkDialog.

> > 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.

The old gnome-help API won't cut it I'm told.  Help is a more complex issue.

In any case.  The two weeks term was given to give reserve for unexpected
things.  We weren't ready to shout freeze before it was actually frozen.  A
freeze would then mean that nothing would be added, subtracted or changed
no exceptions.  That doesn't mean that the API will keep changing.  Sander
asked us to make a release within a few days which would be tenatively
finished and "almost frozen", and we want to do that.  Of course with the
current mess in CVS we can't get to actually doing work.  So the latest
revert fun probably put us back a few days on that goal.

> > 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.

Yes, and that is the case.  libgnomeui already expands the set of stock icons
and we can continue doing so.  Without gnome-stock.  And other can also do
so.

> > > 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.

Ahhh, yes as far as I know I did that over a year ago.  I could be wrong, but
I do remember having most widgets privatized around last year's USENIX time.

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

There are games outside of gnome-games, and a shared lib for one widget is
somewhat silly.

> > 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.

I will use it because I have several uses for it.  For example in gdm.  I
will not use something else because I need a very human friendly format,
which is what gnome_config is.  I don't care about what else it gives me.
gdm needs to be easily configurable by vi just like any other daemon.  No XML
format, no fancy API.  It's not needed and would just hurt usability of it.
So if gnome_config goes from libgnome, it will very soon appear in
vicious-extensions in some form.

> > 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.

Huh?

George

--
George <jirka 5z com>
   - I'm getting better!
   - No, you're not. You'll be stone dead in a moment.
                       -- Monty Python