Taking over xdg-utils

[Thayne]

I would be happy to test any of these scripts/libraries on i3 and sway.

Thayne McCombs

On Wed, Sep 2, 2020 at 7:19 PM Simon Lees <simon at simotek.net> wrote:
>
>
>
> On 8/30/20 6:53 AM, Piotr Karbowski wrote:
> > Hi Simon,
> >
> > On 26/08/2020 09.27, Simon Lees wrote:
> >> I am also interested in this, there are simply to many bugs related to
> >> shell quoting behavior etc that break something else when they get
> >> fixed. Unfortunately I have been moved into a different team at work for
> >> the next few months and don't have alot of time atm.
> >>
> >> When I did some initial research into the idea I planned to split the
> >> mime stuff out of pyxdg into a python-mime library and use that as well
> >> as creating a separate python library for things like
> >> desktop_file_to_binary etc Unfortunately I didn't get past the design stage.
> >>
> >> While I don't have much time in the next 6 months once you upload the
> >> code i'll happily review it and help test it on openSUSE.
> >
> > Will post to list with link to repository once at least basic feature
> > parity with current xdg-utils is achieved.
> >
> > My goal is to create a drop-in replacement for xdg-utils, while greatly
> > simplifying the logic. For example, xdg-open uses xdg-mime, and xdg-mime
> > have whole logic to choose what tool it should use to query for
> > mimetype, if there's kde, it will use kmimetypefinder, if there's gnome
> > it will use gio and fallback to gvfs-info, if it fail to detect DE, it
> > will use mimeinfo written in Perl instead.
> >
> > For this route the new xdg-mime will just use python-magic (bindings to
> > libmagic) regardless of what DE is running, as I really see no benefit
> > in using DE specific tools to query for mime, it will only result in
> > fragmentation and issues with reproducing bugs, as there's multiple code
> > paths.
> >
> > After you mentioned pyxdg I looked into it, from what I see it uses
> > rox-lib2's mime.py to query shared-mime-datebase, but in this case, I
> > think I will just stick to python-magic (libmagic) instead, as it seems
> > to be widely used already in other projects.
>
> I also share others concerns about this, and if its going to be a
> blocker for other people adopting the new python version then I think
> its worth reconsidering.
>
> The aim of having just one codepath that works with the mime database in
> a compliant way makes sense, my aim was to first have standards
> compliant python libraries for handling things like mime and desktop
> files that would also be useful for writing a xdg-utils replacement as
> well as other applications / scripts. If python-magic is already doing
> that I see no point in re inventing the wheel, If it is not and they are
> unwilling to implement a "compliant mode" then i'm back to being inf
> avor of creating python-mime from the old pyxdg codebase.
>
> What I'm less sure about is re-implementing  all of say xdg-terminal or
> xdg-su in python, in these cases it might make more sense to replace the
> "complex" logic such as desktop_file_to_binary with helper scripts
> written in python living in libexec and leave much of the rest in bash,
> I think it would be more complex to implement many parts of those
> scripts in python then it is in bash. It might also make the testing /
> migration path smoother.
>
> > If you have any other suggestions, comments or information, please let
> > me know, I plan to have a working PoC within few weeks (by working I
> > mean something that will work on my Gentoo for daily usage. :))
> >
> > -- Piotr.
>
> Yeah unfortunately for me I have to end up with working without
> regression on the 8-9 different desktops you can find in openSUSE, which
> includes making sure there various gui's for interacting with the mime
> database also still work.
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg