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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg