Re: A path to xdg-utils2 in python
Hi, On 28/02/2019 20:07, Thomas Kluyver wrote: Hi Simon, On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote: 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. As the not very active maintainer of PyXDG: much of the package is written in ways I would avoid for new code - e.g. it has its own ini file parsing instead of using the standard library configparser module. I'm wary of changing it because it's been around for a long time and people could be relying on all kinds of implementation details. But I wouldn't necessarily encourage you to use it for new code. If there's useful functionality in there, by all means make use of it. But you might be better off extracting and refactoring any code you want, either as internal modules for xdg-utils2 or as separately packaged parts. I can probably find some time to help with this if you like. When I first read your email, I thought about a parallel 'pyxdg2' project to produce a modern version of that code without compatibility constraints. But on further thought, I don't think it necessarily makes sense to bundle together the different functionality that's in PyXDG. Historically, the limitations of the Python packaging tools pushed us towards fewer, bigger packages incorporating disparate functionality, and PyXDG is exactly that. Now the tools have improved, it's more practical to have more focused packages - e.g. maybe desktop file handling could be its own package. In a couple of weeks i'll have 30ish hours allocated to make a start on this, my initial plan is to rewrite the "pyxdg" desktop file classes as "xdgdesktop" (i'm open to other naming suggestions) keeping the same API where possible but basing the class off configparser I will probably also add the desktopfile_to_binary and binary_to_desktopfile functions that are commonly used in the xdg-utils shell scripts as well. Having this functioning as a standalone library in a "beta" state that people could start using complete with updated test cases seems like a easily reachable goal. I guess another question that should be asked is should we drop anything thats no longer being used? I'm not especially familiar with what and how the KDE specific stuff is used and whether it is still relevant. Then the plan is to move onto xdgmime again I think its probably worth splitting all the mime handling out into a separate library (although i'm open to discussion), at a first glace the existing mime code seems reasonable although you as the author might have ideas about things that should change. I plan to extend the library to cover everything that the xdg-mime script currently does which will include stuff like setting and getting the default mimetypes etc, I guess these functions could go into a mimedatabase module. Beyond that I don't think it makes sense to split the other modules out, but I will tidy them up for example i'll drop the use of inifile and require python 3.3 so that some of the other work arounds can be removed. Beyond that i'll also add support for some of the common functions in the xdg-utils scripts such as detecting if a graphical server is running and detecting the desktop environment. After that the process of rewriting a lot of the command line tools shouldn't be too hard but I don't think i'll get there during the week I have this time, its something I will slowly do after. 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
Re: A path to xdg-utils2 in python
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
Re: A path to xdg-utils2 in python
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.
Re: A path to xdg-utils2 in python
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
___
Re: A path to xdg-utils2 in python
On 28/02/2019 20:07, Thomas Kluyver wrote: Hi Simon, On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote: 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. As the not very active maintainer of PyXDG: much of the package is written in ways I would avoid for new code - e.g. it has its own ini file parsing instead of using the standard library configparser module. I'm wary of changing it because it's been around for a long time and people could be relying on all kinds of implementation details. But I wouldn't necessarily encourage you to use it for new code. If there's useful functionality in there, by all means make use of it. But you might be better off extracting and refactoring any code you want, either as internal modules for xdg-utils2 or as separately packaged parts. I can probably find some time to help with this if you like. When I first read your email, I thought about a parallel 'pyxdg2' project to produce a modern version of that code without compatibility constraints. But on further thought, I don't think it necessarily makes sense to bundle together the different functionality that's in PyXDG. Historically, the limitations of the Python packaging tools pushed us towards fewer, bigger packages incorporating disparate functionality, and PyXDG is exactly that. Now the tools have improved, it's more practical to have more focused packages - e.g. maybe desktop file handling could be its own package. Best wishes, Thomas Hi, Certainly my initial thoughts before looking at what already exists was to create one library related to desktop file handling and another for handling mimetypes, because those parts are probably useful for other programs, then I was going to put all the other code shared between the various tools in an "Internal" library. So if you agree this is a good way forward why don't we work towards a series of libraries to replace the old one then, that way people can migrate as they choose. I'll get in touch when I'm closer to starting to writing code. It would be good to have a solid plan for what should be replaced, what should be reused / rewritten / dropped before I start. -- 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
Re: A path to xdg-utils2 in python
Hey, On Thu, 2019-02-28 at 10:38 +1030, Simon Lees wrote: > Hi, > > For those who don't know me, I am currently the xdg-utils maintainer > for > SUSE / openSUSE. > > Given that SUSE is in a year where where SUSE doesn't have any major > releases scheduled I have a bit of extra time, I am also sick of > fixing > errors with desktop file / mime handling in posix shell. People on > this > list have in the past discussed the idea of rewriting xdg-utils in > python oneday if someone has the time, I asked my manager nicely and > I > now have the time. As such i've developed the very rough plan below > that > i'll work on carrying out if there's a general consensus here that > its a > sensible way forward. I have been allocated a couple of hours a week > to > work on this. 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. dbusmock is a very useful tool to use if you want to implement the server-side of some of the tools for testing. > 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. > 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. Cheers ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: A path to xdg-utils2 in python
Hi Simon, On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote: > 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. As the not very active maintainer of PyXDG: much of the package is written in ways I would avoid for new code - e.g. it has its own ini file parsing instead of using the standard library configparser module. I'm wary of changing it because it's been around for a long time and people could be relying on all kinds of implementation details. But I wouldn't necessarily encourage you to use it for new code. If there's useful functionality in there, by all means make use of it. But you might be better off extracting and refactoring any code you want, either as internal modules for xdg-utils2 or as separately packaged parts. I can probably find some time to help with this if you like. When I first read your email, I thought about a parallel 'pyxdg2' project to produce a modern version of that code without compatibility constraints. But on further thought, I don't think it necessarily makes sense to bundle together the different functionality that's in PyXDG. Historically, the limitations of the Python packaging tools pushed us towards fewer, bigger packages incorporating disparate functionality, and PyXDG is exactly that. Now the tools have improved, it's more practical to have more focused packages - e.g. maybe desktop file handling could be its own package. Best wishes, Thomas ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: A path to xdg-utils2 in python
Hi! I think I'll throw in a couple of thoughts about xdg-open, accumulated over a long process of creating a custom KISS-oriented Openbox-based environment for office and personal use. The most paradoxical situation with xdg-open is that it is a mishmash of DE-specific hacks condensed into a single script while there exists a very flexible MIME Apps Spec that in theory covers DE-specific behavior and interplay between DEs at the level of config hierarchy. Also the current version of the Spec allows DE to be completely dynamic. In my view the reason for the growth of workarounds in xdg-open is that open_generic() function at times lagged behind the Spec and could not provide needed flexibility. At times a new or custom DE had to de-facto be "registered" in upstream xdg-open code to work. Given the state of the Spec now this no longer should be needed. If you, or anyone, are going to reimplement xdg-open, this would be a great opportunity to drop DE-specific hacks in the code altogether and force DEs to use '$desktop-mimeapps.list' elements of the config hierarchy. Because things like hadcoding pcmanfm in open_lxde() look really ugly. If special logic would be needed anyway (and this should be officially discouraged, IMHO), don't put it into xdg-open itself, but into something like /lib/xdg-open/$desktop for xdg-open to hook on demand. This would shift more power downstream and make packagers and admins happy. On 28/02/2019 03.08, Simon Lees wrote: Hi, For those who don't know me, I am currently the xdg-utils maintainer for SUSE / openSUSE. Given that SUSE is in a year where where SUSE doesn't have any major releases scheduled I have a bit of extra time, I am also sick of fixing errors with desktop file / mime handling in posix shell. People on this list have in the past discussed the idea of rewriting xdg-utils in python oneday if someone has the time, I asked my manager nicely and I now have the time. As such i've developed the very rough plan below that i'll work on carrying out if there's a general consensus here that its a sensible way forward. I have been allocated a couple of hours a week to work on this. 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. 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. 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. In terms of a build system etc other then the thought that we should use one I haven't put in much thought but i'm leaning towards setup.py or meson but i'd really like to here anyone else's opinion. I guess another thing to discuss is are there any of the tools that are worth removing / not reimplementing because no one is using them anymore? Thats all thats floating around in my head atm, feel free to send through your thoughts / suggestions. Cheers ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
A path to xdg-utils2 in python
Hi, For those who don't know me, I am currently the xdg-utils maintainer for SUSE / openSUSE. Given that SUSE is in a year where where SUSE doesn't have any major releases scheduled I have a bit of extra time, I am also sick of fixing errors with desktop file / mime handling in posix shell. People on this list have in the past discussed the idea of rewriting xdg-utils in python oneday if someone has the time, I asked my manager nicely and I now have the time. As such i've developed the very rough plan below that i'll work on carrying out if there's a general consensus here that its a sensible way forward. I have been allocated a couple of hours a week to work on this. 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. 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. 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. In terms of a build system etc other then the thought that we should use one I haven't put in much thought but i'm leaning towards setup.py or meson but i'd really like to here anyone else's opinion. I guess another thing to discuss is are there any of the tools that are worth removing / not reimplementing because no one is using them anymore? Thats all thats floating around in my head atm, feel free to send through your thoughts / suggestions. 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
