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