Integration of freedesktop.org standards for Menu&Desktop icons into LG3D^?

Proposal by Juan González Aguilera (opsi)

Introduction

Freedesktop.org is a "collaboration zone" working on interoperability and shared technology for X Window System desktops. While it's not a formal standards organization (like ISO), they create de facto specifications that are becoming widely used in modern Linux desktops.

They create specifications for all the typical operations of traditional desktop environments, including for example:

• A Drag and Drop standard shared betwen GTK+ and Qt
• Window Manager specifications to extend the ICCCM (Inter-Client Communication Conventions Manual) between X desktops
• Specification for the use of the X clipboard in a consensual way that is shared between Qt and GTK+
• Desktop Entry specification to describe desktop entries that include information about applications (name,icon,...), and are used to build the desktop and the menu
• A draft document that defines how to construct a user-visible hierarchy of applications, usually displayed as menu.

For this proposal, the relevant specifications are the two latest, let's look at them a bit deeper.

Desktop Entry Specification

Most widely used desktop enviroments (KDE&GNOME) have adopted a similar format for "desktop entries" which is in benefit of users because makes their desktop applications available in both (and more) desktops with no extra work, simplifiyng interoperatibilty betwen them and making developers life a bit easier.

These desktop entries are plain text files with the extension .desktop. There are also desktop entry files, that are to describe how a directory is to be formatted/displayed, which are just called .directory .

The basic format of the desktop entry file requires that there be a "group" header named [Desktop Entry]. This "group" entry denotes that all {key,value} pairs following it belong in the Desktop Entry group. There may be other groups present in the file, but this is the most important group which explicitly needs to be supported.

Compliant implementations MUST not remove any fields from the file, even if they don't support them. This is interesting for LG3D^? integration because it allows to add specific requirements that are not present in traditional desktops (like Z position), and may probe interesting to be used as the standard for LG3D^? as it's already for Gnome and KDE.

Desktop Menu Specification

This specification defines how to build a user visible hierarchy of applications. Information about each entry of this hierarchy is stored in a desktop entry (the ones defined before in this document), and the layout of them is described using an XML file which defines where and how to display all of this "desktop entries". The specification allows to restrict elements to one single desktop environment, or the reverse, allow items in all but one desktop.

Adoption of these standards

Since the "standards" proposed by freedesktop.org for desktop entries and menu definition has been adopted by the Free Standards Group, and are referenced in their Linux Standard Base specifications, most modern linux distributions (desktops) are working to get them fully integrated (since KDE3.4 and Gnome2.10 they both integrate these standards). Even Solaris is planning to integrate them when they update to Gnome 2.10 (next Nevada release).

In fact, one little survey that I started in the LG3D^? forum has shown that, at least, the following distributions already follow the standard:

• Suse linux (since 9.1 at least)
• Ubuntu/Kubuntu (since 5.10 at least)
• Gentoo (since ??)
• Mandriva (since 2006 release at least)
• Fedora Core (since release 4 at least)
• Debian (since Sarge at least (needs an extra package: menu-xdg))

LG3D^? Integration

In order to integrate the specified elements it will be necessary to first create:

1. An infraestructure to read "desktop entries" from disk and make them objects. As the "desktop entry" file is similar to an standard Java .properties file, it looks easy to create a Class containing a Map of keys/values, with keys holding the Section and the real key and the values holding, well, the values. This will be used both in Desktop and in Menu creation.
2. A parser for the XML .menu files that follows the indications of the standard to merge multiple files, and can build the complete memory tree for the menu hierarchy. This tree only includes information about the structure, and leave the information about each element in "Desktop entries" that are referenced from it.

At this point, we have the hability to read and abstractly recreate the menu and the desktop in memory, let's look at them separatly:

Desktop

Once the "menu entries" can be managed from Java, loading the user Desktop is trivial, just load all files from ~/Desktop directory and it's in memory. It looks plausible to regenerate the desktop structure in every run. The complexity comes in how to show those Desktop icons to the user. Some ideas have been tried in the past, like the abandoned Microsoft's Task Gallery palette, or the Rooms3D software, but we will have to dig on what the users think is the better way to show all this icons whithout cluttering the desktop, and using the third dimension.

The desktop layout manager is a good candidate to be pluggable.

Applications menu

This part is a little more tricky, because LG3D^? already has a way to build the menu through .lgcfg files, which leads to (at least) two possible solutions:

• Using a cached tree that's updated at startup if the .menu files in disk change. In every start of LG3D^? a single, independent, thread is started to check the timestamps of all .menu file, and if the timestamp is different than the cached one rebuild the tree, persist it and generate the necessary events to build the menu.
• Independent importer that converts from freedesktop format to LG3D^? one (.lgcfg files), and that must be manually run by the user. This importer is to be run outside LG3D^? and before it's running, so it can load it with the existing model.

It's to the comunnity to decide which one is a better option (or even propose some other), but there is time (work) before arriving to this part, and the forum will bring some light on it.

Deliverables

1. Classes to access .desktop files
2. Classes to parse and merge .menu files
3. One generic SceneManagerPlugin^? to generate the desktop icons. It must be pluggable to allow different layouts of desktop icons
4. At least two plugins for that SceneManagerPlugin^? (standard plane layout and palette layout)
5. Depending on the comunnity decisions, a one thread event source for menu entries or a independent importer
6. Of course, documentation on all the above

Here is a Gantt chart to show you the expected schedule for this deliverables:

Last point in this schedule refers to the creation of comunnity suggested plugins for the Desktop plugin.

It's expected to have a working implementation of the desktop by june mid-term evaluation, and work on menu after this.

Disclaimer

I'm very sorry for my poor english , hope you understood me ;)

-- Main.opsi - 01 May 2006