The Future of libgnome and libgnomeui

Anders CarlssonJonathan Blandford

History of gnome-libs● What are libgnome/libgnomeui?

– Initial GNOME library– Held all shared code in the early desktop– Dumping ground before we really knew

what we wanted in a desktop

Problems● Lack of defined scope

– GTK+ does widgets– GConf does configuration– gnome-libs does ???

● Dependency liability– Bonobo not portable to windows– Complicates the platform

● Relatively unmaintained code base● Desktop integration issue

Our Goal● Deprecate● Whack entirely!!● Remove● Fit with a pair of concrete shoes● Send to the great Attic/ in the sky

Our Approach● Deprecate as much as code as possible● Move inappropriately placed code into

appropriate libraries● See what's left

– With some luck, everything will be gone

Comparison of Size

What the heck is there?● Dead code● General purpose objects and widgets● Code to integrate non-codependent

libraries● Code to integrate applications with the

desktop

Dead Code● Large chunks of both libraries are

deprecated– Over a third

● kept for ABI/API compatibility only● 'nuff said

Objects and Widgets● About a dozen widgets● Tend to be lower quality than GTK+● All except GnomeApp and GnomeEntry

are straightforward● All have either an appropriate target

library where they belong or can be deprecated

Objects● gnome-client● gnome-config● gnome-i18n● gnome-score

Widgets● GnomeAbout● GnomeApp/GnomeDock● GnomeDruid● GnomeEntry● GnomeHRef● GnomeIconList● gnome_icon_lookup()

gnome-client● Description:

– Provides session manager support to applications

● Problem:– Buggy and unmaintained– Too complicated

● Action:– Finish GsmClient and move it into GTK+

gnome-config● Description:

– .desktop file parser● Problem:

– not flexible– indeterminate use case– Many alternate implementations (6 at last

count)● Action:

– Rewrite proposed by Ray Strode: #139973

gnome-i18n● Description:

– provides a set of standard gettext macros– gnome_i18n_get_language_list()

● Problems:– Used by libraries lower in the library stack– Cut-n-pasted all over

● Solution:– Move language list getter to glib– Discussed in #95587

gnome-score(s)● Description:

– Set of widgets and library code for handling game score code

● Problem:– Not generically useful

● Action:– move into gnome-games as a library

GnomeAbout● Description:

– Simple 'About...' dialog● Problem:

– Limited API● Action:

– Move to GTK+ once the API is done– Discussed in #109435

GnomeApp/GnomeDock● Description:

– Framework for application main windows.● Problem:

– Unclear that users actually want this– Depends on BonoboDock– HIG is moving in a different direction– Different apps have different forms. Think

IDE vs. Office vs Web browser...

GnomeApp/GnomeDock (II)● Action:

– If need be, write one or more dock for GTK+.

– Unclear if needed

GnomeDruid● Description:

– Assistant widget● Problem:

– Complex API– Bad for accessibility as style can be set

explicitly● Action:

– Discussed in #115348– HIG work needed

GnomeEntry● Description:

– Multiple specialized history entries● Problem:

– Complex API– Dubious targets– Standards non-compliance– Depends on gconf

● Action:– James Cape proposed a replacement

GnomeHRef● Description:

– Simple hyperlink button● Problem:

– Depends on gnome-vfs● Solution:

– Unclear. Possibly provide callbacks that gnome-vfs can use.

GnomeIconList● Description:

– A simple icon list widget● Problem:

– Uses gnome-canvas– Unmaintained– Too simple a widget

● Action:– Discussed in #61819

gnome_icon_lookup()● Description:

– Set of functions to lookup an icon from file information

● Problems:– depends on gnome_vfs

● Actions:– Unclear

Integration code (I)● gnome-libs is high in the library chain

Problems● Some libraries depend on

functionalities that other libraries provide. For example:– GTK+ needs gconf keys– GTK+ needs gnome-vfs methods– gnome-vfs needs graphical and widget

abilities

GTK+ and gconf● History of proposed entry widgets● Color picker palette● Themes● Settings (such as double click time,

drag threshold)

GTK+ and gnome-vfs● Filechooser backend● URL callbacks● VFS access to files

gnome-vfs and GTK+● Authentication dialogs● Warning messages● Launch feedback on application launch

Integration code (II)● code to integrate GNOME applications

with the rest of the desktop.– gnome-help– gnome-program– gnome-sound– gnome-triggers

gnome-help● Description:

– Integrated help system● Problem:

– GNOME specific● Action:

– Move to GTK+?

gnome-program● Description:

– Provides three distinct features:● Argument Parser● Central repository for known paths● Desktop integration system

gnome-program (II)● Problems:

– Argument parsing uses popt, which doesn't handle UTF-8 correctly

– popt API doesn't fit stylistically– path repository doesn't work well– path repository also doesn't use xdg

basedir spec– module registry requires explicit linking,

and doesn't work well with language bindings

gnome-program (III)● Solutions:

– Anders has written an option parser destined for glib.

– Path repository should be rethought. Really only used for help

– Library registry in glib?● We don't know

gnome-sound● Description:

– Plays sound files. Goes 'ping'– Uploads sound files to the esound daemon

● Problem:– uses esound– largely uninteresting

● Action:– GStreamer, if needed. Dump otherwise.

gnome-triggers● Description:

– Plays sounds when global events occur.● Problem:

– Depends on esound. Uses esound in the API

● Action:– Possibly replace with something using

accessibility hooks?

What wasn't removed● gnome-help● gnome-program● authentication dialog● GtkFileChooser vfs backend● gnome_icon_lookup()

Solutions● No really good solutions● Some half-solutions

– XSETTINGS– libgnomevfsui– rearrange the dependency chain

● No good ideas on the desktop integration issue

Conclusions● Going to continue with our deprecation

of gnome-libs● Build upon the current half-solutions● This was harder than expected!

Questions?