Taking over xdg-utils

Piotr Karbowski piotr.karbowski at protonmail.ch
Sun Aug 30 14:57:10 UTC 2020


On 30/08/2020 16.40, Emmanuele Bassi wrote:
> That's the literal *opposite* of the correct approach: you must always start 
> from a compliant code, otherwise you're just writing something that is not 
> useful to people writing and consuming the freedesktop platform.
> 
> If a specification is unclear, or it's missing cases, then you need to fix the 
> specification. The freedesktop.org <http://freedesktop.org> specs might not be 
> strict standards, but the whole point of the fd.o effort is to have a shared 
> place where to collaborate; we have multiple implementations already of the 
> specifications, but what we're missing is a shared reference for people that are 
> either not using platform libraries such as GLib or Qt; or for people who are in 
> the process of writing new platform libraries. If you start ignoring stuff 
> because "it can be changed" at any later date, then you're simply not 
> collaborating, and you're just writing a bunch of code for yourself.

What I had on mind is that I am aware of the freedesktop specs and will
try to be complaint with them. However if anything of what I produce end
up not benig complaint in the end, it can be changed to be.

What is important here are the interfaces. xdg-mime is the interface
used by xdg-open, so as long as compatible interface is provided,
xdg-open can be developed, at this very moment my xdg-mime uses
python-magic, which as you stated, is not up to freedesktop's specs, so
it needs to be changed, however, shared-mime-info or libmagic, does not
matter for the xdg-open development, the (new) xdg-mime returns mime
type, and then (new) xdg-open can do it's thing.

> (...) If you start ignoring stuff
> because "it can be changed" at any later date, then you're simply not
> collaborating, and you're just writing a bunch of code for yourself.

I am sorry to hear that you see my effort as simply not collaborating,
and indeed I am writing a bunch of code for myself, because I am
generally unhappy with state of xdg-utils, and at the same time I put an
effort to make it in a way that it can overtake current xdg-utils, by
eventually be complaint with all the specifications. At no point I've
expressed that I will be intentionally ignoring any specification anyway...

-- Piotr.



More information about the xdg mailing list