The Future of libgnome and libgnomeui Anders Carlsson Jonathan 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 # – 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?