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)

Brainstorming

As of November 2022, this section reflects an ongoing thought process.

Philosophy

• KISS
• Unix philosophy
• Usable with existing POSIX/BSD/Xorg/... mechansims if possible
• Manipulate logical objects directly
• No separate databases or data directories to be taken care of, information should be kept on the logical objects themselves wherever possible

Desktop Metaphor

• Everything is an object that can and should be directly manipulated in the file manager (if it is on the filesystem) or in the menu (if it is a running application)
• Each object should be represented by exactly one file or directory in the filesystem si that it can be easily managed using the file manager
• Each object is shown in the GUI in one place, not multiple places (ideally)
• Drag-and-drop. E.g., documents can be dropped on applications to open them (if the application supports the MIME type)

Logical Objects

• Application at rest (on the filesystem). Should be trivial and fast to get its icon, name, supported MIME types, version, etc (e.g., using xattrs). When an application at rest is launched, the information regarding it is automatically mirrored to its unning application, identified by PID (e.g., using environment variables) and all of its running application windows identified by WId (e.g., using X11 atoms) to allow for trivially easy and blazing fast access
• Running application, identified by PID. Should be trivial and fast to get the above (e.g., using environment variables)
• Running application window, identified by WId. Should be trivial to get its PID and the above (e.g., using X11 atoms)
• Document (non-executable file) at rest (on the filesystem). Should be trivial and fast to get the application it should be opened with.
• Executable (executable file) at rest (on the filesystem). Should be trivial and fast to get the application it belongs to.
• A database that holds all applications known to the system. Possibly just the paths to the applications at rest. The database would be updated whenever an Application at rest would be encountered (e.g., file manager looks at an application, or the search indexer comes across one, or a thumbnailer encounters one; to be defined)
• A database that holds for each MIME type and for each URL scheme the preferred (default) application. How can this be made robust enough to allow for moving applications in the filesystem, while allowing for version changes? (E.g., open first tries to launch the application from its absolute path and if that fails, search the database that holds all applications known to the system for an application with the same name and the highest version? What is the proper thing to do here?)

Verbs

Verbs should be implemented as command line tools. Unix philosophy.

• launch
• open

Storing data on the logical objects themselves

• Keep metadata and state on the objects themselves, not in some obscure proxy location that also needs to be taken care of and can get out of sync (such as: thumbnails, .desktop files, .icon files outside of the application bundle, etc.)

• For files and directories, including non-running applications: Use extattr to store as much information about applications and files directly there as possible. Don't litter around icon files, desktop files, and whatnot in the filesystem. Don't construct cryptic paths like /home/user/.cache/thumbnails/normal/3c35889566ef588c871c4e1f324fa37a.png which are overcomplicated and error-prone

• For windows and running applications: Use X11 atoms to store as much information about applications and files directly there as possible. Only if it is missing, request it using procinfo -e and similar means.

Simplicity

• No indirections like g_filename_to_uri which only add complicatons. Just use Unix

Implementation

As of November 2022, this section reflects an ongoing thought process and describes ongoing implementation in helloSystem. The implementation currently is experimental in nature, and is subject to change at any time without prior notice.

launch.db

Information stored on windows

Example:

FreeBSD% xprop | grep -i Terminal
_EXECUTABLE_PATH(STRING) = "/Applications/Utilities/QTerminal.app/Resources/qterminal"
_ENV_LAUNCHED_BUNDLE(STRING) = "/Applications/Utilities/QTerminal.app"
WM_CLASS(STRING) = "qterminal", "qterminal"

• _EXECUTABLE_PATH: The path of the executable which has started the process which has created this window
• _ENV_LAUNCHED_BUNDLE: The content of the LAUNCHED_BUNDLE environment variable of the process which has created this window. The _ENV prefix indicates that this comes from an environment variable

Information stored on running processes

Information stored on applications (at rest)

Information stored on documents (at rest)