Project "XDG ng"

Purpose of project "XDG-ng"

• Improve the usability of desktop environments for end users
• Allow for features previously lacking in desktop environments
• Remove layers of legacy crust
• Remove reliance on GLib
• Make debugging and development faster, simpler, and more fun

Potentially of interest to

• Haiku
• SerenityOS
• Fyne
• Draco Desktop Environment (@rodlie)
• GNUstep
• ravynOS

Basically all desktop environments that are not firmly rooted in XDG land.

• Likely not interested: Red Hat, Fedora, GNOME, Gtk, Flatpak, Wayland (firmly in XDG land)
• Possibly not interested: KDE? (currently in XDG land)

Prior Art

XDG

freedesktop.org (formerly known as X Desktop Group, hence XDG) specifications

• Define how most desktop environments currently work under the hood
• Address most areas needed to put together desktop environments
• Are decades old and do not make best use of contemporary technology, e.g., extended attributes
• Lack concepts integral to the desktop user experience, e.g., application bundles and global menus
• Make things that should be simple complicated or impossible
• Seem to be retrofitted to explain how Glib works, are not designed in the Unix philosophy

Observations

• Can't easily have correct app icons for different app versions
• Can't easily drag a document onto an application to open it
• Can't easily assign two files of the same MIME type to be opened with two different applications
• Can't easily handle application bundles (like .app, .AppDir, .AppImage, etc.)
• Can't easily handle applications that move around in the filesystem
• Can't easily handle applications that come and go on removable disks
• Lacks the concept of creator codes, telling the system which application a document was created with
• Logical objects (such as applications) scattered across different locations in the filesystem (e.g., desktop files, icons, etc.), making it hard to manage logical objects in the file manager
• Therefore essentially relies on package managers to be viable; not desktop-like at all
• Depends on legacy formats (.ini, .xml)
• Depends on overly complex and not thoroughly undocumented software (e.g., D-Bus)
• Is centered around how GLib works, but that is not how desktops in general should work
• Is centered around Linux rather than all Unix-like systems
• No concept of resources embedded into logical objects (e.g., icon embedded into ELF or icon inside an application bundle)
• Because the core concepts of how the logical objects that make up a desktop are not working properly, a lot of infrastructure has been built up around XDG, thus making it harded than needed for both developers and users

Haiku (inspired by BeOS)

To be written; see https://medium.com/@probonopd/my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6

Observations

• Concept of resources embedded into files
• Using extattr for caching information onto files and directories for fast and easy access

ravynOS/GNUstep (inspired by NeXTSTEP, OPENSETP, and Mac OS X)

To be written; see https://medium.com/@probonopd/my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6

Observations

• Works seamlessly
• Mechanisms partly undocumented, but can look at how GNUStep and ravynOS do things
• LaunchServices has an internal database which may be hard to keep in sync with reality; hence can we do better and keep most information on the locical objects themselves?
• Uses UTIs (Uniform Type Identifier); can be simpler and achieve the same just using MIME types?

ReactOS (inspired by Windows)

Observations

• Works more seamlessly than XDG

Approach

• Start from first principles - the objects that the desktop user experience consists of
• Think entirely independently of any particular existing desktop environment
• Propose simpler, more robust, more contemporary solutions for each of the XDG specifications, ideally in less than 10% of the length and complexity of the corresponding XDG specification
• Propose solutions for areas the XDG specifications fail to address

First Principles

Objects

User sees

• Applications
• Documents
• Folders
• Windows
• Icons

The system (also) sees

• Processes
• Files
• Directories

Verbs

• Launch an application
• Open a document (with an application)

Properties

• Each application has a version
• Different versions of the same application can coexist on the system
• Each document has a certain format (the MIME Type which describes the format of the content)
• Each document has been created by a particular application (the Creator)
• Applications have icons; different versions of the same application can have different icons
• Documents have icons; these describe the Creator and/or the format (a "GIMP PNG" may have a different icon than a "Krita PNG"
• Applications and Documents can be freely moved around in the file system using the file manager; they cannot be assumed to be at fixed locations in the filesystem

Associations

• By default, documents should be opened with the Creator
• Individual documents (not all document that happen to be in the same format) may need to be associated to different applications (or even application versions)