Why does KDE (esp. Plasma) prefer .Desktop to data interchange formats that permit >2 levels of key-value depth?

Development
1

I didn’t ask this at an OS-wide forum [1] [2] because the formats utilised by the kernel [3] and common userspace utilities [4] frequently utilise entirely custom formats.

In contrast, every RC file I’ve interacted with in Plasma has utilised the FreeDesktop “.desktop” format (necessarily excepting CSS3 shims for GTK3+). I needn’t rehash here why most of the world has chosen JSON, YAML, XML, and TOML in the stead of .ini-like formats - the ability to nest values to arbitrary depths has been of significant use to any developer working with data interchange formats.

Consequently, why does Plama, and, more generally, KDE, continue to utilise the .desktop format for internal configuration files (that is, necessarily excepting applications:/)?

I don’t appear to be the sole person to have asked something similar. [5]

  1. discussion.fedoraproject.org ↩︎

  2. forums.opensuse.org ↩︎

  3. unix.stackexchange.com/q/732130 ↩︎

  4. superuser.com/posts/1849204/timeline#comment_2928210 ↩︎

  5. reddit.com/r/linux/comments/1y1ym2/comment/me5sdxp ↩︎

2

We use JSON in places where we do want or need multi-level data structures; you’ll see JSON files all over KDE git repos, especially in Plasma.

.desktop files are used in places where we don’t need that, and where the data needs to be displayed to the user somehow, because it’s a recognized standard in our world so there’s lots of developer familiarity with it and tooling to read and write it.

The single-level .ini style format used by our RC files likewise uses it mostly because we haven’t found a particular need for anything more.

Is there a particular problem you’ve encountered here, or are you just one of those people who ReallyJustLikesJSONaLot@hotmail.com? :wink:

1 Like
3

KDE predates most of these formats so the default format of the main API for config handling, KConfig, is one that was available at the time (and easier to handle than e.g. XML)

From a developer perspective it is actually a tree of entries.
Each “group” node is stored as a INI-style “section”.

For example if we look into plasma-org.kde.plasma.desktop-appletsrc we might see entries like this

[Containments][1][Configuration]
PreloadWeight=0

Which as a tree would look a bit like this

Containments 
|----1
     |----Configuration
          |---- PreloadWeight=0

As a “path” this could be written as /Containments/1/Configuration/PreloadWeight=0.
(this is how Qt handles tree inside INI)

3 Likes
4

@ngraham, I’ve encountered no problem with them, although I’m not quite either: I’ve no preference for XML, JSON, or YAML (although I pity whoever has to write the parsers for the latter). I merely can’t envision any benefit to restricting oneself to two layers of hierarchy, so I’m interested in what the cause is.

…I tend to dislike those who advocate for a technology without particular cause as much as I presume that you do.

5

@krake, evidently, I wasn’t familiar enough with the format. Thanks!

6

@krake I learned something too, thanks!

1 Like