xdg-utils 1.2.1 Release
Hi All, xdg-utils 1.2.1 contains three bugfixes found following the 1.2.0 release: * xdg-icon-resource: Fix for incorrect syntax * documentation: Proper quoting of _MANUALPAGE and _USAGE sections. * The version was not bumped from 1.2.0_beta in the internal scripts. For a full list of changes checkout the changelog https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/v1.2.1/ChangeLog?ref_type=tags https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.1 https://gitlab.freedesktop.org/xdg/xdg-utils/-/archive/v1.2.1/xdg-utils-v1.2.1.tar.bz2 -- 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 OpenPGP_signature.asc Description: OpenPGP digital signature
xdg-utils 1.2.0 Release
Hi All, xdg-utils 1.2.0 contains contributions from over 20 people (thankyou) some of the highlights are listed below. * better support for Plasma6, Deepin, LXQt * partial support for WSL / flatpak's * Numerous other fixes and improvements For a full list of changes checkout the changelog https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/v1.2.0/ChangeLog?ref_type=tags https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.0 https://gitlab.freedesktop.org/xdg/xdg-utils/-/archive/v1.2.0/xdg-utils-v1.2.0.tar.bz2 As a side note could someone with wiki permissions please update https://www.freedesktop.org/wiki/Software/xdg-utils/ to point to the new gitlab releases page. Thanks -- 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 OpenPGP_signature.asc Description: OpenPGP digital signature
xdg-utils 1.2.0-beta1 release
Hi All, I have created a test beta release of xdg-utils at [1] it contains contributions from over 20 people so thakyou to them. Some of the highlights are listed below. * better support for Plasma6, Deepin, LXQt * partial support for WSL / flatpak's * Numerous other fixes and improvements One of the main aim's with this beta release is to sort out any issues with the release process as it hasn't been done for quite some time. I have just let gitlab create the source tarball automatically, if people are happy with this I will just continue to do it this way because its simple. In that case we should update the release link on [2]. If people would prefer manual tarballs uploaded to the old location I am happy to do that (I have a copy of a tarball locally), someone will just need to show me how. If no one raises any major issues with the beta i'll aim for a full release in around 2 weeks time. Thanks 1. https://gitlab.freedesktop.org/xdg/xdg-utils/-/releases/v1.2.0-beta1 2. https://www.freedesktop.org/wiki/Software/xdg-utils/ -- 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Taking over xdg-utils
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Taking over xdg-utils
Hi On 8/26/20 1:17 AM, Piotr Karbowski wrote: > On 25/08/2020 16.54, David Edmundson wrote: >> >Project looks kind of abandoned and I'd like to pick it up, is there >> anyone who can pass the access to repository? >> >> If you want to pick a project up, don't keep asking for permission. I would >> start by reviewing everyone else's patches that are already there and other >> such >> tasks being proactive. You don't need access to do that. > > And how do you see that going? Like, go and review pending merge > requests, ack them or suggest changes and then... wait with a hope that > someone with access will actually notice it and grant the access so I > can actually merge them? Using this logic, my own merge request is > reviewed by myself, is very simple and sits there for over a year > already, not a great motivation to go and review something that no one > is going to merge. > > If there was anyone in the first place who would be willing to do > anything with the merge requests after they were reviewed, they would > already have done it. > > Out of frustration I already started rewrite of xdg-utils keeping it's > interface, in pure Python3, targeting >= 3.7, starting from xdg-open, > then will switch to another tool. Will be dropping it on github later, > once at least some UT are written. 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. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Taking over xdg-utils
Hi On 12/31/19 2:55 AM, Piotr Karbowski wrote: > Hi, > > It appears that xdg-utils is dead upstream, handful of merge requests > (mine including) rots waiting for comments/merge, no new commits being > pushed to repo either. > > I am considering forking xdg-utils and maintaining it for Gentoo, but it > could be much better if I could maintain the original project, if no one > else does, if possible so something beside Gentoo could benefit from it. > > I am not sure to whom should I reach, I've mailed a few people who's > commits recent in repo but did not got a single response. > > So, xdg list, how can one take over supposedly dead xdg-utils > maintainership? > I am the maintainer for SUSE / openSUSE, i've only had commit access for the last few months, but am working through some stuff, between other work but given travel and some other stuff coming up in January I probably won't get back to xdg-utils until feburary at the earliest. SUSE has a "hackweek" once or twice every year where they allow employee's a week to work on whatever projects they feel like, I believe the next one will be in February. Currently i'm planning to use most of that time to start working on porting the more complex parts into python. Especially parts that deal with parsing desktop files and mime database where there are already python libraries that can be utilized. From memory there are some other corner case bugs that can't really be fixed while using a posix compliant shell but that wont exist when using python api. At the same time there are parts of utilities like xdg-terminal that make more sense and are much simpler in shell, so I suspect the answer will end up being shell scripts that call out to python scripts that are just wrappers around a library. An example would be functions like desktop_file_to_binary etc. In the shorter term I haven't really looked at the release process because on openSUSE we have historically just taken "snapshots" from the git repo when it suites us since before I was maintainer so I haven't had as much motivation to look into what the official release process has been. I'll also review merge requests that are easy to merge (I should now atleast get email notifications for these and new issues). I also need to take the hour to sit down and learn how to manually merge commits with gitlab such as the one you have open. But i'm not sure i'll get this time in the next couple of weeks. It will likely depend on how I progress with writing the conference talk i'm working on. If I have enough permissions and no one objects in the next week I can try and give you some access although currently I only have "Developer" rights not "Maintainer" rights and I haven't looked at the differences. Cheers Simon -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple styles in icon themes and the future of the XDG icon specs
On 11/21/19 10:28 PM, Noah Davis wrote: > On 2019-11-20 01:04:29 EST, Simon Lees wrote: >> I think the simplest way to do this is to focus more on implementing it >> in the toolkits rather then by drastic changes to the desktop spec. >> Possibly the best way forward could be to teach toolkits to use two >> themes, the standard theme and the "application" theme (for lack of a >> better name). If the application theme is set then the toolkit would use >> it over the "main" theme for the elements you suggested such as buttons >> etc. You could then extend the button api etc with a flag that tells it >> to use the main theme instead. You could also add api to QApplication >> (or its equivalent) that specifies certain applications like maybe >> desktops should ignore the application theme. >> >> In a similar way to the way the current spec allows you to set a >> fallback theme for missing icons we could also extend it to specify a >> "application" theme that it could choose to use or not to use. >> >> If you were to then ship a breeze-monochorome theme that falls back to >> the breeze theme, users of toolkits that didn't support this new >> functionality could choose to use breeze-monochrome and have 95% of >> there icons looking right (with the exception of ones with conflicts). >> If a KDE user was to set gtk to use breeze-monochorome for example then >> pretty much all of there icons would look in place. > > Thank you for pointing me in the right direction, although I feel a little > out of my depth. I suppose there are probably some people I could talk to in > the KDE community that are already familiar with modifying Qt. > >> The default enlightenment / efl icon set is taking a similar stylistic >> approach but rather then using monochrome for most things like actions >> it uses a single shade of blue. > > That's quite interesting. Do you have any links I could follow to have a > closer look? Is this in the current released version? Here's one (the rest are easy to find) from the github mirror [1], its mostly used through the application toolkit but the actual desktop hasn't been completely swapped yet. From the screenshot of the desktop [2] the default UI is mid grey's with that color blue used everywhere as the only highlight color. 1. https://github.com/Enlightenment/efl/blob/master/data/elementary/themes/fdo/actions/128/document-print.png 2. https://www.enlightenment.org/_media/shot-enlightenment.png -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Multiple styles in icon themes and the future of the XDG icon specs
On 11/20/19 4:33 AM, Noah Davis wrote: > On 2019-11-19 09:32:21 EST, Bollinger, John C > wrote: >> What you're describing could be characterized as using different _themes_ >> for different parts of a GUI, and indeed, it may be that structuring your >> design around that idea would provide a way forward that benefits from >> reasonably good support from existing foundations. >> >> Do keep in mind, however, that one of the main objectives of themes is to >> provide UI elements that are consistent across applications and contexts. >> You may not remember the days when every application provided its own icons >> for everything, but it was needlessly painful and made everything harder to >> use. Consistent icon naming does support icon theme swapping, but that's a >> secondary consideration. > > Thank you for the suggestion. I didn't know that was possible, but I suppose > that makes sense. However, we'll still need to have a way to group the > monochrome and color themes together. The fact that there are 2 parts > (themes) to Breeze icons should be abstracted away when a user selects Breeze > icons in the system settings. It should also be possible for users to use > ungrouped themes like Oxygen and Papirus without any issues or additional > configuration. I'd also like it if Breeze icons could be a popular outside of > Plasma, but that's a lower priority goal than fixing this issue. > I think the simplest way to do this is to focus more on implementing it in the toolkits rather then by drastic changes to the desktop spec. Possibly the best way forward could be to teach toolkits to use two themes, the standard theme and the "application" theme (for lack of a better name). If the application theme is set then the toolkit would use it over the "main" theme for the elements you suggested such as buttons etc. You could then extend the button api etc with a flag that tells it to use the main theme instead. You could also add api to QApplication (or its equivalent) that specifies certain applications like maybe desktops should ignore the application theme. In a similar way to the way the current spec allows you to set a fallback theme for missing icons we could also extend it to specify a "application" theme that it could choose to use or not to use. If you were to then ship a breeze-monochorome theme that falls back to the breeze theme, users of toolkits that didn't support this new functionality could choose to use breeze-monochrome and have 95% of there icons looking right (with the exception of ones with conflicts). If a KDE user was to set gtk to use breeze-monochorome for example then pretty much all of there icons would look in place. The default enlightenment / efl icon set is taking a similar stylistic approach but rather then using monochrome for most things like actions it uses a single shade of blue. >> Consistency would not be impacted too badly by a multi-theme UI if the >> themes involved were appropriately designed for use together. For example, >> monochrome and full-color versions of the same icons would probably work >> together without too much friction, but even there you're stepping on user >> expectations: I predict that most users would suppose that there was some >> difference between the meaning of color and monochrome versions of an icon. >> In that particular case, in fact, I'd expect that some users would confuse >> the monochrome icons with icons for disabled actions. > > I'm not worried about this. Users these days seem to be pretty used to using > monochromatic icons for buttons/menus and nobody has complained yet about > monochrome icons looking like icons for disabled buttons. The color icons > give us an easier way to convey more information where it matters. For > instance, it's rather difficult to make unique mimetype icons without using > color. > In terms of disabled buttons etc, generally having a monochromatic icon at 50% (ish) grey is enough to show that something is disabled. In terms of mimetypes it doesn't sound like this proposal was planning to use monochromatic icons there. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils wants to be maintained or deprecated
Hi, On 8/14/19 4:22 AM, Dominik Schmidt wrote: Hi there, There are many issues and pending pull requests on the xdg-utils project. You should consider either maintaining or deprecating it. https://gitlab.freedesktop.org/xdg/xdg-utils/ It is maintained, just by not many people who are also very busy maintaining many other things, I'll try and go through the list of pull requests in the next couple of days. A few months back I went through and collected up all the patches that were in the bugtracker and submitted those. As for the issues most of them are very old, I tried to close a bunch that are no longer relevant a little while back but I don't have easy access to every desktop so I can't close all of them (help here is wanted). There are another bunch many of which that are to do with escaping that can't easily be fixed due to the fact that fixing them either breaks in an alternate shell such as dash or causes other things to break. Into the future I'm aiming to rewrite much of xdg-utils in python which should limit / remove some of these issues. Having said all that speaking with a SUSE / openSUSE distro hat on, xdg-utils is still a core desktop component and unless something else replaces it, it won't be depreciated any time soon. I suspect that with the move from the old location to gitlab some people who were getting notifications about new issues / pull requests are no longer doing so, which may not be helping the problem. I just updated my settings so that hopefully I now get notifications. 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
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
Depreciating xdg-file-dialog and xdg-copy (or supporting them properly)
Hi All, Having just looked through xdg-file-dialog and xdg-copy, they seem to only have partial support, with gnome*, cinnamon, lxde, mate, xfce and kde being supported while others including a "generic" option are not. Does anyone know of cases where these utilities are in use? or would it be safe to deprecate them and remove them in the xdg-utils rewrite. Providing a working implementation for enlightenment and LXQt is probably not a straight forward task. -- 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
Permission to close bugs in xdg-utils gitlab
Hi, I'm happy to go through and clean up some of the older bugs in the xdg-utils gitlab, atleast some of the imported bugs have been fixed and others may no longer be relevant. The only issue at the moment is I don't have permission to close bugs, if someone would like to give the user @simotek access that would be much appreciated. 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=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
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=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 Fi
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
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
Re: Discussion Proposal: Specifications about panels and widgets
On 07/11/2018 20:23, IFo Hancroft wrote: > What I am hoping to achieve with this, is widget and panel interoperability. > While this is possibly technically possible it would really require every desktop rewriting there widgets / panels to use the same modular plugin system, this would be much more complex given that currently even basic things like strings are done completely differently between toolkits it would be huge amounts of extra work with significant performance decreases, you then also need to look at sandboxing because a problem enlightenment has found is if your using C modules for this and one crashes it will tend to crash the whole desktop. So while this is technically possible I don't see any desktop developers agreeing then implementing something. > On 11/05/2018 02:54 PM, Simon McVittie wrote: >> On Mon, 05 Nov 2018 at 13:05:24 +0200, IFo Hancroft wrote: >>> It is not agreed on whether a panel should provide the taskbar/task >>> manager, menu, tray, widgets. >> This is a UX design question. If one desktop environment's designers >> think there should be a panel with a list of running applications (a >> taskbar), and another desktop environment's designers think there should >> not, then they are not going to agree on a specification that tries to >> require or forbid a taskbar: at least one set of designers would object >> to that specification. >> >> Desktop environments have different UI/UX designs, and that's a good >> thing, because different users have different preferences for the UI/UX >> they want to use. Some people want a panel with a taskbar, and they should >> choose a desktop environment that (at least optionally) provides one. >> Other people don't want a panel with a taskbar, and they should choose >> a desktop environment that (at least optionally) doesn't provide one. >> >> Similar considerations apply to various other UI/UX features. >> >> What is it that you aim for desktop environments to agree on? >> >> One of the major topics for freedesktop.org is arranging that an >> application that wants to do something can use the same code for multiple >> desktop environments (for instance, an application can get itself listed >> among other applications by installing a single .desktop file that works >> approximately the same in GNOME, KDE, etc., instead of having to install >> a .gnomeapp file and a .kdeapp file and so on). What application-facing >> functionality do you aim to standardize? >> >> (In particular, when an application installs a .desktop file, there is >> no guarantee that it will be presented in the same way in all desktop >> environments: KDE shows it among other apps in a hierarchical menu, >> whereas GNOME shows it among other apps in a flat, searchable list in >> the overview. Both are equally acceptable from the point of view of >> the Desktop Entry specification, and whether you prefer KDE's design or >> GNOME's design should be a factor in whether you choose to use KDE or >> GNOME or something else.) >> >> smcv >> ___ >> xdg mailing list >> xdg@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/xdg > > ___ > xdg mailing list > xdg@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/xdg > -- 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: Expand os-release spec with LOGO
On 08/10/2018 20:07, Lennart Poettering wrote:
> On So, 07.10.18 15:39, hel...@opensuse.org (hel...@opensuse.org) wrote:
>
>> Hi,
>>
>> A few months ago a discussion happened about changing display logo for Gnome
>> depending on os-release file [1].
>>
>> However spec [2] doesn't cover DEs wanting to add items to it, just OSes,
>> which
>> will still not be great, if support would have to be extended to SUSE_LOGO,
>> DEBIAN_LOGO, UBUNTU_LOGO etc.
>>
>> KDE does this by having that stuff specified in /etc/xdg/kcm-about-distrorc
>> [3],
>> which is not great, because again, it's kind of info that easily could be in
>> os-release for every DE and app that might need it. Both DEs require
>> information
>> about logo location, would be nice to provide it once, for all that might
>> require
>> it in the future.
>>
>> Suggestion I would give about it would be to allow for either full path or a
>> name to be used with xdg-icon standard.
>
> The man page (which is also the spec) os-release(5) is maintained as
> part of systemd btw, it's probably better to discuss this request in a
> github issue.
>
> The request generally makes sense to me, but I am a bit unsure about
> how this should actually look like.
>
> What value should the field take? Some options:
>
> 1. An embedded base64 blob? (probably not, might grow too large; also
>doesn't support multiple resolutions)
>
> 2. A path to some SVG or PNG file? (Not sure, might not be a good fit,
>as the path to a single bitmap probably wouldn't cover the
>necessities for multiple resolutions that well. Also, instead of
>embedded a file path in the os-release file, I think it would be
>more natural to simply define /{usr/lib|etc}/os-logo.{png|svg} or so
>instead, i.e. standardize the name and expect the same search path
>logic as for /{usr/lib|etc}/os-release itself.
>
> 3. A "named icon" according to the icon naming/theming specs?
>
> [https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
>and
>
> https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html]
>(this would solve the resolution problem, but maybe might be a bit
>overkill, a logo is not an icon after all, and "themed logos" are a
>weird concept...)
>
> Maybe a combination of option 3 and the os-logo.{png|svg} idea could
> work, so that downstreams can choose whether they want the
> comprehensive solution or the easy and slightly sloppy one.
>
I think 3 makes most sense, every desktop / toolkit has code for
handling fdo icons. 1 would be less then optimal given every desktop
will want to use it in a different size, enlightenment for example would
want 40px on its default shelf but a user could customize it to be as
small as 16 and on a high dpi display it could be substantially larger,
fdo already covers separate icons for those cases or svg. At the same
time i could see uses for it in certain dialogs at 256px.
I can't think of a common case where an image path would be easier then
a fdo icon. Other then obscure things like the terminology terminal
emulator supports inlining images so you could embed the distro icon as
part of a login welcome message.
--
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
signature.asc
Description: OpenPGP digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop-entry: make Icon field non-translatable?
On 10/09/2018 11:33, Matthias Klumpp wrote: > Am Mo., 10. Sep. 2018 um 03:09 Uhr schrieb Jeremy Bicha : >> >> Originally, the desktop-entry-spec set the Icon field as "string". It >> was changed in 2006 to "localestring" which means it is translatable. >> >> Recently in GNOME, many projects have switched from intltool to >> gettext. gettext treats the Icon field as a translatable string >> without a way for projects to disable that. In GNOME, we include a >> comment to warn translators not to translate the Icon field but >> translators sometimes don't see the comment. That causes breakage >> because no one is providing translated icons here. >> >> Could we please change the Icon field back to "string"? > > I just did a quick search whether the localization feature is actually > used much using Debian's package archive[1] and I only found two cases > which look like mistakes (the referenced icon did not exist). > I also wonder whether this feature is implemented in all desktop > environments... > > This issue looks more like a gettext issue than a specification issue > to me though. It should be changed to not consider the Icon field - > the field is not supposed to be translated by translation teams, > rather designers may specifically add a locale specific icon manually > if they designed it for the respective application. > So, IMHO this issue should be treated separately from any spec change. The way translation tools generally work is they don't have blacklists of strings not to translate but they pick out every string marked for translation, in this case i'm assuming gettext is presuming that everything of type "localestring" should be translated then things that are just normal "string" are not. Without knowing why it was changed in 2006, changing it back makes sense to me, there could be weird cornercases where some icons in some icon sets include text and the designer may want to do different icons for different languages but I doubt anyone is well setup to do that consistently anywhere at the moment. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Updating which specs have "pretty good" adoption
Here is the status from Enlightenment as far as i'm aware On 31/05/18 05:09, Thomas Kluyver wrote: > I'm working on updating the list of specifications here: > https://wiki.freedesktop.org/www/Specifications/ > > I think several of the specs listed as "not yet widely used" are now well > accepted, and could be upgraded to "pretty good adoption". In particular, > these specs describe files which are on my (Fedora+Gnome) system, and I'm > pretty sure I've been seeing some of the files around for several years: > > - Icon naming: > https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html Enlightenment is following the FDO specs here where possible I believe > - MIME application associations: > https://specifications.freedesktop.org/mime-apps-spec/latest/ Yes but only for stuff in the users home directory > - Sound themes: http://0pointer.de/public/sound-theme-spec.html No: Enlightenment (efl) ships its themes as single compressed binaries, all sounds are included as part of these themes > - Help: > https://wiki.freedesktop.org/www/Specifications/help-spec/help-system-spec.xml No: But mostly because enlightenment doesn't have a built in way of viewing help files, its help files go into the standard directory set by autotools > - Thumbnails: > https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html No > > Can anyone confirm which other desktops do or don't use each of those > specifications? And if you know, what version of the desktop added support > for them? > > I'm hoping to find that all major desktops have supported these specs for a > long time, which makes life easy. If that's not the case, we can figure out > what counts as "pretty good" adoption. > > Thanks, > Thomas -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Consider adding license information to freedesktop.org wiki contents?
On 06/05/18 21:25, rhkra...@gmail.com wrote: > On Sunday, May 06, 2018 05:49:15 AM Simon Lees wrote: >> if I wrote anything on the wiki which I don't think I did I would be >> more then happy for it to be relicensed under a BSD/MIT style license >> but would be less happy to allow because I don't think its the right >> license for the task. > > allow ___??? Sorry this is what happens when you get interrupted by kids, I was probably going to put some form of gpl in that blank as an example, but there are many different licenses I could list there instead. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Consider adding license information to freedesktop.org wiki contents?
On 06/05/18 20:06, Thomas Kluyver wrote: > On Sun, May 6, 2018, at 10:49 AM, Simon Lees wrote: >> The only way that I think we can realistically make the wiki situation >> better is by changing it now to say new changes are under the following >> license, then in 10 years hope that enough of the content has been >> changed that someone can delete all the remaining non licensed content >> then get someone else to fill in any gaps. > > I'm hoping it might also be possible to work at the level of individual > pages: find everyone who has contributed to a page and get their agreement to > put a license on it. In combination with agreeing a license for new changes, > of course. > That might work for the most part, then at least we'd just end up with a list of pages / sections of pages that need to be rewritten. >> If we were to go with the suggestion I wrote above >> there are many others who could make that change easier then myself who >> has no access. > > Do you know who these people are? Part of what makes this tricky is that I > don't even know who can do admin stuff on the wiki. Unfortunately not, I only started having an interest in this area over the last couple of years. > >> Either way if something is going to change there needs to be more >> discussion yet as no one has agreed on which license we would use, which >> you need to decide before contacting previous contributors. > > OK, let's try to move that forwards. I propose that we use the MIT license > for any code on the wiki, and CC-BY for text and any other non-code content. > These are equivalent in spirit, but MIT is written for source code. > Id agree that's reasonable. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Consider adding license information to freedesktop.org wiki contents?
On 06/05/18 17:40, Thomas Kluyver wrote: > On Sun, May 6, 2018, at 8:40 AM, Simon Lees wrote: >> Anyone >> who goes to the effort of editing a wiki knows and acknowledges that the >> content they have produced will be displayed on the wiki in its current >> form and are therefore giving permission for the content they have >> created to be redistributed by the wiki in its current form. > > I'm fine with this 'implicit license' approach, but it's precisely the sort > of grey area that other people insisted cannot possibly be allowed. > I am only fine with the 'implicit license' approach for the one area I mentioned (being distributed on the original wiki with the same access that existed at the time of writing. Unless someone can point me to a precedent that does otherwise. > It's frustrating that people have the time and energy to argue about > copyright, but nobody seems to be interested in doing anything to improve the > wiki. > The only way that I think we can realistically make the wiki situation better is by changing it now to say new changes are under the following license, then in 10 years hope that enough of the content has been changed that someone can delete all the remaining non licensed content then get someone else to fill in any gaps. (Note the person deleting the content really needs to be different from the people writing the new content, technically the people writing the new content probably should have never read the old content). I personally don't think any other approach is going to work, yes it sucks, which is why i'm not spending time on it. (but I won't stop you if you want to). If we were to go with the suggestion I wrote above there are many others who could make that change easier then myself who has no access. Where as contributing to this mailing list thread has taken not much more then 10 minutes of my Sunday afternoon. Either way if something is going to change there needs to be more discussion yet as no one has agreed on which license we would use, which you need to decide before contacting previous contributors. For example if I wrote anything on the wiki which I don't think I did I would be more then happy for it to be relicensed under a BSD/MIT style license but would be less happy to allow because I don't think its the right license for the task. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Consider adding license information to freedesktop.org wiki contents?
On 06/05/18 02:30, Thomas Kluyver wrote: > I also stole about 30 sheets of toilet paper from a hotel a few weeks ago. > Please, someone explain property law to me! > > More seriously, it's clear that my proposed solution is not going to fly, > because we're taking copyright Very Seriously. Since we are taking copyright > Very Seriously, there are two problems: > > 1. No-one can copy code samples from the wiki, or redistribute specifications > or anything, because they don't have a license. This is what the thread was > originally about, and it seems like a pretty major flaw for a body making > interoperability specifications for open source software. > 2. Whoever runs freedesktop.org is violating all the contributors' copyright > by redistributing the content they created, because you're not asked to grant > a license when you edit the wiki. > I am no legal expert and hence my wording may not be legally correct but the idea behind it stands. I suspect your #2 here is a non issue. Anyone who goes to the effort of editing a wiki knows and acknowledges that the content they have produced will be displayed on the wiki in its current form and are therefore giving permission for the content they have created to be redistributed by the wiki in its current form. If you were to take a private wiki and make its contents public then you have an issue because it was not reasonable for authors to expect that the content they created would become publicly available. If this did not hold then the issue would extend beyond wiki's into bugtrackers, forums etc -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: user languages
On 19/08/17 10:25, Mubarak AlQahtani wrote: > > Dear All, > > > One of the user's aspects is languages that he speak (or at least > understand), so is it mandatory for the operating system (i.e Desktop > environment softwares) to know the preferred languages ( defaults )?!! > > > As a programmer I prefer if the DE has some defaults info for each user. > not sure under what category it should be but its user's info. > > > Thanks > > > Mubarak AlQahtani > This can still be handled via the general locale handling so all a DE should have to do is query locale, see https://wiki.archlinux.org/index.php/locale#Overriding_system_locale_per_user_session -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Spec to define the default terminal?
On 05/25/2017 12:12 PM, Vladimir Kudrya wrote:
> Hello everyone!
>
> Any news on this?
>
> I'll expand my previous proposal of xsession-like approach:
>
> - Terminal emulators with their exec arguments should be described by
> desktop entries in /usr/share/x-terminal-emulators
> - Preferred terminal is configured in
> ${XDG_CONFIG_[HOME|DIRS]}/[$desktop-]x-terminal-emulator.list (hierarchy
> similar to the one in mime-apps-spec)
> - Format would be a simple newline-separated list of desktop entries.
> - Implementations should choose the first available entry in top
> priority config. Move to next priority config if not found. Last
> priority would be a list generated by `ls /usr/share/x-terminal-emulators`.
>
We already have the xdg-terminal binary which launches the terminal
based off the currently running desktop. I think a better approach would
be to integrate with that existing infrastructure, it could be modified
for example to check for the existence of a config file in 1 maybe
several dirs (I guess a sysadmin may want to configure a default
terminal for all his users).
That config file would contain the path to the terminal followed by the
exec command. This approach is less secure as someone could modify the
config file without you realising (I guess this could happen anyway).
I don't like the idea of describing exec arguments only somewhere in
/usr, it would mean that if I was working on a machine that I didn't
have root access to and I wanted to use some less popular or new
terminal that hadn't been added to the list yet I wouldn't be able to. I
also wouldn't be able to use a terminal that I had built from source in
my home dir and added to my path.
I also think in the days of the X11 / wayland transition prefixing the
config files with xdg- rather then x- is a better approach, I may be on
my own with that though.
Cheers
>
> 2015-11-03 16:47, Bastien Nocera пишет:
>> On Wed, 2015-10-21 at 19:30 +0200, Per Olofsson wrote:
>>> On 2015-10-20 15:10, Bastien Nocera wrote:
>>>>> Apparently GNOME removed the UI for choosing terminal so you have
>>>>> to
>>>>> use
>>>>> the gsettings command to change it.
>>>> No, it doesn't have anything to change it because nobody who might
>>>> care
>>>> has made the changes:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=627943
>>> I believe GNOME 2 had a UI for choosing the terminal emulator. But I
>>> guess the settings UI was completely rewritten in GNOME 3. Sorry.
>>>
>>>>> I was sceptical at first but now I think it might be a good idea,
>>>>> although strictly speaking it is an abuse of MIME types. It is
>>>>> similar
>>>>> to how URIs are handled, with x-scheme-handler/.
>>>> Not really. See the bug above.
>>> I can't find any argument in the bug report for why having a MIME
>>> type
>>> for terminals would be more wrong than x-scheme-handler. Only you
>>> stating so :-)
>> Both mime-type and scheme are metadata to the URL. I'd be fine having a
>> "x-scheme-handler/terminal" mime-type added if they could all handle
>> those URLs. They can't though.
>>
>>> But you're right, it is more of a stretch. At least x-scheme-handler
>>> is
>>> about applications opening stuff.
>>>
>> ___
>> xdg mailing list
>> xdg@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
--
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
signature.asc
Description: OpenPGP digital signature
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Questions about a unified API for file choosers (and platform/toolkit integration)
On 03/24/2017 08:00 AM, Roman Hargrave wrote: > > First off, I do hope this is the correct mailing list seeing as it's > the > one cited as being for general inquiries on freedesktop.org. > > Having got that out of the way, I was curious as to whether there had been any > discussion on a manner of general-purpose interface for file selector dialogs, > as they are one of the more frequently interacted-with non-control aspects of > the toolkits (GTK2/3, Qt, Wx, Enlightenment, etc..) in use today in building > applications and desktop environments on Linux. > > This question first came to mind when GTK3 replaced the type-ahead feature > with > a recursive search, at which point it became apparent to me that I would not > like to have to interact with that particular file chooser anymore. > > Unfortunately, due to the nature of file choosers and their toolkits, the user > is at the mercy of the toolkit developer, and GTK has decided that any ability > to change this behavior shall not be considered for inclusion. > Also, unfortunately, many very useful applications using these toolkits really > have no alternative (Gimp, Inkscape), and working on an alternative would be > counterproductive, to boot. > > Currently, some applications use DESKTOP_SESSION as a way to determine which > utilities and IPC facilities, etc, to interact with. Currently, the burden of > selecting the "correct" toolkit features is upon the application, and I have > encountered at least one application that seems to switch between the Qt or > GTK file picker based on the environment it runs in, so there is that. > > Now, if there were a toolkit-agnostic set of interfaces for applications > to call in to in order to prompt the user with the native file picker > instead of that which the toolkits use would have the advantage of insuring > that any settings applied by their desktop environment follow through to the > application experience, thus allowing users to, for instance, not be subjected > to, for instance GTK file picker if they would prefer to use the Qt picker. > > It would also allow for users to more efficiently use applications which have > an anemic file chooser by way of their toolkit (some older versions, i think, > of > fltk just present a listbox of files in PWD) - provided that the application > uses the interface rather than calling directly in to the toolkit. > > I would be interesting in writing an RFP if one does not already exist for > such > a thing, but was also primarily interested in fielding interest, as I know > that > there would probably be interest in being able to use a "better" (in some > folks > opinion) picker than say, the GTK picker, given what I've read in the rather > heated discussions on the GTK and Gnome bugzilla. > > I don't intend to attract ire from more seasoned XDG/Freedesktop folks, as I > know > Freedesktop isn't exactly a standards org, but it does seem like the most > appropriate > venue, to me at least. > > Feel free to point me elsewhere if you know of a better group for this. > There is a xdg-file-dialog, to go with xdg-terminal and friends but it seems to only support kde and zenity (gtk?) this seems close enough to what your looking for it would just be a matter of getting toolkits to use it rather then there own built in. Although you would probably want to extend some other areas as well for example there's currently no sensible option for enlightenment or lxqt. -- 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 signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
chromium-browser.desktop and desktop files with "-" in the filename
Hi All, I have been investigating https://bugs.freedesktop.org/show_bug.cgi?id=98562 (chromium-browser.desktop can not be set as the default browser). In the generic implementation desktop_file_to_binary is treating filenames with a "-" in the format vendor-app.desktop so it is searching for browser.desktop in a chromium directory, so my question here is should "-" be allowed in desktop file names in this context, if not there is a number of apps that are "broken" on this openSUSE tumbleweed machine without searching much. If not should desktop_file_to_binary be fixed in such a way to handle this and how should vendor directories be found. simon@host /usr/share/applications ➤ find -iname "*-*" ./YaST2/samba-server.desktop ./YaST2/services-manager.desktop ./YaST2/iscsi-client.desktop ./YaST2/relocation-server.desktop ./YaST2/virtualization-config.desktop ./YaST2/add-on.desktop ./YaST2/yast-language.desktop ./YaST2/samba-client.desktop ./YaST2/auth-client.desktop ./YaST2/ntp-client.desktop ./YaST2/http-server.desktop ./kde4/active-documentviewer_chm.desktop ./kde4/active-documentviewer_comicbook.desktop ./kde4/active-documentviewer_djvu.desktop ./kde4/active-documentviewer_dvi.desktop ./kde4/active-documentviewer_epub.desktop ./kde4/active-documentviewer_fax.desktop ./kde4/active-documentviewer_fb.desktop ./kde4/active-documentviewer_ghostview.desktop ./kde4/active-documentviewer_ooo.desktop ./kde4/active-documentviewer_pdf.desktop ./kde4/active-documentviewer_plucker.desktop ./kde4/active-documentviewer_tiff.desktop ./kde4/active-documentviewer_txt.desktop ./kde4/active-documentviewer_xps.desktop ./textmaker-free.desktop ./planmaker-free.desktop ./presentations-free.desktop ./gtk-recordmydesktop.desktop ./yast2-metapackage-handler-ymu.desktop ./yast2-metapackage-handler.desktop ./claudia-launcher.desktop ./projectM-jack.desktop ./git-gui.desktop ./simple-scan.desktop ./vivaldi-stable.desktop ./lxqt-config-powermanagement.desktop ./lxqt-config-session.desktop ./lxqt-hibernate.desktop ./lxqt-leave.desktop ./lxqt-lockscreen.desktop ./lxqt-logout.desktop ./lxqt-reboot.desktop ./lxqt-shutdown.desktop ./lxqt-suspend.desktop ./lxqt-config-notificationd.desktop ./lxqt-about.desktop ./lxqt-config-appearance.desktop ./lxqt-config-brightness.desktop ./lxqt-config-file-associations.desktop ./lxqt-config-input.desktop ./lxqt-config-locale.desktop ./lxqt-config-monitor.desktop ./lxqt-config.desktop ./lxqt-config-globalkeyshortcuts.desktop ./pcmanfm-qt-desktop-pref.desktop ./pcmanfm-qt.desktop ./chromium-bsu.desktop ./gnome-mimeapps.list ./pavucontrol-qt.desktop ./notification-daemon.desktop ./gnome-calculator.desktop ./geoclue-where-am-i.desktop ./gpk-prefs.desktop ./bluetooth-sendto.desktop ./uget-gtk.desktop ./gcr-prompter.desktop ./mount-archive.desktop ./nautilus-autorun-software.desktop ./nautilus-classic.desktop ./gcm-calibrate.desktop ./gcm-import.desktop ./gcm-picker.desktop ./gcr-viewer.desktop ./lximage-qt-screenshot.desktop ./lximage-qt.desktop ./ibus-setup.desktop ./xscreensaver-properties.desktop ./exo-file-manager.desktop ./exo-mail-reader.desktop ./exo-preferred-applications.desktop ./exo-terminal-emulator.desktop ./exo-web-browser.desktop ./itweb-settings.desktop ./xfce4-power-manager-settings.desktop ./xfce4-about.desktop ./xfce4-screenshooter.desktop ./claws-mail.desktop ./system-config-printer.desktop ./gnome-background-panel.desktop ./gnome-bluetooth-panel.desktop ./gnome-control-center.desktop ./gnome-datetime-panel.desktop ./gnome-display-panel.desktop ./gnome-info-panel.desktop ./gnome-keyboard-panel.desktop ./gnome-mouse-panel.desktop ./gnome-network-panel.desktop ./gnome-notifications-panel.desktop ./gnome-power-panel.desktop ./gnome-printers-panel.desktop ./gnome-privacy-panel.desktop ./gnome-region-panel.desktop ./gnome-search-panel.desktop ./gnome-sharing-panel.desktop ./gnome-sound-panel.desktop ./gnome-universal-access-panel.desktop ./gnome-user-accounts-panel.desktop ./gnome-wacom-panel.desktop ./gnome-online-accounts-panel.desktop ./gnome-color-panel.desktop ./gnome-shell-extension-prefs.desktop ./evolution-calendar.desktop ./chromium-browser.desktop ./org.kde.krusader.root-mode.desktop ./yast2-packager.desktop ./audio-assistant.desktop ./gtk3-icon-browser.desktop ./gtk3-demo.desktop ./gtk3-widget-factory.desktop ./gkbd-keyboard-display.desktop ./nm-connection-editor.desktop ./nm-applet.desktop ./vivaldi-snapshot.desktop -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: Patches for xdg-utils
On 11/01/2016 07:06 AM, Reuben Thomas wrote: > Dear xdg-utils maintainers, > > I have a slew of patches, of my own and from Debian/Ubuntu, which I'd > like to help get into xdg-utils while they're still fresh in my mind. > > Are any maintainers currently active and willing to help? > > I've opened bugs 98496, 98497, 98498, 98509 and 98519 to address these. > > Many thanks for your efforts! > > -- > http://rrt.sc3d.org > https://bugs.freedesktop.org/show_bug.cgi?id=98561 is the openSUSE patch for supporting Enlightenment and LXQt better, I have been meaning to upstream it for a while (I thought I upstreamed the enlightenment part over a year ago) -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-su: using gnomesu in the generic option if available.
On 08/27/2016 12:23 AM, Rex Dieter wrote: > PCMan wrote: > >> On Mon, Aug 8, 2016 at 1:11 PM, Simon Lees <sfl...@suse.de> wrote: >>> Hi All, >>> >>> I was answering an openSUSE bugtracker question re xdg-su and lxqt and >>> the most sensible solution we came to was modifying xdg-su's behavior >>> when running under a generic DE to use gnomesu or kde-su if they are >>> present so I thought i'd put the idea up for discussion in case anyone >>> objects. >>> >>> For reference currently lxqt doesn't have its own replacement for >>> gnomesu/kde-su (well not one I know of) distro's are also highly >>> unlikely to recommend either of those packages with lxqt as they will >>> bring in uneeded kde or gtk packages but by modifying the generic >>> fallback to atleast check for there existence first a user can then >>> choose to use one of them if they please. >> >> FYI, LXQt now provides its own tool, lxqt-sudo. >> https://github.com/lxde/lxqt-sudo >> However, I think pkexec is a reasonable fallback. >> Cheers! > > There are "reasons(tm)"(1) why xdg-utils doesn't install xdg-su by default, > though I wouldn't object to adopting patches to improve it either. > > My strong recommendation: just use pkexec (or engineer things to use > policykit natively). > > -- Rex > Coming from a distro where it does, I wrote a patch this week to enable lxqt support and improve enlightenment support in a couple of places there are a couple of things I have not implemented yet and that don't have a generic fallback (xdg-file-dialog, xdg-copy) are these actually used anywhere? Having mostly used enlightenment + openSUSE for the last few years which doesn't have a implementation i've never hit an issue from not having them but maybe other distro's use them more? Once that issue is sorted (or decided that it can wait) i'll have the patch ready to push. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
xdg-su: using gnomesu in the generic option if available.
Hi All, I was answering an openSUSE bugtracker question re xdg-su and lxqt and the most sensible solution we came to was modifying xdg-su's behavior when running under a generic DE to use gnomesu or kde-su if they are present so I thought i'd put the idea up for discussion in case anyone objects. For reference currently lxqt doesn't have its own replacement for gnomesu/kde-su (well not one I know of) distro's are also highly unlikely to recommend either of those packages with lxqt as they will bring in uneeded kde or gtk packages but by modifying the generic fallback to atleast check for there existence first a user can then choose to use one of them if they please. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org get off the air
On 10/03/2015 07:21 AM, Éric wrote: Just puzzled as to what the OP was trying to accomplish by his/her/its post. - Éric. The OP has a history of similar posts using various alias's to LKML, Debian and a bunch of other lists, all equally complaining about things that he does not agree with such as systemd and others that arn't worth mentioning. Usually he is quickly banned and comes back a few months later with a new email account. As such he's probably best just ignored. Cheers Simon On 10/02/15 14:50, noi...@a6.25u.com wrote: Hello, would you please consider to stop ruining the achivements of the Linux kernel-space with your user-space regressions? You are to operating systems (that uses the Linux kernel) what MTV was to music. Thank you so much for that. And those of you who have "good" intentions: You do not make professional operating systems (that uses the Linux kernel) appealing to unprofessional people without reinventing Windows badly. There is a clear majority of people who *do not care* about computers. And you want them to use operating systems (that uses the Linux kernel)? Just because they might like Windows less? Ridiculous. This is ridiculous. Dirk ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: $XDG_CURRENT_DESKTOP and the xdg-* commands
On 06/01/2015 04:21 AM, Jerome Leclanche wrote: Hi Just earlier a user encountered an issue with xdg-settings, which would complain about an unknown desktop environment. Looked in the code and sure enough, it hard-checks for $XDG_CURRENT_DESKTOP and actually only implements kde, gnome and xfce. All other DEs are implemented with a dispatch_generic which would be suitable for any DE, really. Seeing as we have generic functions in all xdg-* commands, cant we merely check whether XDG_CURRENT_DESKTOP is set at all, and if it is (and we dont have a specific function for the DE in question), use the generic one? Writing a new DE shouldn't require changing these tools. As long as we don't do nonstandard stuff, they should just work. J. Leclanche I agree 100% here, I fixed similar issues with xdg-su and xdg-terminal under enlightenment, someone implemented xdg-open which added a check for the DE and because they didn't know they had to add actions to the others it broke everything else. xdg-su and xdg-terminal also just use xterm so they should just work regardless of DE. From what I saw when fixing enlightenment i'm pretty sure there is atleast 1 place where one of the other smaller DE's is still broken. Cheers Simon Lees ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
