Revisit XDG .desktop files

[danshick]

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

It would be nice to consume an existing standard. Hopefully this issue can serve as a place to persist information on why or why not XDG desktop files might be a good fit.

Importantly, I think it is worth mentioning that there are two mechanisms to extend the recognized keys supported by the format:

Extending the format

If the standard is to be amended with a new {key,value} pair which should be applicable to all supporting parties, a group discussion will take place. This is the preferred method for introducing changes. If one particular party wishes to add a field for personal use, they should prefix the key with the string X-PRODUCT, e.g. X-NewDesktop-Foo, following the precedent set by other IETF and RFC standards.

Alternatively, fields can be placed in their own group, where they may then have arbitrary key names. If this is the case, the group should follow the scheme outlined above, i.e. [X-PRODUCT GROUPNAME] or something similar. These steps will avoid namespace clashes between different yet similar environments.

[Eeems]

Would we also want to support xdg-open and the MIME Applications spec?

[coozoo]

vote plus for desktop entry files well developed, it's easy to read, easy to capture in bash, easy to edit with text editor..
no need creepy yaml, no need sophisticated json structure

[Eeems]

creepy yaml? sophisticated json?

[coozoo]

creepy yaml? sophisticated json?

do you think it's not creepy to follow all indentations with text editor (I'm not talking about text processors or complete IDE). I should mention it's IMHO :)
I've just tried to setup github actions and simply screwed up with space at the end of string and wondered why nothing works.

About json, try to read it without jq from cosole :)

[Eeems]

creepy yaml? sophisticated json?

do you think it's not creepy to follow all indentations with text editor (I'm not talking about text processors or complete IDE). I should mention it's IMHO :)
I've just tried to setup github actions and simply screwed up with space at the end of string and wondered why nothing works.

I've done a lot of python programming, so whitespace stuff doesn't bother me.

About json, try to read it without jq from console :)

Why? That's what jq is there for. Just like you don't try to read image files directly from the console ;)

[coozoo]

I've done a lot of python programming, so whitespace stuff doesn't bother me.

Yeah I know ppl like you 😏 my eyes are bleeding when I'm editing python files with mcedit :)

Why? That's what jq is there for. Just like you don't try to read image files directly from the console ;)

there is small difference. Image files content is "binary", json still text and there is cases when you need to parse it directly :)

[Eeems]

mcedit

There's your problem ;)

there is small difference. Image files content is "binary", json still text and there is cases when you need to parse it directly :)

Wouldn't using jq still be a better option? I'm failing to see a scenario that you'd need to parse it directly.

[coozoo]

Wouldn't using jq still be a better option? I'm failing to see a scenario that you'd need to parse it directly.

jq usually needs to be installed it's not a part of posix. and remarkable by default without it as most of the systems.

[Eeems]

Right, but that's up to the application to list as a dependency and either require through toltec, or link to a binary.

[Eeems]

In theory desktop files should be easy to work with in Qt: https://gist.github.com/zester/1185753

[coozoo]

yeah it's not just in theory, it's really easy :) I can confirm, I'm not using it for desktop files. But I'm using QSettings often for app settings basically the same ini format.
I think it's more complicate to support features that they provide, like mime or translations sure if there is plans to implement them at all :)

[Eeems]

But I'm using QSettings often for app settings basically the same ini format.

Same here, reMarkable is as well.

I think it's more complicate to support features that they provide, like mime or translations sure if there is plans to implement them at all :)

Yeah, we'd probably just want to support a subset initially.

[matteodelabre]

Python also provides easy support for ini-like files. Could be handy for generating compat Draft & Oxide files from a Python script.
https://docs.python.org/3/library/configparser.html

EDIT: To be fair, it supports json just as well through https://docs.python.org/3/library/json.html

[coozoo]

here it's an old qt4 project there was some implementation maybe it can be helpful despite it is for qt4
https://github.com/radekp/qtmoko/blob/cdaa420a6675aa396c326b07122a853a9d5578a8/src/3rdparty/applications/qx/DesktopScanner.cpp

https://doc.qt.io/archives/qtextended4.4/desktopfiles.html

[Eeems]

One issue with using .desktop files is that existing applications in the *nix ecosystem use them, but expect to be running under X or Wayland. Since we currently are not working towards implementing either, it does cause some problems with having application entries show up that will never run.

On my reMarkable, I currently have two desktop files:

[raisjn]

One issue with using .desktop files is that existing applications in the *nix ecosystem use them, but expect to be running under X or Wayland. Since we currently are not working towards implementing either, it does cause some problems with having application entries show up that will never run.

from the spec:

This specification defines 3 types of desktop entries: Application (type 1), Link (type 2) and Directory (type 3). To allow the addition of new types in the future, implementations should ignore desktop entries with an unknown type.

so, if we wanted to, we could still use .desktop and the launchers will have to ignore .desktop files that are of the wrong type. (assuming we use a placeholder type)

[Eeems]

Do they allow custom types though, or are they assuming that new types should only be added by the official spec?

[danshick]

Do they allow custom types though, or are they assuming that new types should only be added by the official spec?

