A path to xdg-utils2 in python

[Bastien Nocera]

On Fri, 2019-03-01 at 19:11 +1030, Simon Lees wrote:
> 
> 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

Like what?

You can run OpenQA in the upstream CI as well.

> > > 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.

Those tools don't use GTK.

> 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.

I'm sorry, but I have no idea what those comments correspond to.

But you seem set on wanting to rewrite xdg-utils in Python. Good luck.

Cheers