A path to xdg-utils2 in python

[Simon Lees]

On 28/02/2019 20:36, Bastien Nocera wrote:
> Hey,
> 
> While I share your hate for the xdg-utils codebase, a couple of
> comments below.
> 
>> 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.
> 
> The freedesktop.org GitLab has a CI, you should add and run the tests
> upstream, against the current implementation, if you want to be sure to
> minimise the behavioural differences.
> 

I still plan to use the current CI tests but I see them being rather 
limited compared to the system level testing I can do in openqa which is 
far more useful. For example across 4-5 different desktops I can call 
xdg-terminal and check that the same terminal is launched, or can check 
that the right authenticator is used for xdg-su and that authentication 
succeeds or fails as it should. It can also do things like

>> 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.
> 
> You're probably underestimating the amount of work required.

Well whenever the week comes I will already have a plan and everything 
layed out and i'll know what I can pull in from existing python 
libraries. So I should be able to just sit down and write. Many of the 
tools are pretty simple although they have alot of boilerplate code and 
the complicated stuff which is the desktop and mime handling will 
hopefully mostly be coming from another already written library.

I'm not aiming to get everything done in that week but i'd like to get 
it to a point where the framework is there so I or other people can grab 
and do a small chunk thats still missing.
> 
>> 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.
> 
> For what it's worth, there's also an implementation for the .desktop
> and mime handling available in GLib, some of which are available
> through "gio mime" or "gio open". Those APIs are also usable from
> Python through gobject-introspection.
> 
> The current xdg-utils are unusable inside a sandbox, which is why xdg-
> open and xdg-email were replaced by portal clients:
> https://github.com/flatpak/flatpak-xdg-utils/tree/master/src
> 
> This might be something to keep in mind.
> 
> The other thing to keep in mind is all the tools in this list that
> aren't xdg-email or xdg-open still need to be reimplemented, or at
> least assessed.
> 
> You can use Debian's codesearch to find some of the uses:
> https://codesearch.debian.net/search?q=xdg-desktop-icon&perpkg=1
> 
> My own assessment would be:
> $ rpm -ql xdg-utils | grep bin
> # There are better installation methods than this, remove
> /usr/bin/xdg-desktop-icon
> /usr/bin/xdg-desktop-menu
> /usr/bin/xdg-icon-resource
> # Replace
> /usr/bin/xdg-email
> /usr/bin/xdg-open
> /usr/bin/xdg-mime
> # Only works with X11, nuke
> /usr/bin/xdg-screensaver
> # Does the same thing as xdg-mime for x-scheme-handler,
> # remove, or replace with xdg-mime code
> /usr/bin/xdg-settings
> 
> Whether with my Fedora, Flatpak, or GNOME hat on, my course of action
> would be to extend the above mentioned "flatpak" versions (xdg-email
> and xdg-open) to work outside the sandbox, and add an xdg-mime
> implementation. And have that replace the upstream xdg-utils.

Unfortunately it would still be nice if xdg-utils didn't require libgtk 
to be installed I know the number of systems these days that doesn't 
have it are minimal but it would still be nice.

I haven't really had anything to do with flatpack or any of the other 
sandboxing approaches are they still able to see / call 
/usr/bin/xdg-open? if so doing the dbus calls from python won't be hard 
in fact the version of xdg-open I have on my machines has an 
open_flatpak function which makes the following dbus call

gdbus call --session \
         --dest org.freedesktop.portal.Desktop \
         --object-path /org/freedesktop/portal/desktop \
         --method org.freedesktop.portal.OpenURI.OpenURI \
         "" "$1" {}

Outside of flatpak it still has alot of uses, I think some of the 
smaller desktops might even still be using it with a desktop file as the 
path to launch applications.

Cheers

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B