1 / 39

Evolution of GNOME Libraries: Removing Legacy Code and Driving Efficiency

Explore the transition and deprecation of libgnome and libgnomeui in the GNOME desktop environment to streamline development by removing obsolete code chunks. Learn about the history, challenges, and current efforts to enhance library usage in the GNOME ecosystem.

woody
Download Presentation

Evolution of GNOME Libraries: Removing Legacy Code and Driving Efficiency

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Future of libgnome and libgnomeui Anders Carlsson Jonathan Blandford

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

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

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

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

  6. Comparison of Size

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

  8. Dead Code • Large chunks of both libraries are deprecated • Over a third • kept for ABI/API compatibility only • 'nuff said

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

  10. Objects • gnome-client • gnome-config • gnome-i18n • gnome-score

  11. Widgets • GnomeAbout • GnomeApp/GnomeDock • GnomeDruid • GnomeEntry • GnomeHRef • GnomeIconList • gnome_icon_lookup()

  12. gnome-client • Description: • Provides session manager support to applications • Problem: • Buggy and unmaintained • Too complicated • Action: • Finish GsmClient and move it into GTK+

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

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

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

  16. GnomeAbout • Description: • Simple 'About...' dialog • Problem: • Limited API • Action: • Move to GTK+ once the API is done • Discussed in #109435

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

  18. GnomeApp/GnomeDock (II) • Action: • If need be, write one or more dock for GTK+. • Unclear if needed

  19. GnomeDruid • Description: • Assistant widget • Problem: • Complex API • Bad for accessibility as style can be set explicitly • Action: • Discussed in #115348 • HIG work needed

  20. GnomeEntry • Description: • Multiple specialized history entries • Problem: • Complex API • Dubious targets • Standards non-compliance • Depends on gconf • Action: • James Cape proposed a replacement

  21. GnomeHRef • Description: • Simple hyperlink button • Problem: • Depends on gnome-vfs • Solution: • Unclear. Possibly provide callbacks that gnome-vfs can use.

  22. GnomeIconList • Description: • A simple icon list widget • Problem: • Uses gnome-canvas • Unmaintained • Too simple a widget • Action: • Discussed in #61819

  23. gnome_icon_lookup() • Description: • Set of functions to lookup an icon from file information • Problems: • depends on gnome_vfs • Actions: • Unclear

  24. Integration code (I) • gnome-libs is high in the library chain

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

  26. GTK+ and gconf • History of proposed entry widgets • Color picker palette • Themes • Settings (such as double click time, drag threshold)

  27. GTK+ and gnome-vfs • Filechooser backend • URL callbacks • VFS access to files

  28. gnome-vfs and GTK+ • Authentication dialogs • Warning messages • Launch feedback on application launch

  29. Integration code (II) • code to integrate GNOME applications with the rest of the desktop. • gnome-help • gnome-program • gnome-sound • gnome-triggers

  30. gnome-help • Description: • Integrated help system • Problem: • GNOME specific • Action: • Move to GTK+?

  31. gnome-program • Description: • Provides three distinct features: • Argument Parser • Central repository for known paths • Desktop integration system

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

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

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

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

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

  37. Solutions • No really good solutions • Some half-solutions • XSETTINGS • libgnomevfsui • rearrange the dependency chain • No good ideas on the desktop integration issue

  38. Conclusions • Going to continue with our deprecation of gnome-libs • Build upon the current half-solutions • This was harder than expected!

  39. Questions?

More Related