A path to xdg-utils2 in python

[Vladimir Kudrya]

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
>