Skip to content

Project "XDG ng"

Jump to bottom
probonopd edited this page Nov 5, 2022 · 25 revisions

PLEASE NOTE: This is work in progress. The project working title "XDG-ng" will change. This set of ideas and the potentially evolving set of specifications is intended to be a simpler but more powerful alternative to the XDG specifications. Implementations may opt to also implement a minimal amount XDG fallbacks for legacy support, although this is not mandatory.

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

  • SerenityOS (@awesomekling)
  • FyneDesk (@andydotxyz)
  • Draco Desktop Environment (@rodlie)
  • Redox OS? (@jackpot51)
  • ...

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

Might be good to get input from

  • Haiku
  • GNUstep
  • ravynOS (@mszoek)
  • ...

Basically all desktop environments that have overcome some or all of the issues of XDG.

Likely not interested

  • Red Hat, Fedora, GNOME, Gtk, Flatpak, Wayland (firmly in XDG land)
  • Unsure: 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

There is a wiki page which talks about user.creator extattr, but it doesn't seem it has become part of any XDG specification.

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

SQLite database used by the system to keep track of where applications are. Table applications has only one column that looks like this:

/usr/home/user/Applications/TextEdit.app
/usr/home/user/Applications/UBports Installer.app
/Applications/3D Printing/Ultimaker Cura.app
...
/usr/home/user/Downloads/Olive-cbfe4240-Linux-x86_64.AppImage
/usr/home/user/Downloads/Viper_Browser-1-x86_64.AppImage
/usr/home/user/Downloads/PhotoTeleport_0.13-0.AppImage
...
/usr/home/user/Applications/Linuxulator/Akira.AppDir
/usr/home/user/Applications/Linuxulator/Brave.AppDir
/usr/home/user/Applications/Linuxulator/IrScrutinizer.AppDir
...
# Debatable, for legacy XDG support
/usr/local/share/applications/gimp.desktop
/usr/local/share/applications/goland.desktop
  • Whenever the system "encounters" an application, it adds it to launch.db. "Encounters" can mean that the file manager requests a thumbnail for it, the launch command launches it, possibly the filesystem indexer sees it, etc.
  • Whenever launch tries to launch an entry in launch.db that doesn't exist on the filesystem, it removes the entry. Periodically all entries in launch.db may be checked to see whether they are orphaned
  • Debatable: How to handle removable disks

Information stored on windows

Currently implemented:

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

When an application is launched by the launch command, the following environment variables are set:

  • LAUNCHED_EXECUTABLE
  • LAUNCHED_BUNDLE

Information stored on applications (at rest)

Implemented in open:

  • can-open extattr with ; separated list of MIME types (mirrored to .app/Resources/can-open fallback file for robustness)

Not implemented yet:

  • version extattr

Whenever the system encounters an application in launch.db that doesn't have these extattrs set already, it shall set them based on the information contained in the fallback text file(s).

Information stored on documents (at rest)

Implemented in open:

  • open-with extattr

Not implemented yet:

  • Colors/emblems extattrs

Information stored on all kinds of files and directories (at rest)

Not implemented yet:

  • Thumbnails as extattrs
  • User-pasted icon as extattr
  • Window and icon positions as extattrs
  • is-bundle extattr. Speed up Filer. Whenever encountered, try to set bundle-path, bundle-exec, bundle-icon...

Fallback files for use with extattrs

Needed because not all file systems support extattrs, and we can't write on all volumes (e.g, read only, network shares,...)

Partly implemented:

  • Fallback files that mirror the filesystem hierarchy, on a local filesystem that supports extattrs, like Filer is using for storing window sizes
Clone this wiki locally