Re: Getting libgnome* into shape

[George <jirka 5z com>]

[ Anders and Jonathan helped with this email so it's not just my own
  opinions ]

On Mon, Aug 27, 2001 at 12:49:10PM -0400, Michael Meeks wrote:
> Hi Guys,

Hi dude

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

Well. 

  1) there are undoubtably things to be finished.  We can bring back the
     API (except help stuff) within a few days at most.  However, even
     though this is mostly old API there has to be a period of possible
     change.  We would really like someone to try it in porting a real app
     before we freeze.  And porting a real app, not something small.  Or
     at least starting to port.  So that we get more feedback as to what
     can go wrong.

  2) The help API isn't even finished.  Two weeks from zero to frozen API
     is not enough at all.

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

It's not actually that much deprecated code.  Not to mention that without
a miracle happening, most applications would link against libgnome1-compat.
Adding more code to a library is much lower in overhead then a new library.

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.

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.

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

We don't add complex dependencies.  Note we keep dependencies.  We have
release gnome-libs 1.x.  That is a supported API.  We have repeatadly said we
will fully support this API.  We cannot simply drop it.  Especially if the
alternative is either very hard to port to, or fullfils a different niche.

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

That is the same with or without libgnome1-compat.  The fact if it's a
separate library or not doesn't change anything.  We are trying to make an
easier and more consistent deprecation process.  And to make maintaing the
whole thing a lot easier.

Again, please read Owen's mail on the topic it covers this pretty fully.

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

We cannot, in order to have some holy grail of clean APIs, screw over the
developers.  Remember we are not the only people developing for internal
GNOME use.  We should learn from people like Jim Gettys.  He said this a few
times on this list already.  We have already comitted to an API, we can't
just completely change it because we have found the new in-vouge way of doing
things.  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.

Another thing I think of here is Miguel's talk 'Unix sucks'.  I agreed with
what Miguel said very much.  And I still do.  Miguel mentioned why is it that
Microsoft dominates the industry.  Why?  Because they don't keep reinventing
the foundations.  They may change them slightly, they may add.  But they keep
them, and they keep them for backwards compatiblity.  That's why there are SO
MANY windows applications.  Some of them are still 16bit win3.1 apps.  Don't
you think they'd really like to go get rid of some of the APIs?  Oh I bet
they'd shed a whole bunch of API/libs if they could.

Libraries are for the public to use.  Not for the public to admire their API
beauty in the next promised revision.

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

1)  It's an implementation detail anyways.  This does not break the API.
    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, GConf is already a wrapper).  I thought that Martin
    mentioned that he was going to use bonobo_config only b/c he was more
    comfortable with it.  He was only going to use the gconf moniker.
2)  All three of us are a lot more comfortable with the gconf API
3)  GConf is already required by the platform so if we have the
    "manifestly broken gconf C client headers" we'll have those anyway
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.  Remember bugs do
    go down with the amount of code.  And all that bonobo_config in
    gnome-libs achieve right now is add an extra layer that is not
    at all needed.
5)  I think some of the startup time is related to this.  Though I'm not
    completely sure of that, that will need investigation.  That said
    GNOME2 startup time is incredibly horrid.  Taking out any layer
    which happens on startup (the configuration does) will speed things
    up.

> > *  gnome-mdi 1.0, re-port, deprecated (george)
> 
> 	Why !? leave it in compat; peripheraly it's a broken concept
> anyway.

We don't have libcompat.  It wasn't in libcompat anyway.  And it's used quite
a bit.  And is a large API.  It takes quite a bit of time to port to
something else.  And remember that most hackers of GNOME stuff do so on their
free time.

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

Same argument as above.  However GnomeApp is much more used then GnomeMDI.
There will be many apps that will want to stay with GnomeApp for the
forseeable future.  I maintain a bunch of these.

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.  There are
a LOT of GNOME applications.

> > *  help stuff (jrb is working on a proposal)
> 
> 	Sounds great - but does this add more API breakage - we want to
> freeze now.

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.

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

Well it IS deprecated in our plan as well.

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

Actually I have looked at gtk-stock.  And damn, I found that gnome-stock
provides no extra functionality.  I ported GnomeApp to gtk-stock within
minutes (well you don't just use gtk-stock, you use gtk-button and gtk-image
as well for all the functionality).  With a good porting guide there is
absolutely no reason to use gnome-stock.  What we can easily do (and I
already did this for the dialog buttons) is have defines from old GNOME
stock names to new gtk-stock names.

There are also some extra gnome stock icons in libgnomeui that work with
gtk-stock.  So that we don't lose any icons.

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.

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

Actually I think we should be supporting the gnome-sound api.  It's utterly
simple, the way it should be.  I don't see anything wrong about that API.

The triggers api is not so nice.  BUT there is no replacement.  According to
the policy stated above.  Unless there is an easy to port to and viable
replacement that can do what this API can, we shouldn't deprecate it, if
it is a usable and used API (which this is).  It's also a very small API.

> > *  bring back gnome-score (non-deprecated)
> 
> 	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.  In
fact same as one of Owen's reasons for not using libgnome1-compat.  Having
this in libgnomeui is not at all a big overhead addition, but having a
separate library is.  And this widget is quite small.

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

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.
XML doesn't solve things here.  For example in gdm I can parse configuration
with a shell script (And so can startup scripts in distros and whatever).  
Not to mention that if you are trying to make an actual human readable
configuration there is nothing more readable then this.

Now Here I somewhat differ from Anders and Jonathan.  All in all we
(including me here) are willing to deprecate this API or have more thought
go into this point.

... Well, have fun

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

-- 
George <jirka 5z com>
   If all gnome hackers were laid end to end, they would not reach a
   conclusion.
                       -- George Bernard Shaw