XDG Default Applications specification proposal

[elektra at markus-raab.org]

Dear XDG folks,

On 20.07.20 at 13:00 smcv at collabora.com wrote:
> On Thu, 16 Jul 2020 at 22:40:43 -0600, Thayne wrote:
>> and we should just put the
>> terminal launching command in a standard place like an
>> XDG_TERMINAL_LAUNCHER environment variable
> 
> I would prefer not to be doing this via environment variables. [...]

I fully agree here. Environment variables are heavily abused because
devs currently do not use a proper configuration library.

>> or in a $XDG_CONFIG_HOME/terminal-launcher.sh file.
> 
> I would prefer to avoid this, and in any case it doesn't address the need
> for a sensible per-desktop default.
> 
> I think it might be helpful to take a step back from the implementation
> and write down what the requirements are, so that proposed implementations
> can be judged against those requirements. Such as:

This sounds like a very good approach.

> * Reading the configuration format should not require linking to specific
>   implementation libraries

This is "not invented here".

Does anyone here actually care about the first sentence on the website
"https://www.freedesktop.org"? It reads: "freedesktop.org hosts the
development of free and open source software, focused on
interoperability and shared technology for open-source graphical and
desktop systems".


More useful requirements for a FLOSS ecosystem (where not most of the
time is lost in reinventing wheels) would be:

- API stability by version numbers
- API documentation exists
- lightweight and efficient implementation exists
- availability for popular distros
- easy-to-use API
- supportive community
- bugs are fixed promptly
- supports human-read/writeable configuration files
- several implementations in different languages exist

I would be interested which of these requirements XDG folks consider to
be important, or which requirements are missing.

>   - GLib isn't going to want to link to KDE libraries, Qt/KDE isn't going
>     to want to link to GNOME libraries, and neither is likely to want to
>     become dependent on some desktop-agnostic abstraction layer library
>     whose continued maintenance they cannot guarantee

KDE people were very open to accept libelektra as kconfig backend¹.
GSettings seems to be designed in a way, that, by using an
Elektra-backend, you can access desktop-agnostic configuration via
GSettings.

¹ https://www.libelektra.org/news/0.8.24-release  -> KDE Workshop

> Many of the requirements are the same as for MIME-type handling

Many are not enough, or are they only MAY requirements?

Ganz liebe Grüße,
-- 
Markus Raab          http://www.complang.tuwien.ac.at/raab/
TU Wien                   markus.raab at complang.tuwien.ac.at
Compilers and Languages          Phone:      +43 2619 21073
Argentinierstr. 8, 1040 Wien, Austria           DVR 0005886