XDG Default Applications specification proposal
elektra at markus-raab.org
elektra at markus-raab.org
Tue Jul 21 14:05:11 UTC 2020
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
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
¹ 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
More information about the xdg