Re: My vision of gnome-libs (was Re: GNOME 2.0 meeting summary)

[Rodrigo Moya <rodrigo gnome-db org>]

Hi

I haven't written a single line of code for gnome-libs, so my opinion
may not be too good, but as
a gnome-libs user for almost 3 years, I'll say my opinion in case it's
useful.
 

> b) Compatibility layer
> ----------------------
> 
> To avoid too much breakage to existing applications, we should discuss whether
> we want to have some kind of compatibility layer which will allow GNOME 1.x
> applications to use the new gnome-libs with minimal changes.
> 

> I think after GNOME 1.4, we should add some things to the stable
version of
> gnome-libs to ease migration to gnome-libs 2.x for application
developers:

one of the most important, IMO, compatibility layer that should be
provided is the gnome_config stuff,
which, AFAIK, is being used everywhere. GConf API and gnome_config are
almost identical, with few exceptions, and a mapping between them should
be very easy to do (in fact, I did this once for gnome-db when we were
supporting both gnome_config and GConf, and it was really easy to do).
New stuff in GConf, such as notifications, won't be a problem since this
is not used in gnome_config-based apps.

And this could remain for ever in gnome-libs, as it's more a wrapper
than a compatibility layer.


> 
> f) GnomeSelector, Gnome-VFS integration or Martin's Baby
> --------------------------------------------------------
> 
> First of all, let me explain what GnomeSelector is, what it does and
> why it's there.
> 
> In gnome-libs 1.x there are widgets like GnomeEntry, GnomeFileEntry,
> GnomeIconEntry, GnomeIconSel etc. All of them share some common technology:
> 
> - they store/manage a list of directories/files
> - they have an UI to let the user browse these lists etc.
> - they have history support
> 
> If you look at the code of these widgets in gnome-libs 1.x, you'll see that
> there's a lot of similar code in all of them since they implement more or
> less the same technology.
> 
> GnomeSelector is an abstract base class which provides all the common
> technology between these widgets. This means that for instance GnomeIconSelector
> inherits all of its functionality from GnomeFileSelector which itself inherits
> from GnomeSelector. The only thing which GnomeIconSelector needs to implement
> is its UI.
> 
> GnomeSelector already uses GNOME-VFS and is fully asynchronous.
> 

this is great!

> g) Bonobo integration
> ---------------------
> 
> Well, basically I'm still waiting for Miguel to tell me how to do this ...
> 

IMO, one way to do this could be to componentize the GNOME core, that
is, the window manager, the panel, the configuration stuff (background
image, menus, etc), and have gnome-libs provide 
functions to access all this stuff.


> h) Other things which I'd like to have integrated in gnome-libs
> ---------------------------------------------------------------
> 
> In the last few months, several cool and nice things have been developed
> in GNOME. We should have a look around at all these nice things and discuss
> whether we should move some of this stuff into gnome-libs. Especially in
> libnautilus and libnautilus-extensions there seems to be such stuff.
> 
> For instance, what I'd like to see in libgnomeui is:
> 
> - this nice icon list / icon canvas item stuff
> - maybe some stuff from gal
> 
yes, I'd add to the list the shortcut bar in evolution, which is very nice



cheers


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers