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