Hi!
I think I'll throw in a couple of thoughts about xdg-open, accumulated
over a long process of creating a custom KISS-oriented Openbox-based
environment for office and personal use.
The most paradoxical situation with xdg-open is that it is a mishmash of
DE-specific hacks condensed into a single script while there exists a
very flexible MIME Apps Spec that in theory covers DE-specific behavior
and interplay between DEs at the level of config hierarchy. Also the
current version of the Spec allows DE to be completely dynamic. In my
view the reason for the growth of workarounds in xdg-open is that
open_generic() function at times lagged behind the Spec and could not
provide needed flexibility. At times a new or custom DE had to de-facto
be "registered" in upstream xdg-open code to work. Given the state of
the Spec now this no longer should be needed.
If you, or anyone, are going to reimplement xdg-open, this would be a
great opportunity to drop DE-specific hacks in the code altogether and
force DEs to use '$desktop-mimeapps.list' elements of the config
hierarchy. Because things like hadcoding pcmanfm in open_lxde() look
really ugly.
If special logic would be needed anyway (and this should be officially
discouraged, IMHO), don't put it into xdg-open itself, but into
something like /lib/xdg-open/$desktop for xdg-open to hook on demand.
This would shift more power downstream and make packagers and admins happy.
On 28/02/2019 03.08, Simon Lees wrote:
Hi,
For those who don't know me, I am currently the xdg-utils maintainer
for SUSE / openSUSE.
Given that SUSE is in a year where where SUSE doesn't have any major
releases scheduled I have a bit of extra time, I am also sick of
fixing errors with desktop file / mime handling in posix shell. People
on this list have in the past discussed the idea of rewriting
xdg-utils in python oneday if someone has the time, I asked my manager
nicely and I now have the time. As such i've developed the very rough
plan below that i'll work on carrying out if there's a general
consensus here that its a sensible way forward. I have been allocated
a couple of hours a week to work on this.
Stage 1: Implement regression tests for the existing xdg-utils in
openSUSE's openqa instance, openqa.opensuse.org there is already
general testing for most desktops here but i'm planning to extend
these tests with more xdg-utils specific tests.
Stage 2: SUSE has a hackweek (https://hackweek.suse.com) once a year
where SUSE employees get a week to work on whatever they feel like.
The dates for this years have not been announced yet but my plan is to
spend most of that week doing the bulk of the rewrite.
Stage 3: Spend 2 hrs a week implementing the remaining code.
Stage 4: Submit a "beta" version into openSUSE Tumbleweed, given there
will already be regression tests in openqa by the point its accepted I
should be pretty confident that most of the major issues should have
been found and fixed.
Design:
Where ever possible i'm currently planning to use as much of the
existing pyxdg libraries especially for handling all the mime /
.desktop file handling.
In terms of a build system etc other then the thought that we should
use one I haven't put in much thought but i'm leaning towards setup.py
or meson but i'd really like to here anyone else's opinion.
I guess another thing to discuss is are there any of the tools that
are worth removing / not reimplementing because no one is using them
anymore?
Thats all thats floating around in my head atm, feel free to send
through your thoughts / suggestions.
Cheers
_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
