Re: Getting libgnome* into shape

[Maciej Stachowiak <mjs noisehavoc org>]

On 27Aug2001 06:20PM (-0400), Jonathan Blandford wrote:
> 
> <non-controversial comments>
> 
> Maciej Stachowiak <mjs noisehavoc org> writes:
> 
> > > *  finish gnomedruid stuff (jrb)
> > 
> > Could someone please explain the scope of and need for these changes?
> 
> All the API changes have been made (modulo property additions).  The
> scope is simply to update the look of the widget to be less broken.

OK, we can get this off the freeze blocker task list then.
 
> > > *  help stuff (jrb is working on a proposal)
> > 
> > This sounds like a large item which has the potential to blow out the
> > release.
> 
> It's a smallish item that has the potential to blow out the release. (-:
> I don't think anyone thinks the help system we currently have is
> acceptable, and we need to replace it for gnome-2.  It's worthy of
> another mail, though...
 
Looking forward to the other mail.

> > > *  bring back gnome-score (non-deprecated)
> > 
> > I suggest this be moved to a separate games library in the gnome-games
> > package. It seems silly to have it in libgnomeui. 
> 
> Is that as silly as it is to have a 1 widget library in gnome-games?
> I personally would like to see the number of libraries in GNOME go down.
 
Maybe there's more code the games can share. I dunno. But I think app
developers will laugh when they see high score management in
libgnomeui. I wouldn't be averse to cut and pasting the code into all
the games to be honest, but it seems better to ship it off to the
games libary.

> > > *  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)
> > 
> > When is it appropriate to be used? It sounds like we have three
> > non-deprecated config systems now!
> 
> Backwards compat; 

If this were the only use, making the API deprecated would be fine,
don;t you think?

> human readable config file (similar to what's used in gdm);

Sounds like a special-case need. Is this really enough to justify
having a third public, non-deprecated config system in a platform
library? gdm can cut & paste the code as far as I'm concerned...

> migrating older configurations and parsing desktop files mostly.

It sounds like for migrating older configurations and parsing desktop
files we only need it as a private interface, if that. (I'm hoping the
code for parsing desktop files will be a higher-level sane interface
that uses "desktop" instead of "config" in the name).

Perhaps another option would be to rename it to gnome_ini_file_* or
whatever, to make it clear that these are functions for reading files
in a windows .ini-like format, not a config system.

> It will unfortunately still be called gnome_config, but shouldn't be
> really used as a config format.

I worry that the combination of gnome_config, GConf and bonobo-config
will hopelessly confuse developers looking for a config solution. Can
we try harder to figure out a way to kill or deprecate gnome_config?
 
> > > *  finish gnome-about (anders)
> > 
> > Can someone provide more detail/justification? Why not just roll back
> > to the GNOME 1 version?
> 
> These aren't API changes at this point, just UI improvements.

OK, good, it can go off the API freeze blocker list then.

 - Maciej