On 01/03/2019 19:53, Bastien Nocera wrote:
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.
Being able to run it is one thing, being able to maintain it is a
different issue though, everytime desktops are updated there are small
changes that tests need to be adapted, sometimes people get crazy ideas
and go we should change the default font or or a desktops theme, then
lots of tests need to be updated. I don't have time to maintain all the
tests for different desktops in the xdg-utils CI so it would just end up
mostly failing due to unrelated issues, however there are a number of
people that help maintain openSUSE's openqa instance including the
maintainers of the various desktops so the amount of effort to maintain
tests there is significantly lower. I believe other distro's are
starting to also use openQA so potentially I can add tests there as
well. I can probably also run xdg-utils git master against the tests on
a semi regular basis manually but I don't think I could automate it into
the xdg-utils
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'm aware that they don't currently, but to use the implementations via
gobject-introspection i'm guessing that it would require some of those
dependencies, I have no idea how GTK is split up these days and whether
Glib and GIO are part of it but when I was mentioning this I was
referring to GTK and its related libraries.
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.
Well I did consider some other alternatives I could use C++ with boost,
I dislike using the C and C++ standard libraries for string handling
enough that I don't think the result would be any better then posix
shell. I could do it really comfortably and cleanly using Qt's core
libraries but I don't think xdg-utils should require Qt in the same way
I don't think it should require gio. I think that python makes more
sense then perl because more people in general myself included find
python code easier to maintain. A python replacement has also been
discussed on this list before, if anyone has other suggestions for a
language i'm open to suggestions but atm python makes the most sense.
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
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
