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