Even of we don't create a new type, we should probably define a custom group for all of our unofficial settings. The spec suggests the format [X-PRODUCT GROUPNAME] so maybe [X-Remarkable Settings].

If that group were missing, we could ignore the file. Also, we could even have a launchable setting in there. There are some toltec apps that shouldn't be listed by the launcher, like the restream binary.

[Eeems]

Even of we don't create a new type, we should probably define a custom group for all of our unofficial settings. The spec suggests the format [X-PRODUCT GROUPNAME] so maybe [X-Remarkable Settings].

I'd probably define one for all of the Oxide specific settings as well.

If that group were missing, we could ignore the file. Also, we could even have a launchable setting in there. There are some toltec apps that shouldn't be listed by the launcher, like the restream binary.

I think that ignoring everything without [X-reMarkable Settings] is a good idea. As for a launchable setting, likely not. If it's defining a desktop file, it's telling launchers that it can be launched. Otherwise it should just not define a file.

[matteodelabre]

Do they allow custom types though, or are they assuming that new types should only be added by the official spec?

As discussed during our meeting, it seems that the specification mandates parsers to allow for types other than the three currently documented ones. The concern voiced by @Eeems was that a future update of the standard could add a new type that happens to conflict with ours. Note that the standard recommends that custom field names be prefixed with X-ProductName. I think we could apply this recommendation to make a custom type. For example, it is pretty unlikely that a future extension would reserve the Type=X-reMarkable-app value.

[danshick]

I think we can stick to existing types for the predefined fields and run wild as long as we stick to our own X-Remarkable fields and groups.

Are there any standardized fields where a preexisting type doesn't fit for us?

[raisjn]

I think we can stick to existing types for the predefined fields and run wild as long as we stick to our own X-Remarkable fields and groups.

Are there any standardized fields where a preexisting type doesn't fit for us?

i believe systemd service files uses repeated keys for arrays, which i'm not sure is in this spec. additionally, there's no map type in this spec.

[Eeems]

For arrays I guess we can go with space or comma delimited.
We could emulate maps with the following though:

Map[Field0]=Value0
Map[Field1]=Value1

[danshick]

Some keys can have multiple values. In such a case, the value of the key is specified as a plural: for example, string(s). The multiple values should be separated by a semicolon and the value of the key may be optionally terminated by a semicolon. Trailing empty strings must always be terminated with a semicolon. Semicolons in these values need to be escaped using ;.

Example of multiple values ("arrays") would be the Actions key below:

[Desktop Entry]
Version=1.0
Type=Application
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
TryExec=fooview
Exec=fooview %F
Icon=fooview
MimeType=image/x-foo;
Actions=Gallery;Create;

[Desktop Action Gallery]
Exec=fooview --gallery
Name=Browse Gallery

[Desktop Action Create]
Exec=fooview --create-new 
Name=Create a new Foo!
Icon=fooview-new

[Evidlo]

There's something wrong at the end of your quoted text. The page says: Semicolons in these values need to be escaped using \;.

So the Actions line would be

Actions=Gallery\;Create;

And the final semicolon is optional (except when the value is empty, then it's required).

[Evidlo]

Actually it appears you copy pasted the example you gave from the spec, so maybe the sentence I'm referring to is a typo?

[danshick]

The semicolon is the separator. It only needs to be escaped if it should be a part of a single item.

[Evidlo]

Playing devil's advocate here for a moment to maybe introduce some new points to think about.

What do we concretely gain from using the XDG standard here for launcher entries? The standard is also a bit of an odd duck and parsers are obviously not as ubiquitous and popular as toml/ini/json. I can't find one for Lua for example.

I see three potential arguments for using XDG's spec:

1. Launcher icons will automatically work with Gnome/KDE/etc.

2. We can use existing .desktop files for non-reMarkable apps that have been ported.

3. Inventing a new standard requires work and thought and XDG is not that bad.

And counterarguments to these:

1. I think Gnome/KDE will never be a good experience on an e-ink tablet and thus won't gain traction. The very fact that three launchers have been developed for the rM to fill this void instead of porting existing desktop environments is evidence to this.

2. Looking through the list of projects on awesome-remarkable, I see 2 apps (Plato, KOReader) that were not specifically written to run on the reMarkable, and only KOReader already comes with a '.desktop'. Transcribing a .desktop file is trivial anyway.

3. We can easily pick-and-choose the ideas from the XDG spec that we want. The only actual work is agreeing on field names, and as mentioned previously the config can be in a format which is more popular and a little easier to parse.

[Evidlo]

I personally agree with 1, and 2, but I'm on the fence about 3.

[danshick]

I'm not 100% married to the idea either. Lack of parsers to me is the most valid criticism, but the format is painfully simple, which helps assuage my concerns there.

For me, the biggest benefits are these:

1.) It is far more trivial to port remarkable apps back to Linux, which makes existing desktop files useful.

2.) It also allows us to use xdg-open for automatic filetype association if we want to do so.

[raisjn]

something I posted on discord the other day:

---

let's say we create a new format (or use an existing one), called F. let's say it is extensible (launchers can have launcher specific options) and supports arrays, maps, etc.

if a launcher wants to add a custom option for an app to the app's launcher file, the app package has to be re-built and will cause re-download for everyone. for example, KOReader is 30MB (or whatever). this means that launcher specific option will cause package rebuilds, even if you don't use the launcher.

because of the above situation, i think the spec should be minimal and change very slowly. in order to reduce the amount of package updates for software, i even think that launchers should keep their own application specific config in a package like draft-app-config, oxide-app-config or remux-app-config and the launchers join their config data against the launcher data, using a unique ID for the application.

then the question becomes: how do launchers promote a shared config option into the shared spec.

---

some further clarifications and opinions:

• draft-app-config would be a package that contains all the extra config draft has for other apps. when any app's config changes, this package would get bumped. since the config is rather small (would be kilobytes) for all apps, thrashing this package is not as costly as thrashing apps with binaries in them (which can be megabytes for heavier ones, but usually only hundreds of KB)

• at this point, i prefer not to upgrade from the draft spec to something else because it is more dev work without clear gains (for me). the majority of this conversation started because of PR199 in toltec (and see this comment in particular for motivations: Oxide v2.1 toltec#199 (comment)). regardless of whether we create a new launcher format, oxide will need to have some way of having per app configuration kept outside of the shared launcher format. may as well start with implementing that first, then we can see what pieces are common or necessary for draft, remux, oxide and timower's launcher.

[raisjn]

thanks for the comments!

Yeah, launchers will probably always maintain their own configs/caches/settings/etc. I think that's already the case.

part of the question is how a launcher maintains per app settings out of the box as a default. if you look at PR199, koreader.oxide was checked in to the KOReader package because it has necessary customizations for running KOReader. which package should this file belong to?

2.) If all app configs for a given launcher are packaged under a single package, that's a lot of configs on my device I don't need or want (for apps I don't install). I know that they're small, but they are unnecessary noise that may confuse users at best. I'm not a fan of this all or nothing strategy.

ideally, it's only applications that have settings that are not defaults in their launcher. i mostly agree with your points 1, 3, 4.

[danshick]

Thanks for the constructive conversation. I'm glad everyone is open to the discussion.

part of the question is how a launcher maintains per app settings out of the box as a default. if you look at PR199, koreader.oxide was checked in to the KOReader package because it has necessary customizations for running KOReader. which package should this file belong to?

I've only briefly looked into the relevant oxide and fbink code, so I may have some misunderstanding, but here are my initial thoughts.

This one is somewhat unique because the launcher is, in effect, acting as a compositor of sorts, controlling when the application is and isn't on the screen. I suppose I'd start by asking how this is handled on other eInk devices that are capable of switching/multitasking.

Realistically, I'd suggest an IPC protocol or d-bus API that would provide this event data to all registered services. With a common standard for communicating these events, different launchers/device services could publish these events in a manner suited to their device and individual apps could consume and handle these events as they saw fit. I'm thinking of wayland-protocols as a conceptual model.

I know this one example illustrates a broader point regarding extensibility of a "desktop config", but I guess I'm arguing this is the wrong place to solve this specific problem.

ideally, it's only applications that have settings that are not defaults in their launcher. i mostly agree with your points 1, 3, 4.

This is better than I originally thought, but still a compromise IMO compared to something suited for the problem.

[dixonary]

There are two overlapping concerns here.

1. How do we ensure that app description files are flexible enough to support all common use cases?
2. How do we deal with bespoke requirements for individual launchers?

(1) is a matter of preference - in practise any solution we decide on will be good enough. (2) is a critical infrastructure decision and the more important one to nail down.

Realistically, I'd suggest an IPC protocol or d-bus API that would provide this event data to all registered services. With a common standard for communicating these events, [...]

This exists as part of oxide. I plan on building against it personally, but I don't think we should enforce that all launchers make use of it.

[dixonary]

To address some of the other important points above: I strongly feel that "interoperability" with desktop Linux is not an upside, and may actually be detrimental. The ecosystems are completely disjoint and I don't think we should start encouraging people to think otherwise.

[danshick]

This exists as part of oxide. I plan on building against it personally, but I don't think we should enforce that all launchers make use of it.

Oxide's approach is a good one, but you're right that it shouldn't be enforced because it isn't standardized (and even if it were, enforced is not how I'd frame it). I think an approach like this deserves documentation, discussion, and competing implementations validating its design before it is considered standard. It's also worth making the naming generic as well and managing its definition in a neutral repository.

For a device where only one application can write to the framebuffer at a time (for now, AFAIK, there are no true "compositors"), there really should be a standard way to broadcast what app is in the foreground and which aren't. There may be other such launcher info or events that apps may want to rely on uniformly.

To address some of the other important points above: I strongly feel that "interoperability" with desktop Linux is not an upside, and may actually be detrimental.

Without discussing the merits and detriments of thinking of the rM as a "Linux device", apps already are and will continue to be written that work for the remarkable and the Linux desktop. KOReader is one such example and they already ship a .desktop file.