Re: Linux Malware
Le samedi 16 novembre 2013, à 17:48 -0800, Stephen Reichow a écrit : I know the hackers step up infection (they install zypper in OpenSuse for example.) Not sure what you meant here, but zypper is the default package manager in openSUSE. It's like yum on Fedora or apt-get on Debian, and it's obviously installed by default. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le mardi 22 janvier 2013, à 07:26 +, Jerome Leclanche a écrit : My most recent use case is the use of xdg dirs in some shipped .desktop files (eg. skype --dbpath=$XDG_DATA_HOME/skype) Just for the record: it might work for your setup, but there's no guarantee that $XDG_DATA_HOME is set. So if environment variables end up in the spec, this would be a good example of something that should be avoided ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le vendredi 18 janvier 2013, à 15:40 +, Jerome Leclanche a écrit : On Fri, Jan 18, 2013 at 12:08 PM, Vincent Untz vu...@gnome.org wrote: Le vendredi 18 janvier 2013, à 22:48 +1100, jupiter a écrit : The current issue is that adding an environment variable such as $HOME in desktop entry file as following example works with KDE file manager and Thunar when to click a desktop launcher (copy an application menu icon to the desktop), but does not work with nautilus, the error was Failed to change directory $HOME (No such file or directory) Path=$HOME There's no support for environment variables in the desktop entry spec, and therefore there's no guarantee that this will work on all implementations. We've hit the same issue at Razor a few times. Assuming we can get GNOME to implement envvar support in desktop files, would you be opposed to adding it to the spec? I really don't think it's good that currently half of the implementations can treat the same PATH differently. Nope, I wouldn't be opposed to it as long as it's well-defined, that many people see a use for it and that most desktops are happy with it. So I guess we need a proper patch and some convincing for some desktops. There's the question of backwards compatibility, but I guess not a lot of desktop files are using $. It might also be worth investigating which desktop environments (and base libraries, such as glib and qt) support this and which ones don't. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le vendredi 18 janvier 2013, à 22:48 +1100, jupiter a écrit : Can you give more details on the issues you hit? I was not able to list the application menu on desktop menu in gnome, but works on KDE and xfce. You mean, by right-clicking on the desktop (we don't have that in GNOME)? Or something else? I can tell you that GNOME does support the menu spec, for sure. The current issue is that adding an environment variable such as $HOME in desktop entry file as following example works with KDE file manager and Thunar when to click a desktop launcher (copy an application menu icon to the desktop), but does not work with nautilus, the error was Failed to change directory $HOME (No such file or directory) Path=$HOME There's no support for environment variables in the desktop entry spec, and therefore there's no guarantee that this will work on all implementations. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le vendredi 18 janvier 2013, à 23:27 +1100, jupiter a écrit : On 1/18/13, Vincent Untz vu...@gnome.org wrote: Le vendredi 18 janvier 2013, à 22:48 +1100, jupiter a écrit : Can you give more details on the issues you hit? I was not able to list the application menu on desktop menu in gnome, but works on KDE and xfce. You mean, by right-clicking on the desktop (we don't have that in GNOME)? Or something else? No, the application menu did not list in gnome desktop menu. I'm sorry, I still don't really understand the issue. Can you maybe provide a screenshot? Also, is the XDG_MENU_PREFIX environment variable set? [...] Path=$HOME There's no support for environment variables in the desktop entry spec, and therefore there's no guarantee that this will work on all implementations. But how do you set up the Path to your home working directory? When you log in your desktop, by default, the current working directory is $HOME. So your desktop has this as current directory, and therefore all apps started by your desktop will have this as current directory. So you shouldn't need it. (arguably, there will be some edge cases where this is not true, like if you restart part of your desktop from a terminal and the current directory is not $HOME there, but that's really edge cases) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le samedi 19 janvier 2013, à 00:01 +1100, jupiter a écrit : Speaking to terminal, I also have following error in nautilus which could not interpret the Terminal=true, and I don't want to use xterm, how to resolve that problem? (nautilus:3441): GLib-GIO-WARNING **: couldn't find a terminal, falling back to xterm See the code at http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c#n1036 Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Is gnome or nautilus fully compliant to freedesktop spec?
Le vendredi 18 janvier 2013, à 16:02 +1100, jupiter a écrit : Hi, A year ago, I started to implement application menus based on freedesktop spec, I could only get it work in xfce or kde, but not in gnome. After googling, I found some comments said that gnome is not fully compliant with freedesktop spec and it has bugs. Is it still the case today? Has anyone run application menus based on freedesktop spec in gnome? Can you give more details on the issues you hit? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: standards.freedesktop.or (Message sign� : Eric H.)
Hi, Le dimanche 16 d�cembre 2012, à 07:22 -, faispasie...@brefmail.com a �crit : I suggest that http://standards.freedesktop.org redirect to http://www.freedesktop.org/wiki/Specifications and not to a directory listing I think we should really just have some index.html page that we generate automatically instead. Using the Specifications wiki page could work, but it contains some other stuff and would need to be updated every now and then... Any volunteer? Note that we already have a script that generates most of the output on specifications.freedesktop.org: http://cgit.freedesktop.org/xdg/xdg-specs/tree/web-export Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Changes in Categories in the XDG Desktop Menu Specification
Le mercredi 24 octobre 2012, à 15:53 +0100, Thomas Kluyver a écrit : On 24 October 2012 14:04, Stanislav Brabec sbra...@suse.cz wrote: I am pleased to announce changes in Categories in the Desktop Menu Specification[1] that incorporated changes and proposals collected in last years in XDG list or Bugzilla. Please update your utilities and distribution menus to accept these new Categories. I've updated PyXDG: https://github.com/takluyver/pyxdg/commit/d7f23a55ce3bb07463f6de0289901e39b1f0265c Are more updates likely in the near future? If not, I'll aim for a new release soon with those changes in. I'm not aware of any changes that might go in soon; however, someone might want to take a look at the bugs in bugzilla for the spec and see if there are some of them that we can fix (product is Specifications). Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Battery icon names
Le jeudi 18 octobre 2012, à 17:50 +0100, Jerome Leclanche a écrit : We're hitting a small block on Razor: Battery icons seem to be missing from the icon-naming-spec. Theres battery, battery-low and battery-caution but that's simply not enough. https://bugs.freedesktop.org/show_bug.cgi?id=41458 deals with this. I would personally propose going a step further: Recommend checking for, for example at 32%, battery-32-charging and if it doesn't exist, fall back on battery-low-charging. That's just me though; it's not necessary to the spec and it would have the advantage of being backwards compatible with current one. Either way, any reason why the current patch hasnt been accepted? I think it's simply because nobody is actively maintaining the spec :/ Last commit was three years ago: http://cgit.freedesktop.org/xdg/default-icon-theme/log/spec/icon-naming-spec.xml Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: proposals for minor updates of menu-spec
Le mercredi 03 octobre 2012, à 16:13 +0200, Vincent Untz a écrit : Hi, Sorry for the late reply :/ I wanted to get to this earlier, but hten forgot... Le lundi 09 juillet 2012, à 20:45 +0200, Stanislav Brabec a écrit : Hallo. Here is a batch of minor updates in the menu-spec. All of them are pending in the Bugzilla for several years, and many of these proposals were already discussed in the XDG list. Move Science to Main Category: https://bugs.freedesktop.org/show_bug.cgi?id=20186#c1 Add Spirituality and Humanities: https://bugs.freedesktop.org/show_bug.cgi?id=20192#c5 Add Maps, clarify GIS: https://bugs.freedesktop.org/show_bug.cgi?id=20187#c1 Allow Network;Monitor: https://bugs.freedesktop.org/show_bug.cgi?id=49699#c2 Add Network;Feed and Network;NetworkService: https://bugs.freedesktop.org/show_bug.cgi?id=20197#c2 Add Game;Shooter: https://bugs.freedesktop.org/show_bug.cgi?id=38553#c1 One issue I can see with some of the patches is when you use, for instance, Education;Science for the related categories column. Note that this means and, not or. So I think what you want is Education or Science. I think we should clarify the spec and replace Education;Science with explicit Education and Science. I'll do that in a week or so, unless someone objects. The other change I don't like in your patches is NetworkService, which I feel is too vague and won't be helpful. I'm +1 for all other changes. Unless someone objects within a week, I'll push your patches. I pushed the patches to git, with the changes mentioned above. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Menu spec: main category requirement for the ProjectManagement additional category
Le mercredi 03 octobre 2012, à 16:21 +0200, Vincent Untz a écrit : Hi Alexandre, Le mardi 05 juin 2012, à 18:10 +0200, Alexandre Franke a écrit : Hi, As someone reported https://bugzilla.gnome.org/show_bug.cgi?id=677298 against the module I'm maintaining, we noticed that the menu spec requires applications with the ProjectManagement additional category to have Office;Development as main categories. We think this is a rather nonsensical requirement as project management applications such as Planner don't belong to the Development category. Could the spec be updated to require either one of those, but not necessarily both? Good point. This issue was raised for a few similar cases. Here's a patch to fix this. If nobody raises a -1, this will go in next week. Pushed to git, and can be seen at http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils: How to handle audio CDs?
Le lundi 01 octobre 2012, à 10:18 +0200, Paul Menzel a écrit : Even adding `x-scheme-handler/cdda` to the desktop file $ grep MimeType /usr/share/applications/rhythmbox-device.desktop MimeType=x-content/audio-player;x-content/audio-cdda;x-scheme-handler/cdda; and updating the MIME database $ sudo update-mime-database /usr/share/mime/ I think you need to call update-desktop-database, not update-mime-database. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils: How to handle audio CDs?
Le mardi 02 octobre 2012, à 16:29 +0200, Paul Menzel a écrit : Am Dienstag, den 02.10.2012, 16:14 +0200 schrieb Vincent Untz: Le lundi 01 octobre 2012, à 10:18 +0200, Paul Menzel a écrit : Even adding `x-scheme-handler/cdda` to the desktop file $ grep MimeType /usr/share/applications/rhythmbox-device.desktop MimeType=x-content/audio-player;x-content/audio-cdda;x-scheme-handler/cdda; and updating the MIME database $ sudo update-mime-database /usr/share/mime/ I think you need to call update-desktop-database, not update-mime-database. Thanks, but still no luck. $ grep cdda /usr/share/applications/rhythmbox-device.desktop MimeType=x-content/audio-player;x-content/audio-cdda;x-scheme-handler/cdda; $ update-desktop-database Warning in file /usr/share/applications/pcmanfm.desktop: usage of MIME type x-directory/normal is discouraged (x-directory is an old media type that should be replaced with a modern equivalent) Warning in file /usr/share/applications/gnumeric.desktop: usage of MIME type zz-application/zz-winassoc-xls is discouraged (zz-application/zz-winassoc-xls should be replaced with application/vnd.ms-excel) The databases in [/usr/local/share/applications, /usr/share/applications] could not be updated. $ xdg-mime query default x-scheme-handler/cdda $ sudo update-desktop-database Warning in file /usr/share/applications/pcmanfm.desktop: usage of MIME type x-directory/normal is discouraged (x-directory is an old media type that should be replaced with a modern equivalent) Warning in file /usr/share/applications/gnumeric.desktop: usage of MIME type zz-application/zz-winassoc-xls is discouraged (zz-application/zz-winassoc-xls should be replaced with application/vnd.ms-excel) $ xdg-mime query default x-scheme-handler/cdda $ Ah, right, xdg-mime looks at /usr/share/applications/defaults.list, and how this file is updated actually depends on the distro. This is unfortunately not covered by any spec. That being said, xdg-mime should probably fall back to looking at the content of /usr/share/applications/mimeinfo.cache and take one .desktop file from there if the mime type is present in there. This is https://bugs.freedesktop.org/show_bug.cgi?id=31629 Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg-utils: How to handle audio CDs?
Le mardi 02 octobre 2012, à 16:12 +0100, Jerome Leclanche a écrit : Vincent, In python-mime, I integrated both defaults.list and mimeinfo.cache: https://github.com/Adys/python-xdg/blob/master/xdg/actions.py#L119 I remember going through the spec and kind of having to take decisions in its stead; is the ordering I have reasonable? (See the comment) I don't know all the details about the MIME spec, but I'd recommend how it's implemented in glib and qt. For glib, see g_app_info_get_default_for_type() and get_all_desktop_entries_for_mime_type() in http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Keyrings, redux
Hi, Le mardi 21 août 2012, à 03:43 +0100, Jerome Leclanche a écrit : Googling xdg keyring brings this up: http://old.nabble.com/Unifying-KWallet-Gnome-Keyring-td19098909.html Has there ever been any effort towards this? This is something we're eventually going to hit in Razor, and I'd like to work on this if needs be. If there hasn't, what would be a good place to start? I don't exactly want to alienate gnome and kde in the process. There is a specification and a mailing list for this topic: http://specifications.freedesktop.org/secret-service/ http://lists.freedesktop.org/mailman/listinfo/authentication Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: update-desktop-database and nested desktop files
Le vendredi 17 août 2012, à 23:55 +0100, Jerome Leclanche a écrit : Thanks! After a quick talk on IRC, it seems the spec doesn't define which of the following has priority: wine/example.desktop or wine-example.desktop Instinctively I'm going to let it check wine-example.desktop first, but undefined behaviour is not good especially here, would be good to figure this one out. That's a good point. I think it's fair to say that wine-example.desktop would be the one used by default in that case. Do you want to cook a patch? The spec is in git at http://cgit.freedesktop.org/xdg/xdg-specs/tree/menu/menu-spec.xml (Note that the spec mentions that people should use vendor prefixes or directories to avoid such clashes, but of course, it's still possible to end up with the issue) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_MENU_PREFIX
Hi, Le vendredi 29 juin 2012, à 12:32 -0400, Dan Espen a écrit : I have questions about XDG_MENU_PREFIX as it appears in the spec. This appears to be a dash terminated prefix applied to the applications.menu. Yes. My Fedora system has a lot more menus than just the applications.menu. It has: /etc/xdg/menus/applications-gnome.menu /etc/xdg/menus/applications.menu /etc/xdg/menus/documentation.menu /etc/xdg/menus/gnomecc.menu /etc/xdg/menus/kde4-applications.menu /etc/xdg/menus/kde-information.menu /etc/xdg/menus/preferences.menu /etc/xdg/menus/server-settings.menu /etc/xdg/menus/settings.menu /etc/xdg/menus/start-here.menu /etc/xdg/menus/system-settings.menu As you can see, even the applications-gnome menu violates the XDG spec. It doesn't violate the spec. It's just a menu called applications-gnome instead of the applications menu with a XDG_MENU_PREFIX environment variable set to gnome-. Where is my: kde4-preferences.menu file? I just don't get the logic of having a standard for just the applications category. I believe the rationale is that only applications.menu is reserved by the spec, and XDG_MENU_PREFIX was a way to handle conflicts between different applications.menu shipped by different desktops. No other menu name is defined in the spec, and so we were instead relying on the fact that desktops would not create conflicts. That being said, I don't think I'd be opposed to using XDG_MENU_PREFIX for all .menu files. We should just make sure that it doesn't create any compatibility issue. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon names for browser and MUA
Hi, Le lundi 18 juin 2012, à 09:06 -0400, Rodney Dawes a écrit : No. There used to be similar names in the spec, but were removed as mail and browser apps are always branded things, and not generic utilities. And they need to be branded, so the user knows what to expect from the app. There's no good reason to have generic icons for them. Hrm, except that epiphany uses a rather generic web-browser icon... I guess you consider this is a bug in epiphany? Also, more importantly, there are several areas where it might make sense to have an icon for a web browser (for instance, in a UI to define the default web browser). Same for the mailer. Cheers, Vincent Ditën e Mon, 18/06/2012 më 10.29 +0200, Vincent Untz ka shkruar: (cc'ing Rodney and Alex, since they are the people who dealt with icon-related specs in the past) Le jeudi 07 juin 2012, à 11:49 +0200, Guido Berhoerster a écrit : Hi, is there any reason why there are no standard icon names for a browser and MUA in the XDG Icon Naming Spec? internet-web-browser/web-browser and internet-mail seem to be in use for that already, could these be added to the spec? Rodney, Alex, is this change fine with you? Can we go ahead and commit this to xdg/default-icon-theme? (I'm happy to get write access to the repo and do it if you want) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: PyXDG
Hi Thomas, Le mercredi 13 juin 2012, à 21:22 +0100, Thomas Kluyver a écrit : On 12 June 2012 23:01, Thomas Kluyver tho...@kluyver.me.uk wrote: I've put the changes I've got so far on Github - feel free to pull from there: https://github.com/takluyver/pyxdg/tree/update I've now got an account (thanks!), and I've pushed the changes to freedesktop git. It's in a separate branch until someone can do a bit of code review: http://cgit.freedesktop.org/xdg/pyxdg/?h=update Given that it seemed nobody else was stepping up for maintainership of pyxdg, I think you can just trust yourself, merge the branch, do a release and wait for bug reports from early users ;-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Icon names for browser and MUA
(cc'ing Rodney and Alex, since they are the people who dealt with icon-related specs in the past) Le jeudi 07 juin 2012, à 11:49 +0200, Guido Berhoerster a écrit : Hi, is there any reason why there are no standard icon names for a browser and MUA in the XDG Icon Naming Spec? internet-web-browser/web-browser and internet-mail seem to be in use for that already, could these be added to the spec? Rodney, Alex, is this change fine with you? Can we go ahead and commit this to xdg/default-icon-theme? (I'm happy to get write access to the repo and do it if you want) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: thumbnail: Modify to follow the XDG Basedir Spec
Le vendredi 11 mai 2012, à 14:54 +0200, Vincent Untz a écrit : Hi, There's a patch in [1] to change the thumbnail spec to use the xdg basedir spec to determine where to store thumbnails. Concretely, instead of using ~/.thumbnails, $XDG_CACHE_HOME/thumbnails is used (falling back to $HOME/.cache/thumbnails if $XDG_CACHE_HOME is not set). I'm attaching the patch here for easier review. Opinions? No -1 in a while, so pushed and published: http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: thumbnail: Modify to respect orientation tags
Le vendredi 11 mai 2012, à 09:45 -0400, Dr. Michael J. Chudobiak a écrit : Hi all, Here's another patch to consider for the thumbnail spec, requiring that thumbnailers respect the orientation tag in the image metadata, and encouraging the use of other image metadata (white balance, etc). https://bugs.freedesktop.org/show_bug.cgi?id=49798 Comments? No -1 in a while, so pushed and published: http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: thumbnail: Modify to skip unreadable files
Le vendredi 11 mai 2012, à 09:49 -0400, Dr. Michael J. Chudobiak a écrit : Hi all, Another patch to consider for the thumbnail spec, based on a discussion 4 years ago [1]. Basically, thumbnailers should not generated failed thumbnails for unreadable files, or they will remain un-thumbnail-able even if their permission are changed to make them readable. [1] http://www.mail-archive.com/xdg@lists.freedesktop.org/msg04016.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=49799 Comments? No -1 in a while, so pushed and published (with tiny edits): http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: PyXDG
Hi, Le vendredi 11 mai 2012, à 14:28 +0200, Vincent Untz a écrit : Le samedi 05 mai 2012, à 12:24 +0100, Thomas Kluyver a écrit : On 25 April 2012 12:38, Vincent Untz vu...@gnome.org wrote: We can migrate the CVS repo to git, and give you access if you're interested and nobody else steps up :-) Any news on this? I've got a local copy largely working with Python 3. I filed this bug to get a git repo created: https://bugs.freedesktop.org/show_bug.cgi?id=49793 We have the git repo now: http://cgit.freedesktop.org/xdg/pyxdg/ You'll likely want to request an account: http://www.freedesktop.org/wiki/AccountRequests (cc me on the bug you create so I can give a +1) Thomas, did you get an account? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Support for localized Exec entries, please
Le lundi 28 mai 2012, à 09:51 +0200, Ronny Standtke a écrit : Hi all, In addition to the difficulties with the proposed workaround for the Exec key, I currently see no workaround for the URL and NoDisplay keys. Can we please solve the issue the easy way by bringing the already existing wonderful flexibility of KDE into the spec? Is there any update on this? Is there any other process besides sending and discussing mails here to get the spec improved? No, there's no other process. Just submit a patch. But it was already pointed out that using a wrapper script would work too, and I personally consider this would be the right way to approach what you're trying to achieve. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding to Registered OnlyShowIn Environments
Le lundi 23 avril 2012, à 09:14 +0200, Vincent Untz a écrit : Le samedi 21 avril 2012, à 07:44 -0700, Darrell Anderson a écrit : Greetings, I am writing on behalf of the members of the Trinity Desktop Environment (TDE) project. TDE is a continuation of the KDE 3.5 desktop. We want to add TDE to the list of Registered OnlyShowIn Environments: http://standards.freedesktop.org/menu-spec/latest/apb.html Please let me know how to proceed further. Do you prefer TDE or Trinity to be registered? Any objection? If no, this will go in the spec next week. I was away for a bit, so it took more than a week ;-) But it's done now: http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#onlyshowin-registry I also updated desktop-file-utils. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Thumbnail spec in git
Le jeudi 26 avril 2012, à 10:19 +0200, Vincent Untz a écrit : Hi, I had totally forgotten about this, but Jens sent me a while ago the latest source of the thumbnail spec. I've pushed this to xdg-specs in a branch for now: http://cgit.freedesktop.org/xdg/xdg-specs/log/?h=thumbnail I'll merge that to master (and export it on the website) later on. Merged and exported: http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: PyXDG
Le samedi 05 mai 2012, à 12:24 +0100, Thomas Kluyver a écrit : On 25 April 2012 12:38, Vincent Untz vu...@gnome.org wrote: We can migrate the CVS repo to git, and give you access if you're interested and nobody else steps up :-) Any news on this? I've got a local copy largely working with Python 3. I filed this bug to get a git repo created: https://bugs.freedesktop.org/show_bug.cgi?id=49793 You'll likely want to request an account: http://www.freedesktop.org/wiki/AccountRequests (cc me on the bug you create so I can give a +1) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Thumbnail spec in git
Le vendredi 11 mai 2012, à 13:26 +0100, Jerome Leclanche a écrit : Couple of minor issues: that nearly every program introdues introduces Find a place for permanent storing. storage A few references to this missing file: http://specifications.freedesktop.org/images/note.gif Yes, I know. I simply imported the sgml file we had. Would be nice to fix it. Also, might be time to move .thumbnails to $XDG_CACHE_HOME/thumbnails ? There's a patch for this already, and was planning to start a thread in a few minutes ;-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RFC: thumbnail: Modify to follow the XDG Basedir Spec
Hi,
There's a patch in [1] to change the thumbnail spec to use the xdg
basedir spec to determine where to store thumbnails. Concretely, instead
of using ~/.thumbnails, $XDG_CACHE_HOME/thumbnails is used (falling back
to $HOME/.cache/thumbnails if $XDG_CACHE_HOME is not set).
I'm attaching the patch here for easier review.
Opinions?
Cheers,
Vincent
[1] https://bugs.freedesktop.org/show_bug.cgi?id=49607
--
Les gens heureux ne sont pas pressés.
From ff19cad2e2826a3a26056c816b994ae377e010c9 Mon Sep 17 00:00:00 2001
From: William Jon McCann jmcc...@redhat.com
Date: Mon, 30 Apr 2012 11:38:35 -0400
Subject: [PATCH] thumbnail: Modify to follow the XDG Basedir Spec
https://bugzilla.gnome.org/show_bug.cgi?id=646508
---
thumbnail/thumbnail-spec.sgml | 45 +
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/thumbnail/thumbnail-spec.sgml b/thumbnail/thumbnail-spec.sgml
index 576ffaf..41f81bf 100644
--- a/thumbnail/thumbnail-spec.sgml
+++ b/thumbnail/thumbnail-spec.sgml
@@ -3,8 +3,8 @@
article id=index
artheader
titleThumbnail Managing Standard/title
-releaseinfoVersion 0.7.0/releaseinfo
-dateSeptember 2004/date
+releaseinfoVersion 0.8.0/releaseinfo
+dateMay 2012/date
authorgroup
author
firstnameJens/firstname
@@ -30,6 +30,13 @@
sect1 id=history
titleHistory/title
itemizedlist
+listitemparaMay 2012, Version 0.8.0/para
+ itemizedlist
+ listitemparaModified to respect the
+ulink url=http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html;XDG
+Base Directory Specification/ulink/para/listitem
+ /itemizedlist
+/listitem
listitemparaSeptember 2004, Version 0.7.0/para
itemizedlist
listitemparaAdded readonly support for shared thumbnail repositories/para/listitem
@@ -166,20 +173,24 @@
sect1 id=directory
titleThumbnail Directory/title
-para There exists exactly one place where all generated thumbnails will
- be stored. This is the .thumbnails directory located in the users
- home. /para
+para For every user, there must be exactly one place where all generated thumbnails are
+ stored. This thumbnails directory is located in the user's
+ XDG Cache Home, as defined by the
+ ulink url=http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html;XDG
+ Base Directory Specification/ulink. Namely, if the environment variable $XDG_CACHE_HOME
+ is set and not blank then the directory $XDG_CACHE_HOME/thumbnails will be used, otherwise
+ $HOME/.cache/thumbnails will be used.
+/para
sect2 id=dirstructuretitleDirectory Structure/title
-para Within this dir there are living some other subdirectories showing
- in the following listing:
+para The thumbnails directory will have the following internal structure:
/para
programlisting
-~/.thumbnails/
-~/.thumbnails/normal
-~/.thumbnails/large/
-~/.thumbnails/fail/
+$XDG_CACHE_HOME/thumbnails/
+$XDG_CACHE_HOME/thumbnails/normal
+$XDG_CACHE_HOME/thumbnails/large/
+$XDG_CACHE_HOME/thumbnails/fail/
/programlisting
para The meaning of the directories are as follows:/para
itemizedlist
@@ -417,7 +428,7 @@
listitem
paraTo get the final filename for the thumbnail just append a '.png' to
the hash string. According to the dimension of the thumbnail you must store
-the result either in ~/.thumbnails/normal or ~/.thumbnails/large.
+the result either in $XDG_CACHE_HOME/thumbnails/normal or $XDG_CACHE_HOME/thumbnails/large.
/para
/listitem
/orderedlist
@@ -428,19 +439,19 @@
para
Consider we have a file ~/photos/me.png. We want to create a thumbnail with
a size of 128x128 pixel for it, which means it will be stored in the
-~/.thumbnails/normal directory. The absolute canonical URI for the file in
+$XDG_CACHE_HOME/thumbnails/normal directory. The absolute canonical URI for the file in
this example is file:///home/jens/photos/me.png.
/para
paraThe MD5 hash for the uri as a hex string is
c6ee772d9e49320e97ec29a7eb5b1697. Following the steps above this
results in the following final thumbnail path:/para
programlisting
-/home/jens/.thumbnails/normal/c6ee772d9e49320e97ec29a7eb5b1697.png
+/home/jens/.cache/thumbnails/normal/c6ee772d9e49320e97ec29a7eb5b1697.png
/programlisting
/example
sect2titlePermissions/title paraA few words regarding permissions:
-All the directories including the ~/.thumbnails directory must have set
+All the directories including the $XDG_CACHE_HOME/thumbnails directory must have set
their permissions to 700 (this means only the owner has read, write and
execute permissions, see man chmod for details). Similar, all the files
in the thumbnail directories should have set their permissions to 600. This
@@ -586,7 +597,7 @@ if (file.mtime != thumb.MTime) {
Thumbnail spec in git
Hi, I had totally forgotten about this, but Jens sent me a while ago the latest source of the thumbnail spec. I've pushed this to xdg-specs in a branch for now: http://cgit.freedesktop.org/xdg/xdg-specs/log/?h=thumbnail I'll merge that to master (and export it on the website) later on. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: PyXDG
Le mercredi 25 avril 2012, à 12:22 +0100, Thomas Kluyver a écrit : Hi all, Does anyone know who has control of the repository for PyXDG? It needs updating to work with Python 3. The files in the latest tarball suggest that the maintainer is Heinrich Wendel, but when I contacted him, he said that he was no longer involved, and didn't have access. The project was in CVS, but the web interface appears to be down. We can migrate the CVS repo to git, and give you access if you're interested and nobody else steps up :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding to Registered OnlyShowIn Environments
Le samedi 21 avril 2012, à 07:44 -0700, Darrell Anderson a écrit : Greetings, I am writing on behalf of the members of the Trinity Desktop Environment (TDE) project. TDE is a continuation of the KDE 3.5 desktop. We want to add TDE to the list of Registered OnlyShowIn Environments: http://standards.freedesktop.org/menu-spec/latest/apb.html Please let me know how to proceed further. Do you prefer TDE or Trinity to be registered? Any objection? If no, this will go in the spec next week. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Supporting mime types in desktop actions
Hi, Le mercredi 18 avril 2012, à 22:50 +0100, Jerome Leclanche a écrit : On Thu, Apr 5, 2012 at 7:42 AM, Jerome Leclanche adys...@gmail.com wrote: On Thu, Apr 5, 2012 at 7:33 AM, David Faure fa...@kde.org wrote: On Tuesday 03 April 2012 18:40:04 Jerome Leclanche wrote: Writing the intents spec, I found out that according to the desktop entry spec: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-lates t.html Desktop Actions do not support a MimeType key. Is there a solid reason why? I can't think of another reason than the need for it never popped up before. My use case: I have an image viewer and editor which supports viewing jpg and png, however it can only *edit* png files. The Edit action would then only support image/png while the main entry would support image/jpeg and image/png. One of the issues raised by supporting it is associating a mime type to an action (rather than a desktop file altogether). I propose the following syntax for mimeapps.list image/jpeg=myapp.desktop; image/png=myapp.desktop;myapp.desktop[Edit]; OK, but this also needs a fix in the desktop entry spec, right? For the case where the developer already knows in the first place that the app can only edit PNGs. Not sure I understand what you mean. But yes, the desktop entry spec would need an update... The MimeType key needs to be added to Table 3. Action Specific Keys. I also propose updating the example desktop entry file to display that behaviour. The syntax itself for mimeapps.list would not require an update as it's just a list of strings, although I don't think mimeapps.list actually has a spec anywhere. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 J. Leclanche Is there any more feedback on this? Where/how can I submit changes/get them accepted? The following would be nice: + a patch for the spec (living in xdg/xdg-specs in git.freedesktop.org) + a patch for desktop-file-utils (to update update-desktop-database) + possibly patches for Qt (I assume) and glib to handle the changes in the format of mimeinfo.cache/mimeapps.list It's a bit unclear to me how the old stacks will react to something like: image/png=myapp.desktop[Edit]; Will they just fail gracefully? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OpenRaster specification: possibly migrate to the fd.o wiki?
Le mercredi 11 avril 2012, à 10:59 +0100, Andrew Chadwick a écrit : On 26/03/12 13:29, Vincent Untz wrote: I see you went ahead and put things in the wiki, that's good :-) If you want to link the pages from Specification, I guess starting with the Draft specifications that are new and not yet widely used section is good enough. Have done :) I hope we're not generating too much noise. We may need some small inline images for demonstrating layer compositing modes. Would those typically be done as attachments? I guess so, yes. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: New category XFCE for menu-spec
Le mardi 03 avril 2012, à 18:14 +0200, Vincent Untz a écrit : So unless someone raises a valid objection within a week, I'll add the XFCE category to the spec. Done: http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#category-registry I also updated desktop-file-utils. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: make menu implementations tolerant of vendor changes
Hi, Le mercredi 11 avril 2012, à 15:32 -0400, Bill Nottingham a écrit : In Fedora, we've had the issue where some desktop files were incorrectly shipped with a vendor prefix. Due to the fact that the file name often is used as a key, we then are 'stuck' with either maintaining the bad vendor prefix indefinitely (potentially incompatibly with other distributors or upstreams), or changing the vendor prefix (breaking edited menus, user shortcuts, and so on.). One solution would be to have implementations be tolerant of vendor changes in desktop file names - if they don't find a file with the vendor prefix, to try again without the vendor prefix. Is this something that's worth adding as a recommendation for implementations via XDG, or are there better solutions? To be honest, my gut feeling is that Fedora should just bite the bullet and suffer for one release. It's much simpler than adding more complexity to the whole system. But assuming we'd want to add such a recommendation: how would the implementations know what is/was the vendor prefix? [1] What happens if there are more than one vendor prefix in use on the system (OS vendor + ISV)? Vincent [1] this might sound trivial if you assume your data stay on the same system, but people might share their data on systems from more than one vendor... -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: New category XFCE for menu-spec
Hi, Le mardi 13 mars 2012, à 13:19 +0200, Samuli Suominen a écrit : On 03/13/2012 01:08 PM, Samuli Suominen wrote: On 03/13/2012 12:17 PM, Vincent Untz wrote: Hi, Le mercredi 07 mars 2012, à 19:30 +0200, Samuli Suominen a écrit : Therefore I'm suggesting XFCE to be included in the http://standards.freedesktop.org/menu-spec/latest/apa.html The same way GNOME is there right now: GNOME Application based on GNOME libraries GTK XFCE Application based on XFCE libraries GTK May I ask what's the use case? I know that we have GNOME and KDE there, but I'm not even sure why we have them in the first place :-) [...] I've sent a patch years ago to the xscreensaver author (jwz) to add X-XFCE; in the xscreensaver-properties.desktop. When XFCE; or X-XFCE; is coupled with Settings; in Categories= the Xfce Settings Manager can show a icon of it: I chatted with Guido Berhoerster today. Apparently, what you describe here (filtering apps that will appear in xfce4-settings-manager, while still allowing those apps to appear in the applications menu in other desktops) is the main use case for XFCE. I think it's a valid use case (even though I'm not sure I like this approach, but that doesn't matter). So unless someone raises a valid objection within a week, I'll add the XFCE category to the spec. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: OpenRaster specification: possibly migrate to the fd.o wiki?
Hey hey, Le mercredi 21 mars 2012, à 22:29 +, Andrew Chadwick a écrit : Hello, fd.o! My first post here. I'm a developer working on an OpenRaster[0]-aware painting program [1], but I've become hampered recently by the loss of the CREATE project[2]'s wiki, which is where the working human-readable specification for OpenRaster was kept[3] until recently. I'm seeking to work on and extend the OpenRaster format in a couple of ways, but also to make the text of it publicly available to other developers for editing and improvement, and that's not possible with WayBack machine copies and a private SQL dump of the previous wiki's blurb! OpenRaster already exists as a FreeDesktop project, at least in the bug tracker[4] and has much running code and schemas[5] for the format's primary layers.xml file, plus support from two of the major graphics programs out there. However it has very little in the way of good, editable, public documentation and I'd like to change that, if I may. It seems to me that the right place to move the specification is somewhere under http://www.freedesktop.org/wiki/Specifications - would that be acceptable? I think OpenRaster meets the fd.o Mission Statement quite nicely. I'm new to fd.o, but given that all we need right now is a small amount of wiki space to host some explanations of the fields, what values they can take, and their meanings, presumably I should just add it in under http://www.freedesktop.org/wiki/Specifications ? Suggestions for the right section to use would be welcome. I see you went ahead and put things in the wiki, that's good :-) If you want to link the pages from Specification, I guess starting with the Draft specifications that are new and not yet widely used section is good enough. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: preferred-theme-spec - a spec for getting and setting default icon/cursor/sound themes
Le dimanche 25 mars 2012, à 21:47 +0100, Jerome Leclanche a écrit : Hi lists Followup on my previous post, this is my submission for a spec that stores default and fallback Icon, Cursor and Sound theme with the possibility of adding more themes or metadata to it. https://docs.google.com/document/d/1Slqk1yTFsiTBS0P8EnDcqp5G7sGmJ8SW7iQTdw7NUTs/edit I'm looking for more comments and would like to eventually get the process started on submitting it. It's unclear to me what's the exact goal of this spec: is it intended to be used by theme authors as a hint for desktop environments? Or is it intended to be used by desktop environments to store the theme preferences of the user? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: preferred-theme-spec - a spec for getting and setting default icon/cursor/sound themes
Le lundi 26 mars 2012, à 13:36 +0100, Jerome Leclanche a écrit : On Mon, Mar 26, 2012 at 1:33 PM, Vincent Untz vu...@gnome.org wrote: Le dimanche 25 mars 2012, à 21:47 +0100, Jerome Leclanche a écrit : Hi lists Followup on my previous post, this is my submission for a spec that stores default and fallback Icon, Cursor and Sound theme with the possibility of adding more themes or metadata to it. https://docs.google.com/document/d/1Slqk1yTFsiTBS0P8EnDcqp5G7sGmJ8SW7iQTdw7NUTs/edit I'm looking for more comments and would like to eventually get the process started on submitting it. It's unclear to me what's the exact goal of this spec: is it intended to be used by theme authors as a hint for desktop environments? Or is it intended to be used by desktop environments to store the theme preferences of the user? The latter. It's currently impossible to get/set default themes (unless you do it on an environment-per-environment basis), the spec solves that. I would think that the right way to get the themes would be through xsettings: http://specifications.freedesktop.org/xsettings-spec/xsettings-latest.html http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry (more settings could be added to the registry, if needed) As for setting the theme, don't all environments provide a tool to change the theme? Is your proposed spec intented to allow creating third-party tools, or to script changing the theme? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: preferred-theme-spec - a spec for getting and setting default icon/cursor/sound themes
Le lundi 26 mars 2012, à 14:53 +0100, Jerome Leclanche a écrit : On Mon, Mar 26, 2012 at 2:43 PM, Vincent Untz vu...@gnome.org wrote: [...] I would think that the right way to get the themes would be through xsettings: http://specifications.freedesktop.org/xsettings-spec/xsettings-latest.html http://www.freedesktop.org/wiki/Specifications/XSettingsRegistry (more settings could be added to the registry, if needed) [...] The issue is not just changing the theme, it's also getting it. This is an issue for libraries that provide tools to get file paths for a theme action (in this case, Qt's QIcon.fromTheme: http://qt-project.org/doc/qt-4.8/qicon.html#fromTheme). See my quote above about xsettings :-) And while it's true DEs provide custom ways to change the local theme, someone may wish to create a cross-platform cross-desktop one. I don't think may wish is something that we'll want to cover with a spec, to be honest. Unless there's a need acknowledged by people from various desktops, of course. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: preferred-theme-spec - a spec for getting and setting default icon/cursor/sound themes
Le mardi 27 mars 2012, à 00:21 +0800, PCMan a écrit : 1. Xsettings is a way to expose the settings to applications. It does not define how you store the settings. Yes, nobody said it was about storing the settings. 2. Xsettings, is actually used by gtk+ only. Though there is a KDE port, it's not part of KDE. In LXDE we support Xsettings simply because we're using gtk+. [...] 3. Every desktop of course has its own way to handle settings, but it's nice to have a common way to specify icon themes and cursors. There are many small programs which are not bound to a specific DE. They absolutely need this. Please, not everyone is using gnome. The purpose of freedesktop.org is to provide cross-desktop solutions rather than asking everyone to follow the design of the largest and most famous DE. Hrm, but xsettings is already a xdg spec. That was my point. We can have a competing spec, but unless there's a real investigation as to why xsettings is not used everywhere, I don't see why the competing spec would be more successful. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org trash-spec links broken
Le jeudi 15 mars 2012, à 10:16 +0100, David Faure a écrit : On Wednesday 14 March 2012 18:04:04 Vincent Untz wrote: Le mercredi 14 mars 2012, à 17:41 +0100, David Faure a écrit : On Tuesday 13 March 2012 11:16:43 Vincent Untz wrote: Le mardi 13 mars 2012, à 11:05 +0100, David Faure a écrit : I'm a bit confused because for other specs in git it looks like there's just the latest file, but on the website there are older versions. So I suppose the web site is maintained manually, with copies of old specs? Nope, we use the git history to fetch old versions. See files in http://cgit.freedesktop.org/xdg/xdg-specs/tree/web-export Ah! Funky. OK, I did that too. Can you run the script on the website? I suppose that's the part I can't do myself. Thanks for doing the import! It's now online: http://specifications.freedesktop.org/trash-spec/trashspec-latest.html Thanks! This showed me a bug (version number), which I just fixed in git. Will the online version be updated automatically, or do you need to run the script by hand every time? Right now, we need to manually run the script. If you have an account on gabe and are in the standards group, it's just a matter of doing this: cd /srv/specifications.freedesktop.org/www ../update.py (it's important to be in the right directory) I guess we could add a post-commit hook, or a cron job, though. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org trash-spec links broken
Le mercredi 14 mars 2012, à 17:41 +0100, David Faure a écrit : On Tuesday 13 March 2012 11:16:43 Vincent Untz wrote: Le mardi 13 mars 2012, à 11:05 +0100, David Faure a écrit : I'm a bit confused because for other specs in git it looks like there's just the latest file, but on the website there are older versions. So I suppose the web site is maintained manually, with copies of old specs? Nope, we use the git history to fetch old versions. See files in http://cgit.freedesktop.org/xdg/xdg-specs/tree/web-export Ah! Funky. OK, I did that too. Can you run the script on the website? I suppose that's the part I can't do myself. Thanks for doing the import! It's now online: http://specifications.freedesktop.org/trash-spec/trashspec-latest.html Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org trash-spec links broken
Le mardi 13 mars 2012, à 11:05 +0100, David Faure a écrit : On Wednesday 07 March 2012 18:36:36 Mikhail Ramendik wrote: Sorry it took me so long! But I did eventually dig into my old archives and found all old versions of the spec. Zipped and attached. Archive: /tmp/trashspec_versions.zip Length DateTimeName - -- - 15345 2009-09-27 03:36 trashspec.0.1.html 16177 2009-09-27 03:36 trashspec.0.2.html 25453 2009-09-27 03:36 trashspec.0.3.html 25242 2009-09-27 03:36 trashspec.0.4.html 25307 2009-09-27 03:36 trashspec.0.5.html 25514 2009-09-27 03:36 trashspec.0.6.html 25722 2009-09-27 03:36 trashspec.0.7.html 25722 2009-09-27 03:36 trashspec.html - --- 184482 8 files Question for the xdg-specs people: shall I import this as consecutive revisions of the same file? Or shall I import it as is, one file per version? Consecutive revisions of the same file is better. I'm a bit confused because for other specs in git it looks like there's just the latest file, but on the website there are older versions. So I suppose the web site is maintained manually, with copies of old specs? Nope, we use the git history to fetch old versions. See files in http://cgit.freedesktop.org/xdg/xdg-specs/tree/web-export Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: New category XFCE for menu-spec
Hi, Le mercredi 07 mars 2012, à 19:30 +0200, Samuli Suominen a écrit : I've started seeing these with latest Xfce git: * /usr/share/applications/example.desktop: value XFCE;GTK;Settings;DesktopSettings;X-XFCE-SettingsDialog;X-XFCE-SystemSettings; for key Categories in group Desktop Entry contains an unregistered value XFCE; values extending the format should start with X- And I've discussed it at #xfce-dev on Freenode with 2 developers and the response was that this won't be changing and it's correct. Therefore I'm suggesting XFCE to be included in the http://standards.freedesktop.org/menu-spec/latest/apa.html The same way GNOME is there right now: GNOME Application based on GNOME librariesGTK XFCEApplication based on XFCE libraries GTK May I ask what's the use case? I know that we have GNOME and KDE there, but I'm not even sure why we have them in the first place :-) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg xembed specs broken?
Le vendredi 02 mars 2012, à 11:03 +0100, Mikkel Kamstrup Erlandsen a écrit : Is it just me or is there no human readable version of the xembed spec available? http://standards.freedesktop.org/xembed-spec/ does not contain any document that can be rendered in the browser. Yeah, it's a known issue caused by the fact that cvs.freedesktop.org went offline, see https://bugs.freedesktop.org/show_bug.cgi?id=45184 I need to find the scripts I used to import files from cvs in the git repo, and then it'll get fixed. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdg xembed specs broken?
Le vendredi 02 mars 2012, à 11:37 -0500, Owen Taylor a écrit : On Fri, 2012-03-02 at 16:37 +0100, Vincent Untz wrote: Le vendredi 02 mars 2012, à 14:36 +0100, Vincent Untz a écrit : Le vendredi 02 mars 2012, à 11:03 +0100, Mikkel Kamstrup Erlandsen a écrit : Is it just me or is there no human readable version of the xembed spec available? http://standards.freedesktop.org/xembed-spec/ does not contain any document that can be rendered in the browser. Yeah, it's a known issue caused by the fact that cvs.freedesktop.org went offline, see https://bugs.freedesktop.org/show_bug.cgi?id=45184 I need to find the scripts I used to import files from cvs in the git repo, and then it'll get fixed. I went ahead and did a test import of the clipboard-related specs, recent-files, xembed and xsettings. This is all available at http://cgit.freedesktop.org/xdg/xdg-specs/log/?h=wip/cvs-import Owen, are you fine with xembed and xsettings living in xdg-specs? Yeah, no problem with that. Cool, I've merged the branch. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending the Desktop Entry spec for static app actions
Le lundi 06 février 2012, à 17:23 +0100, Giovanni Campagna a écrit : 2012/1/24 Vincent Untz vu...@gnome.org: Le jeudi 12 janvier 2012, à 12:02 +0100, Vincent Untz a écrit : Le lundi 19 décembre 2011, à 21:53 +0100, Giovanni Campagna a écrit : Updated patch. More comments inline... Any objection on this? So far, David said he's okay with the changes, and I'm happy with them too. No objection = pushed. I reorganized the text a bit in a second commit. Giovanni, you might want to double-check things. It's totally cool for me. :) Btw, did you have time to work on a patch for desktop-file-utils? :-) Sorry but I didn't, until today. Here it is. Oops, this has been waiting for way too long. Pushed, thanks! Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: new OnlyShowIn/NotShowIn values: MATE and RAZOR
Le jeudi 12 janvier 2012, à 11:56 +0100, Vincent Untz a écrit : Hi, MATE and Razor-qt people have requested two new registered values for OnlyShowIn/NotShowIn: MATE [1] and RAZOR [2]. I don't see any reason to reject that. Any objection from people on the xdg list? No objection = pushed. Note that I used Razor instead of RAZOR since I see no reason to use uppercase letters there. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: freedesktop.org trash-spec links broken
Le lundi 23 janvier 2012, à 23:32 +0100, David Faure a écrit : On Tuesday 20 December 2011 15:16:38 Rex Dieter wrote: I was going to look up something do with the trash-spec and found http://www.freedesktop.org/wiki/Specifications/trash-spec to contain just broken links. Anyone have any current/working pointers to the trash-spec? The only link to the trash spec that has ever worked to my knowledge, is: http://www.ramendik.ru/docs/trashspec.html In fact that's the link in the above wiki page, so I'm surprised it didn't work for you. This should definitely be imported into the xdg-specs git, but, hmm, I can't do that myself. Do we have the old versions of the spec, so we can import the whole history too? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: xdgmime
Le lundi 23 janvier 2012, à 23:20 +0100, David Faure a écrit : So for application .desktop files, we could have another helper binary, say update-app-database (part of shared-mime-info maybe, so that we don't need to depend on xdgmime, which we don't use in KDE and I think gnome might not either, or in a new module), which updates a new cache, say application.cache in a given directory. RPMs and other packages would run that script when installing .desktop files, and then xdgmime could just mmap that and look things up directly, without the need to parse any .desktop files during the application runtime. Now if you implemented that, it would definitely be the best Christmas ever, in my eyes :-) For reference, there's a update-desktop-database tool. It doesn't do what you're describing here, but it creates a mimeinfo.cache file (not mmap'able, though). Still, it's useful for mime implementations, so they don't have to parse all .desktop files to find a mime handler. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending the Desktop Entry spec for static app actions
Le jeudi 12 janvier 2012, à 12:02 +0100, Vincent Untz a écrit : Le lundi 19 décembre 2011, à 21:53 +0100, Giovanni Campagna a écrit : Updated patch. More comments inline... Any objection on this? So far, David said he's okay with the changes, and I'm happy with them too. No objection = pushed. I reorganized the text a bit in a second commit. Giovanni, you might want to double-check things. Btw, did you have time to work on a patch for desktop-file-utils? :-) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
RFC: new OnlyShowIn/NotShowIn values: MATE and RAZOR
Hi, MATE and Razor-qt people have requested two new registered values for OnlyShowIn/NotShowIn: MATE [1] and RAZOR [2]. I don't see any reason to reject that. Any objection from people on the xdg list? Cheers, Vincent [1] https://bugs.freedesktop.org/show_bug.cgi?id=44353 [2] https://bugs.freedesktop.org/show_bug.cgi?id=41112 -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending the Desktop Entry spec for static app actions
Le lundi 19 décembre 2011, à 21:53 +0100, Giovanni Campagna a écrit : Updated patch. More comments inline... Any objection on this? So far, David said he's okay with the changes, and I'm happy with them too. Re Peter's point about dynamic actions: I don't think we should block on this; if a good solution comes, we can adopt it. This will get in in one week if there's no further objection. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: desktop-entry-spec: Add an optional Keywords key
Le vendredi 16 décembre 2011, à 18:51 +0100, Florian Müllner a écrit : On vie, 2011-12-16 at 10:12 +, Peter TB Brett wrote: Your update patch[1] looks good to me. You should probably write a patch for the reserved keywords section too, though, Oh, right - does the attached proposal sound about right? Thanks, I've committed the first patch and this one. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending the Desktop Entry spec for static app actions
Hi, Le dimanche 18 décembre 2011, à 22:57 +0100, Giovanni Campagna a écrit : It seems that we reached a consensus on this feature, and comments have cooled down, so here's the actual patch against current git of xdg-specs. That's a good start. I have some comments below, mostly about wording. If this is approved, I'll prepare a patch for desktop-file-utils. That'd be most welcome! [...] From 30a7f830e67acde3114e4450d15cc642c35cd782 Mon Sep 17 00:00:00 2001 From: Giovanni Campagna gcampa...@src.gnome.org Date: Sun, 18 Dec 2011 22:08:28 +0100 Subject: [PATCH] desktop-entry-spec: restore support for Desktop Actions Reintroduce the Actions key, which was removed around version 1.1, and give it a formal specification, detailing what actions applications are expected to provide and who should make use of this information. Names were taken from the original specification, since apparently they have been in use during all this time. --- desktop-entry/desktop-entry-spec.xml | 130 +- 1 files changed, 129 insertions(+), 1 deletions(-) diff --git a/desktop-entry/desktop-entry-spec.xml b/desktop-entry/desktop-entry-spec.xml index 34bc154..34e96c2 100644 --- a/desktop-entry/desktop-entry-spec.xml +++ b/desktop-entry/desktop-entry-spec.xml @@ -508,6 +508,15 @@ entry1/entry /row row + entry id=key-actionsvarnameActions/varname/entry + entry + Additional actions possible, see the discussion in xref linkend=extra-actions/. I suggest this: Identifiers for application actions. This can be used to tell the application to make a specific action, different from the default behavior. The xref linkend=extra-actionsApplication actions/ section describes how actions work. [...] /sect1 + sect1 id=extra-actions +titleAdditional applications actions/title +para + Desktop entries of type Application can optionally include one or more + actions. This represent additional ways to invoke the particular + application; it is expected that application launchers will expose them + in some way (for example, as a submenu) within the context of the application, + to build so called Quicklists or Jumplists. I suggest this: Desktop entries of type Application can include one or more actions. An action represents an additional way to invoke the application. Application launchers should expose them to the user (for example, as a submenu) within the context of the application. This is used to build so called Quicklists or Jumplists. +/para +para + Each action must be accompained with an action group, that is a group + called varname[Desktop Action %s]/varname, where %s is replaced by an + action ID (as specified by the Actions key). Action groups not included in + the Actions key must be ignored by the implementation. I suggest this: Each action identifier is associated with an action group that must be present in the filename.desktop/filename file. The action group is a group named varnameDesktop Action %s/varname, where varname%s/varname is the action identifier. It is not valid to have an action group for an action identifier not mentioned in the varnameActions/varname key. Such an action group must be ignored by implementors. +/para +para + Identifiers must be composed only of lowercase alphabetic characters + from the ASCII set, plus underscore and minus. Some implementations may Hrm, why not use A-Za-z0-9- like for key names? Also the example (fooview) use some uppercase characters. Also, this paragraph should come before the one about action groups. + give special meanings to some identifiers (for example, replacing a + default new window action with a shortcut idenfied by new-window), + though this is not required. Hrm, we should either not mention this at all or reserve some action identifier (like new-window). Else, this is a bit confusing. +/para +para + The following keys are supported within each action group. The absence of + a REQUIRED key within a group makes the group invalid but does not affect + the validity of the overall desktop entry. Other than that, the usual + rules on extensibility apply. I suggest this: The following keys are supported within each action group. If a REQUIRED key is not present in an action group, then the implementor should ignore this action. There's no need to talk about extensibility here, there's a whole paragraph later. +/para +table + titleAction group keys/title + tgroup cols=5 + thead + row + entryKey/entry + entryDescription/entry + entryValue Type/entry + entryREQ?/entry + /row + /thead + tbody + row + entry id=key-action-group-namevarnameName/varname/entry +
Re: desktop-entry-spec: Add an optional Keywords key
Le vendredi 02 décembre 2011, à 13:53 +0100, Florian Müllner a écrit : On vie, 2011-12-02 at 12:43 +, Simon McVittie wrote: On Fri, 02 Dec 2011 at 12:35:09 +, Peter Brett wrote: I just checked -- the Trinity DE (forked from KDE3) is still using the Keywords key (and not X-KDE-Keywords). For example: http://git.trinitydesktop.org/cgit/tdebase/tree/kcontrol/input/mouse.desktop So yes, this might be a showstopper... ... although mouse.desktop does seem to have keywords broadly compatible with the GNOME proposal (except that they're comma-separated). Yes, that was my impression from looking at other examples as well. I very much favor semi-colons as separator (as that's what we use in Categories and MimeTypes), but I'd be fine with allowing both options. Yeah, we really want semi-colons as it's a list. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [PATCH] Revert menu: add Adult category to registry
Hi, Le mercredi 23 novembre 2011, à 13:38 +, Peter TB Brett a écrit : This reverts commit c51aa112f53adc87250177002aa3e008305e0777. There are several serious issues with the stated rationale for and intended use of the Adult Additional Category that have yet to be resolved. FWIW, I don't care much about that category. But: - The menu specification is designed for worldwide application, and thus must be culturally impartial. Different cultures have different criteria for something that is adult-only. Ambiguous examples provided on the XDG list include Bible and Art Gallery applications. True. But on the other hand, past examples have shown that we can be blocked forever (for instance: the discussion on something like a Religion category). And moving forward with something that is not perfect is better than staying blocked. - Given a set of criteria for what constitutes Adult content, the categorisation is binary, but whether an application is Adult is not. Ambiguous examples provided on the XDG list include a Breastfeeding Tutorial application; the PornView application, which does not in fact include or provide access to any pornography; web browsers, which provide access to a wealth of pornography on the Internet; and text adventure games that include the possibility of violent death. Hrm, this is probably an argument that is valid for all categories :-) It's really up to app developers to use the relevant categories, and then to distributors to decide if those should be overridden or not. - The purpose of the Category field in .desktop files is to aid in organisation of applications into a navigable hierarchy. By contrast, the proponents of the Adult Additional Category view the Adult additional category is as a tool for censorship. Hrm, I don't think it's censorship: the apps are still there, after all. It's filtering, and filtering is actually what the menu spec is about. Sure, in this case, it's filtering to hide stuff. Until these issues are addressed and consensus is achieved, this category should be removed. In the interim period, there is no obstacle to Menu Specification implementors using Additional Categories not listed in the Specification, should they wish to do so. Do you see any way those issues can be addressed? The way I see it, it's just additional metadata that is not used by default and that people can use if they want. So I'm not that much worried about it. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Extending the Desktop Entry spec for static app actions
Le mercredi 30 novembre 2011, à 17:36 +0100, David Faure a écrit : On Thursday 24 November 2011 22:27:23 Jannis Pohlmann wrote: On Thu, 24 Nov 2011 23:03:08 +0100 Giovanni Campagna scampa.giova...@gmail.com wrote: Il giorno gio, 24/11/2011 alle 17.56 +, Jannis Pohlmann ha scritto: On Thu, 24 Nov 2011 17:43:17 + Peter Brett pe...@peter-b.co.uk wrote: [...] It would be nice to avoid a repeat of the controversy that happened earlier this year w.r.t. libappindicator/StatusNotifier and GNOME, and I think the best way to avoid that would be for the GNOME and KDE and Unity (and XFCE etc.) folks to collaborate and present a proposal *together*. I haven't managed to read the previous mails properly yet but let me throw in here that Xfce has repeatedly complained about Desktop Actions being deprecated (for no particularly convincing reasons AFAIR) because we found them to be very useful. What specification are you referring to? http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.5 .html#mime-types This section is no longer present in recent versions of the desktop entry spec. Yep, and I agree with you, it makes no sense. Both KDE and XFCE use it, at least. My (controversial) explanation is that gnome doesn't use that, or stopped using that, so they removed it from the spec. Heh, that's not what happened: when Waldo pushed for the 1.0 version of the spec, it was decided to drop this part of the spec because it was under-specified. I'm all for adding it back if there's a need, and if it's well specified. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] Fixing the Desktop Menu Specification.
Le mercredi 23 novembre 2011, à 13:36 +, Peter Brett a écrit : Vincent Untz vu...@gnome.org writes: I'd really like other people to voice their +1 and/or -1... If nobody else replies to this thread within the next week, I'll just consider we can go crazy and do what we want with the spec. Since it's been a week and no-one's made any additional comments or raised any objections, could you please go ahead and push my patches? Pushed. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] Fixing the Desktop Menu Specification.
(hrm, I had written a reply to this mail, but I apparently didn't send it?!) Le lundi 14 novembre 2011, à 14:03 +, Peter Brett a écrit : Vincent Untz vu...@gnome.org writes: [snip] Le jeudi 10 novembre 2011, à 16:58 +, Peter Brett a écrit : This means adding icons, translations, etc. for all categories, but also having inconsistent menus between computers, and worse, having apps that move to a different menu when you install another app. I don't think we want that. Actually, we already have that, don't we? If you install the Fedora 'geda-gaf' package, the apps appear in different places depending on whether you install the 'electronics-menu' package or not. Same goes for Debian and the 'extra-xdg-menus' package. I don't find this argument persuasive, sorry. :-) I didn't know about electronics-menu, but this is a package that explicitly modify the menu structure (same for extra-xdg-menus, I guess). So if someone installs it, then he knows that he's going to change the menu structure. That's different from, say, installing Chromium and then suddenly getting a Web Browser submenu (just an example of how this could degenerate). Surely you're assuming that the user is also the person installing packages? I think that's an invalid assumption. My point is that a package that automatically installs something changing the menu structure that affects other applications is, imho, broken. But let's not fight over this :-) [...] Why not change the spec so that the sets are unified into a list of Recommended Categories. State that .desktop files SHOULD specify all relevant Recommended Categories, and that distributions/packagers MAY use additional or alternative categories. * Existing .desktop files would not need to be modified (except to remove inappropriate Main Categories that were shoehorned in due to the current spec). * Existing distributions and desktop environment implementations would still be conforming. * The list of Recommended Categories could be maintained IANA-style, with new categories being added if a need is shown for them. (we want this point for sure) * If an implementor only wants to use a subset of the Recommended Categories, they are still free to do so. * Distributions and packagers would have greatly improved flexibility for organising menus. This point is actually my main issue with your suggestion to relax things more: improved flexibility will result in menus that are not consistent from one system to another (which is already the case to some extent today). For sure, app developers want their app to be displayed in the menu, but in general they also want to avoid appearing in the catch-all submenu when it exists. And this improved flexibility will make things harder as .desktop files will not be handled the same way by all distributors. I like the idea that specialist distributions can have specialist menus and still be conforming. Saves arguments. ;-) Nod. I'm sure I had something to reply to this, but since I forgot, I guess it didn't matter ;-) That's why I prefer having a recommended applications.menu in the spec. How about both: remove the distinction between category classes, *and* include a recommended applications.menu? That could work, yes. I'd really like other people to voice their +1 and/or -1... If nobody else replies to this thread within the next week, I'll just consider we can go crazy and do what we want with the spec. Thanks for pushing this, btw! Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] Fixing the Desktop Menu Specification.
Le jeudi 10 novembre 2011, à 16:58 +, Peter Brett a écrit : Vincent Untz vu...@gnome.org writes: Le mercredi 09 novembre 2011, à 16:54 +, Peter Brett a écrit : * Add some language that requires desktop environments to display .desktop files that don't include a Main Category but that would otherwise be displayed. (Does that make sense?) One issue here is that you're assuming a .menu file will always display main categories at the toplevel. Which is not necessarily true. Isn't it? The spec currently states: The list of Main Categories consist of those categories that every conforming desktop environment MUST support. By including one of these categories in an application's desktop entry file the application will be ensured that it will show up in a section of the application menu dedicated to this category. That seems to contradict you... It will appear somewhere, not necessarily at the toplevel. What we can easily do, though, is have some text requesting implementors of .menu files to have a catch-all submenu (Other in GNOME) where apps that don't fit anywhere else would go. Yes, that would be a good idea. Cool, let's do that. I think the problem is that, at the moment, the Main Categories are assumed by the specification to form a complete ontology, but they don't. Here's an idea: instead of having separate Main Categories and Additional Categories, why not simply have a list of Suggested Categories and a recommended algorithm for determining which ones to display, based on frequency of occurrence? Is that plausible? This means adding icons, translations, etc. for all categories, but also having inconsistent menus between computers, and worse, having apps that move to a different menu when you install another app. I don't think we want that. Actually, we already have that, don't we? If you install the Fedora 'geda-gaf' package, the apps appear in different places depending on whether you install the 'electronics-menu' package or not. Same goes for Debian and the 'extra-xdg-menus' package. I don't find this argument persuasive, sorry. :-) I didn't know about electronics-menu, but this is a package that explicitly modify the menu structure (same for extra-xdg-menus, I guess). So if someone installs it, then he knows that he's going to change the menu structure. That's different from, say, installing Chromium and then suddenly getting a Web Browser submenu (just an example of how this could degenerate). [...] Why is the division into Main Categories and Additional Categories needed? I didn't write the spec, so I can't know for sure. I can only guess that the intended goal was to encourage a toplevel structure that would be shared by most implementors, without enforcing this. Why not change the spec so that the sets are unified into a list of Recommended Categories. State that .desktop files SHOULD specify all relevant Recommended Categories, and that distributions/packagers MAY use additional or alternative categories. * Existing .desktop files would not need to be modified (except to remove inappropriate Main Categories that were shoehorned in due to the current spec). * Existing distributions and desktop environment implementations would still be conforming. * The list of Recommended Categories could be maintained IANA-style, with new categories being added if a need is shown for them. (we want this point for sure) * If an implementor only wants to use a subset of the Recommended Categories, they are still free to do so. * Distributions and packagers would have greatly improved flexibility for organising menus. This point is actually my main issue with your suggestion to relax things more: improved flexibility will result in menus that are not consistent from one system to another (which is already the case to some extent today). For sure, app developers want their app to be displayed in the menu, but in general they also want to avoid appearing in the catch-all submenu when it exists. And this improved flexibility will make things harder as .desktop files will not be handled the same way by all distributors. That's why I prefer having a recommended applications.menu in the spec. I would be interested in hearing your thoughts on this suggestion. :-) Would you agree that, in the short term, the following three changes are reasonable, though? 1. Delete this sentence: Additional Categories should always be used in combination with one of the Main Categories. I'm fine with this. 2. Delete this sentence: Note that at least one Main Category must be included in the desktop entry's list of categories. I guess I could live with that. 3. Add some language requesting implementors to provide a catch-all submenu. +1 Before we do the changes (I just saw you sent patches, thanks!), I'd really like others to step up and give
Re: [RFC] Fixing the Desktop Menu Specification.
Le mercredi 09 novembre 2011, à 16:54 +, Peter Brett a écrit : Vincent Untz vu...@gnome.org writes: Le mercredi 09 novembre 2011, à 15:57 +, Peter TB Brett a écrit : All conforming implementations of the desktop specification (that I am aware of) display *only* the Main Categories unless explicitly configured otherwise. Any application that fails to include one of the Main Categories in its .desktop file is (at best) shown in a Lost and Found virtual category, or not displayed at all. This could be fixed by changing the applications.menu shipped by the various people; I'm not entirely sure adding a new main category will help since it won't automatically lead to it being used in applications.menu, but we could try. Alternatively, or in addition to that, we could suggest a default applications.menu in the spec. I think the very minimum changes that the specification needs are: * Stop requiring every .desktop file to include a Main Category. * Add some language that requires desktop environments to display .desktop files that don't include a Main Category but that would otherwise be displayed. (Does that make sense?) One issue here is that you're assuming a .menu file will always display main categories at the toplevel. Which is not necessarily true. What we can easily do, though, is have some text requesting implementors of .menu files to have a catch-all submenu (Other in GNOME) where apps that don't fit anywhere else would go. Or will someone finally propose a way out of this situation? Maybe we can start with a proposal and discuss it? Even if it was discussed in the past, time has passed and people might have a different opinion now. I think the problem is that, at the moment, the Main Categories are assumed by the specification to form a complete ontology, but they don't. Here's an idea: instead of having separate Main Categories and Additional Categories, why not simply have a list of Suggested Categories and a recommended algorithm for determining which ones to display, based on frequency of occurrence? Is that plausible? This means adding icons, translations, etc. for all categories, but also having inconsistent menus between computers, and worse, having apps that move to a different menu when you install another app. I don't think we want that. Thinking more about that, I'm not convinced the issue is about categories themselves [1]. I believe the main issue is that desktops and distributors are shipping different applications.menu, which makes it really hard for app developers to do a right choice for the categories. Fixing this would, hopefully, also help fix your issue. Vincent [1] of course, we do have issues with the categories, and we should still fix them: some are missing, some are useless now, their descriptions are broken, it's often unclear which one to choose for an app developer, etc. -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] Fixing the Desktop Menu Specification.
Hi, Le mercredi 09 novembre 2011, à 15:57 +, Peter TB Brett a écrit : All conforming implementations of the desktop specification (that I am aware of) display *only* the Main Categories unless explicitly configured otherwise. Any application that fails to include one of the Main Categories in its .desktop file is (at best) shown in a Lost and Found virtual category, or not displayed at all. This could be fixed by changing the applications.menu shipped by the various people; I'm not entirely sure adding a new main category will help since it won't automatically lead to it being used in applications.menu, but we could try. Alternatively, or in addition to that, we could suggest a default applications.menu in the spec. [...] Or will someone finally propose a way out of this situation? Maybe we can start with a proposal and discuss it? Even if it was discussed in the past, time has passed and people might have a different opinion now. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: An app category for adult material?
Le jeudi 03 novembre 2011, à 09:15 +0100, Mikkel Kamstrup Erlandsen a écrit : On 2 November 2011 13:19, Kevin Krammer kevin.kram...@gmx.at wrote: Hi, On Tuesday, 2011-11-01, Mikkel Kamstrup Erlandsen wrote: Hi, The latest tickets in what's been a recurring item for our application search in Ubuntu is https://bugs.launchpad.net/ubuntu/+source/unity/+bug/883800. It basically boils down to the fact that you may not want PornView (or other adult apps) popping up as you type a search during a presentation (or have your kids look at it for that matter). I think that no one wants to get into censorship - and there are many ramifications of this problem. For example, it might not be appropriate if bible-related apps show up while a rabbi is giving a talk. Make up your own examples ad lib. This all get's really complex really fast. So keeping it to a problem that we can easily solve a user proposed something that I also think the upstream app authors wouldn't mind: Introducing a new XDG category Adult. That way it is a sensible upstream opt-in, and distros and app stores can handle it like they see fit. I find this a rather problematic approach. First, as Joseph has already stated, adult is a rather vague concept, extremely based on cultural factors. That is on purpose - exactly because I didn't want to get this too much into theoretical discussions. The issue that has been raised in bugs (and other forums) will be fixed by my proposal. I can certainly imagine many other potential scenarios not covered by the proposal, but since no one has raised them so far it amounts to solving something that is a non-issue at this point. FWIW, in the worst case, you can simply ignore the Adult category and you'll get the same results as today: it's just some additional metadata. So patch committed. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: RFC: An app category for adult material?
Le mercredi 02 novembre 2011, à 09:26 +0100, Mikkel Kamstrup Erlandsen a écrit : On 1 November 2011 19:31, Ted Gould t...@gould.cx wrote: On Tue, 2011-11-01 at 14:15 +0100, Mikkel Kamstrup Erlandsen wrote: So keeping it to a problem that we can easily solve a user proposed something that I also think the upstream app authors wouldn't mind: Introducing a new XDG category Adult. That way it is a sensible upstream opt-in, and distros and app stores can handle it like they see fit. This is what OpenClipart.org has done, and I think it's worked reasonably well. At least people have stopped complaining ;-) I generally sense positive feedback on this, so here's a patch for xdg-specs/menu adding the category as discussed. If someone with commit rights would merge it I would be grateful :-) Let's wait for a few more days for people to comment, as several people were on holiday. If there's no major complain, we'll commit it next week. (Ping me if you don't see it committed ;-)) Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Current source for basedir-spec?
Le mardi 12 avril 2011, à 12:53 +0200, Richard Hartmann a écrit : On Tue, Apr 12, 2011 at 02:56, Marty Jack marty...@comcast.net wrote: http://cgit.freedesktop.org/xdg/xdg-specs/tree/ Thanks. Is it worth patching this or does FDO prefer not to edit existing specs unless there is actual change in the content? Patches are always welcome, even if they are only about improving readability :-) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [RFC] XDG basedir spec should mandate absolute paths
Le jeudi 07 avril 2011, à 03:53 +0200, Lennart Poettering a écrit : Heya, currently the xdg basedir spec doesn't make clear that all env vars need to be set to absolute paths. Anybody opposed if I add a small sentence whith clears that up? +1 Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
Le mercredi 30 mars 2011, à 22:23 -0500, Ted Gould a écrit : On Mon, 2011-03-14 at 19:02 +0100, Vincent Untz wrote: I'd like to hear what you think; if my understanding of how it works is correct, but you still want to register Unity (to show different apps in menus, or to have different autostart files), that's fine and we can add Unity ASAP :-) That all being said, I would. I think that I now have a better example even :-) We made a small configuration utility for our clock which has a desktop file, but doesn't make sense to show in a GNOME Shell or KDE environment. While I don't know that it would hurt anyone, it could make GNOME Shell running on Ubuntu more confusing. Done: http://cgit.freedesktop.org/xdg/xdg-specs/commit/?id=b6381cb31953070ba7b641bb6fbdb16758bd8356 Since the spec is still versioned 1.1-draft, I went ahead and pushed this online: http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#onlyshowin-registry I also add the required support to desktop-file-utils: http://cgit.freedesktop.org/xdg/desktop-file-utils/commit/?id=47322e554cc5388a3e6325f36b7d07a13f124594 Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
Hi Ted, Le samedi 19 février 2011, à 14:18 -0600, Ted Gould a écrit : On Sat, 2011-02-19 at 10:26 +0100, Vincent Untz wrote: Just curious: do you have examples of what you want to show/hide in Unity compared to GNOME? If it's only for autostarted apps, The use that pushed me to write the patch/email was with the Desktop Actions that we're putting in desktop file for static actions on the Launcher. Unfortunately, it's still an X- thing but I intend to update it to the current version of the Desktop Actions spec soon (because of release timing we needed something too quickly). In the actions that we've added and sent upstream we've been adding an OnlyShowIn=Unity to ensure they won't effect other projects. I have suggested a couple of times that GNOME Shell should use the same actions, but I don't believe they currently are. Something that wasn't clear to me and that I understood after talking to Didier and looking at an example .desktop file for Unity is how you're using this. Which is is the following, as far as I understand: + you have one .desktop file for, say, evolution + in this .desktop file, you define several actions + you want some actions to appear in an indicator, and some others to appear in the dash + you use OnlyShowIn=Unity; for actions that should only appear in the dash, and not the indicator (or the opposite, I forgot already). Is this right? If no, please ignore what's below :-) If yes, then I think that this is abusing the OnlyShowIn property: the property that you use to compare the current session to the list of values in OnlyShowIn is global to the session, and not local to some components in the session. A good question would be: what if another app wants to display the actions in the same session? I agree that the spec isn't saying this so clearly, but I think this is what is meant. Your current usage of this might possibly be okayish, but I'm afraid that it could lead to some weirdness when actions will be used more widely. I'd suggest to instead use something like X-Ubuntu-ShowIn=dash and X-Ubuntu-ShowIn=indicator. What do you think? I'd like to hear what you think; if my understanding of how it works is correct, but you still want to register Unity (to show different apps in menus, or to have different autostart files), that's fine and we can add Unity ASAP :-) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
Hi Ted, Le vendredi 18 février 2011, à 22:26 -0600, Ted Gould a écrit : On Thu, 2011-02-17 at 08:52 -0600, Ted Gould wrote: We would like to add Unity to the list of values allowed for OnlyShowIn in the menu spec. While Unity is mostly GNOME based there are cases where we'd like some desktop files and menus that GNOME does not so the distinction is relevant. Patch attached (it's huge!) Haven't seen any objection on this, I'm guessing it's not because people are scared of my good looks. Sound good to everyone? We usually wait a week or so to make sure everyone has time to object :-) Just curious: do you have examples of what you want to show/hide in Unity compared to GNOME? If it's only for autostarted apps, then you could use a mechanism like the one we're using for GNOME 3 vs fallback GNOME: http://git.gnome.org/browse/gnome-session/commit/?id=58ebdfac223e6246323a6fcc452221a7581ed868 Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG specs migrated to git
(quickly replying to this mail before I go out, will read the rest of the thread tomorrow) Le mardi 11 janvier 2011, à 11:57 -0500, Jeff Mitchell a écrit : On 1/10/2011 6:30 PM, Aaron J. Seigo wrote: hi... super-massively-belated-response(tm) ... On Thursday, October 14, 2010, Vincent Untz wrote: It's all at http://cgit.freedesktop.org/xdg/xdg-specs/ + free media player: currently in gitorious. Want me to import it? yes, i think that would be good. should be passed by whomever is currently maintaining it, of course. That'd be me, who kicked Vincent repeatedly over the last six months to try to get this going...but somehow I seem to have missed the first email in this thread (and it's not in my list archives). Odd. But, yes please. Want me to import it now, or do you want to get an account first so you can update the spec later on? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG badges
Hi, Le mercredi 15 décembre 2010, à 16:57 +1100, Helen a écrit : It would seem reasonable to use the Free Desktop symbol since XDG is integral to the project. I had a bit of a hunt around but can't see any other artwork. However, I haven't had any real involvement with the project as yet so there could be some creative stuff going on somewhere. At any rate, it seems a good idea to make a range of logo graphics available in various resolutions and formats, and to consider the possibility of alternative logos (perhpas varying colors; a glossy 3-D look one maybe). It might be worth discussing with development/management teams to see what the consensus is regarding development of branding and graphics resources. I think the consensus would just be to use the freedesktop logo :-) So if someone wants to create badges, please feel free to do so, and put them somewhere on the wiki. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [PATCH] menu-spec: Clarifying definitions of Graphics categories
Le mercredi 30 juin 2010, à 15:24 +0200, Vincent Untz a écrit : Le mercredi 30 juin 2010, à 11:46 +0100, Matthew Paul Thomas a écrit : Matthew Paul Thomas wrote on 23/06/10 17:25: ... This diff adjusts the definitions of the Graphics, VectorGraphics, RasterGraphics, and 3DGraphics categories in the Desktop Menu Specification. ... If I need to do anything special to get this patch applied, please let me know what it is. ... So ... what do I need to do? Sorry. The change looks good to me. Any objection against it? If no, I'll commit this next week. Next week. Heh. It's now committed: http://cgit.freedesktop.org/xdg/xdg-specs/commit/?id=9783c9d3a393480dc0856507aa0e643cdb1bb7d8 Thanks! Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
XDG specs migrated to git
Hi, I just pushed to git a migration of various specs I did a while ago. I apologized it took so long, but I wanted to double-check things and then other stuff got higher priority... It's all at http://cgit.freedesktop.org/xdg/xdg-specs/ Current specs in there: + autostart + basedir + desktop-entry + menu + systemtray It's just a dumb import at the moment. I'll work on improving things later on. If people want to push other specs there, they're welcome. There's no strict policy right now (except don't break specs ;-)) -- you might need to ask for write access, though, I'm not sure. Ah, maybe we want to have one unique source format for specs? That'd be docbook. I think it'd make to also get the trash and thumbnails specs there if possible. I'll try to find the docbook sources for that, and push them there if people agree -- if someone has a vcs with the full history, please send me a link :-) As for other specs: + icon-theme icon-naming: already in another git repo (xdg/default-icon-theme). I think people wanted to keep them there. + shared-mime-info: already in another git repo (xdg/shared-mime-info) + startup-notification: already in another git repo (startup-notification) + free media player: currently in gitorious. Want me to import it? + ewmh: any opinion? + xembed: any opinion? + xsettings: any opinion? + xds: any opinion? + recent-file: any opinion? + file-uri: any opinion? + sound-theme/sound-naming: any opinion? Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: The latest icon theme spec links to wrong file.
Le mercredi 04 août 2010, à 15:03 +0800, PCMan a écrit : As title, I already reported this in bugzilla. Someone has access to that page please fix it. https://bugs.freedesktop.org/show_bug.cgi?id=29398 I can't log in the server where this is hosted anymore, so that's why the bug is still there. See https://bugs.freedesktop.org/show_bug.cgi?id=28277 Also, bugzilla didn't provide options for most of the specs. Only desktop entry and trash specs are listed. So I put this to desktop entry since there is no component icon theme. That's fine. Can more components be added to that list? Otherwise there is no place to report bugs for other specs. https://bugs.freedesktop.org/show_bug.cgi?id=29399 Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [PATCH] menu-spec: Clarifying definitions of Graphics categories
Le mercredi 30 juin 2010, à 11:46 +0100, Matthew Paul Thomas a écrit : Matthew Paul Thomas wrote on 23/06/10 17:25: ... This diff adjusts the definitions of the Graphics, VectorGraphics, RasterGraphics, and 3DGraphics categories in the Desktop Menu Specification. ... If I need to do anything special to get this patch applied, please let me know what it is. ... So ... what do I need to do? Sorry. The change looks good to me. Any objection against it? If no, I'll commit this next week. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
desktop-file-utils migrated to git / desktop-file-utils 0.16 released
Hi all, desktop-file-utils was finally migrated from cvs to git. The git repo is xdg/desktop-file-utils: http://cgit.freedesktop.org/xdg/desktop-file-utils/ Also, this made it possible to finally do a new desktop-file-utils release. So here we have desktop-file-utils 0.16: http://www.freedesktop.org/software/desktop-file-utils/releases/desktop-file-utils-0.16.tar.bz2 This is the first release in two years (!). Changes in desktop-file-utils 0.16: desktop-file-install - do not unlink the destination file if it's the same as the source file in desktop-file-install desktop-file-validate - check that a main category is included in the Categories - check that categories required by another one are present - do not always show warnings about KDE specific uses - check that the Comment does not look like the Name and the GenericName - display error about multiple keys with the same name earlier - improve MIME type check to make sure that the MIME types are valid - add LXDE in the list of registered OnlyShowIn values - add warning to error strings to make them easily greppable - handle AutostartCondition key, as proposed for the autostart specification and used in GNOME - accept empty Categories key as valid - make new errors non-fatal to give some time to maintainers to fix their .desktop file after a release of desktop-file-utils - plug leak - code cleanups update-desktop-database - improve MIME type check to make sure that the MIME types are valid - improve error messages - fix format string vulnerability warning misc - use AM_SILENT_RULES - improve build system Thanks Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop Entry Specification - ExecuteAs proposition
Le vendredi 05 mars 2010, à 12:26 +0100, Pierre Wieser a écrit : Hi Work currently done on a shared specification about file manager actions extensions (a definitive name is always to be found) has led us to define an 'ExecuteAs' key. I admit I didn't catch up with this thread. What is the rationale explaining the need for this key? Goal of this key is to let the action creator specify with which user/uid the command must be ran. I believe it's been discussed in the past, but I think some people didn't like the idea and would prefer to avoid any kind of su/sudo usage on the desktop. This is where PolicyKit steps in. But David Z. might want to comment there (I think he's on this list). Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: DPMS and automatic sleep inhibit API
cc'ing Richard, to have him comment quickly on this. Vincent Le jeudi 18 février 2010, à 20:55 +0100, Dario Freddi a écrit : On Thursday 18 February 2010 16:40:07 Ali Abdallah wrote: Greetings, So now that org.freedesktop.PowerManagement spec that was written by Richard Hugsie is dropped for whatever reasons, this drops its inhibit interface as well, so applications whishing to prevent automatic sleep cannot anymore do that in a desktop neutral way. As Aaron pointed out already, in KDE the spec is implemented, but a possible work on improving it and resurrecting it eventually (didn't know it was dead, btw.) is more than appreciated, but I would like to have a voice in reviewing it. AFAIK inhibit interface in gnome is moved from gpm to the gnome-session, most gnome applications uses the org.gnome.Session.Inhibit to inhibit automatic sleep, while this will not work if running these apps under other desktop environment (Xfce, KDE, ...). I think KDE also have something similar for their session as well. trivial question raises here, why there is still no standard API for doing this basic task. So why not having a standard API on a name org.freedesktop.SessionManager with two methods InhibitSleep InhibitDPMS for example, this way any session manager can export these methods in parallel with its private name/methods (org.gnome.Session org.KDE.Session). I will be very happy to write such spec and implement it in our Xfce Session manager, this way even closed source media players can use these methods without having to care about the different desktop environments. I hope the idea will be supported as simple as it is, without going to endless discussions. Regards, ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg -- --- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: startup-notification patch for APPLICATION_ID
Le mercredi 03 mars 2010, à 10:22 +0100, Lubos Lunak a écrit : On Friday 26 of February 2010, Colin Walters wrote: Hi Lubos, thanks for the feedback! On Fri, Feb 26, 2010 at 1:42 PM, Lubos Lunak l.lu...@suse.cz wrote: What is actually supposed to be the improvement? I suppose this addition might be useful, but I fail to see how it helps with tracking. There's actually two parts; I wasn't clear on this originally: * Knowing precisely what .desktop file was launched immediately (this is important for our UI) * Later when the application sends a startup completion message we know what X window that came from, and can then make a strong association between .desktop and X window. That says what it does, but still not why. I assume you want this for some kind of a launcher button that will also do other things when the application is running. But in this case that launcher already knows, and why should others need it? Example: + open file manager + double-click on pdf file + (mime system magic = .desktop file for an app handling pdf is found) + okular/evince/whatever gets started You might want to be able to match the window started this way with the .desktop file, but in a tasklist that doesn't live in the file manager. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Migrating the specifications to git (xdg-specs repo)
Hi, I learnt a few days ago that we finally have a xdg-specs git repo. So let's move forward :-) This mail is about deciding which specifications we want to migrate to the xdg-specs git repository. It's not about which layout we'll use after that (Aaron worked on http://gitorious.org/xdg-specs/ which is an example of what we can do); this will be a second step in the discussion. Right now, I just want to import all specs, each one with its cvs history and in its subfolder. And then we'll be able to move files around the way we want. Let me stress that we can always add other specs later -- this first step is mostly important for the specs for which we want to keep the vcs history. So here's a list of specifications grouped by fate: Will be moved to xdg-specs: autostart-spec basedir-spec desktop-entry-spec menu-spec systemtray-spec Will be moved to xdg-specs unless someone shouts: clipboard-extensions-spec clipboards-spec recent-file-spec wm-spec xembed-spec xsettings-spec Will stay somewhere else, unless maintainers wants to move it to xdg-specs: icon-naming-spec (xdg/default-icon-theme git repo) icon-theme-spec (xdg/default-icon-theme git repo) shared-mime-info-spec (xdg/shared-mime-info git repo) startup-notification-spec (startup-notification git repo) Will likely stay somewhere else because they're already external: UTF8_STRING (http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/) XBEL (http://pyxml.sourceforge.net/topics/xbel/) XDND (http://www.newplanetsoftware.com/xdnd/) XDS (http://www.freedesktop.org/wiki/Specifications/direct-save) file uri (http://equinox-project.org/spec/file-uri-spec.txt) ghns (http://ghns.freedesktop.org/spec/) Will not be migrated because we have just a wiki page right now: cursor (http://www.freedesktop.org/wiki/Specifications/cursor-spec) clipboard manager (http://www.freedesktop.org/wiki/Specifications/clipboard-manager-spec) icc (http://www.freedesktop.org/wiki/OpenIcc/ICC_Profiles_in_X_Specification_0.3) MPRIS (http://wiki.xmms2.xmms.se/index.php/Media_Player_Interfaces) Note that I'm unsure about the startup-notification-spec. We can possibly move it to xdg-specs too. If there's any other spec that we want to import with some history (thumbnail, secret, visual notifications, trash, sound theme, sound naming), please send me a mail with the information on where to get the source and the history of the spec. I think this covers most of what are currently the fdo specs. We have more stuff on http://www.freedesktop.org/wiki/Specifications but they are either not specs (like X extensions) or proposals that went nowhere, or that were not discussed. Also keep in mind that we can always add more stuff later in the git repo, except that it will probably be without the vcs history. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Migrating the specifications to git (xdg-specs repo)
Le mardi 16 février 2010, à 14:52 +, Simon McVittie a écrit : On Tue, 16 Feb 2010 at 15:33:32 +0100, Vincent Untz wrote: Right now, I just want to import all specs, each one with its cvs history and in its subfolder. OOI, why not one spec per git repository? I honestly don't remember why we decided this, but honestly, I don't see the point of having 10 git repos, each containing one xml file. This seems to be the case for a significant number of the specs you mentioned already, and it's somewhat easier to merge two git repositories into one than to split a git repository (you can merge branches that have no history in common). (You can split a directory in a new git repo with filter-branch) If you wanted to do one later, a multi-repository merge would look something like this: * have spec1.git, spec2.git each containing (say) README and specN.xml * in spec1.git:master, move all source into a spec1/ subdirectory * rename spec1.git to merged-specs.git * in spec2.git:master, move all source into a spec2/ subdirectory * fetch spec2.git:master into merged-specs.git as a temporary 'spec2' branch * merge the spec2 branch into master and delete the spec2 branch * repeat for more specifications Doesn't this break the local repos of people who cloned the original repository? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: EWMH
Le lundi 08 février 2010, à 12:05 -0500, MK a écrit : Is anyone involved with the Extented Window Manager Hints specification available on this list? I had thought EWMH was an XDG initiative... There's a mailing list dedicated to the EWMH: http://mail.gnome.org/mailman/listinfo/wm-spec-list Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposing the StatusNotifier specification
Le jeudi 14 janvier 2010, à 13:02 +0100, Marco Martin a écrit : I am wondering if we need some event timestamps for the methods on org.freedesktop.StatusNotifierItem? Window managers that does focus stealing prevention will not allow apps to focus windows at whatever times suits them without a valid event timestamp. This goes for Metacity atleast, perhaps also Mutter... is it someting for the dbus protocol? Shouldn't be something more for the client library, to take care raising the window with the timestamp of when the activate signal arrived? (as opposed to when the signal originated, that would add complexity to the dbus protocol) The timestamp is about the last user-generated event, so when the activate signal arrived is wrong. (no idea if the timestamp is needed -- a closer look to the spec would be needed) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposing the StatusNotifier specification
Hi, Le jeudi 17 décembre 2009, à 18:07 +0100, Aurélien Gâteau a écrit : This specification is already implemented by KDE in kdelibs [2] and Canonical is working on an implementation for GNOME, libappindicator [3]. Reading [4], I had the feeling that this would now be implemented directly in GTK+ (but for the release after 2.20). Did I get this wrong? I would think it'd be better to have this implementation done before accepting the specification. However, I guess it might be okay to start using the org.freedesktop namespace for the dbus API. I find org.freedesktop.StatusNotifierItem a bit, hrm, weird, though. Why not org.freedesktop.StatusItem or org.freedesktop.NotificationItem. (same for StatusNotifierWatcher, btw) Vincent [4] http://mail.gnome.org/archives/gtk-devel-list/2009-November/msg00203.html -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposing the StatusNotifier specification
Le mercredi 06 janvier 2010, à 16:03 +0100, Marco Martin a écrit : On Wednesday 06 January 2010, Vincent Untz wrote: I find org.freedesktop.StatusNotifierItem a bit, hrm, weird, though. Why not org.freedesktop.StatusItem or org.freedesktop.NotificationItem. well, it acttally changed name at least 4-5 times and have been issues for each of those names. NotificationItem was indeed the last one, but the problem was the potential confusion with the notification system, Hrm, okay (I'm assuming we're talking about a status system, in opposition of a notification system). StatusItem would be probably ok-ish too, but not significantly better than StatusNotifierItem a Status notifier item is a thing that notifies about the status of an application, so even if not totally pretty is a name that seems to make perfect sense. Well, a status item is a thing that displays the status of an application. I didn't read the spec carefully, but the intro states: This specification defines the management of visual items, usually icons used for reporting the status of an application to the user or provide a quick access to common actions performed by that application. It's certainly not just about an item that notifies. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Fwd: Actions extensions in File Manager
Le vendredi 27 novembre 2009, à 12:59 +0100, Kevin Krammer a écrit : On Friday, 2009-11-27, Ted Gould wrote: On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote: However, these two threads refer to a 'Desktop Action' which was present in current 0.9.4 spec, but has disappeared from latest 1.1. Does this mean the 'Desktop Action' entry has been obsoleted ? More specifically, it was deleted in the 0.9.6 version as it was in 0.9.5. I am too curious about these, as I was looking at trying something similar for a couple messaging menu features. I'd much prefer to use something standard. Good question, since it seems it had already been implemented by at least two file managers. Maybe there is a commit log detailing the removal reasoning? As far as I remember, it was removed by Waldo when there was a push to release a 1.0 version of the spec. The major issue that the Desktop Action stuff had is that the spec didn't really explain how it was working and how it was intended to be used... (I think the plan was to put it back once it'd be well defined) Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Need for new multimedia categories
Le jeudi 27 août 2009, à 15:15 +0200, Stanislav Brabec a écrit : Orcan Ogetbil wrote: After careful consideration we decided to use special X-... categories to classify the multimedia applications according to the demand. This suggests using these additional categories: Please add them to: https://bugs.freedesktop.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=product=Specificationscomponent=desktop-entrylong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailqa_contact2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= It would be nice to update desktop spec, as there is may useful categories missing. Feel free to comment other proposals there (I collected them from the list several months ago). Vincent, is it possible to help you somehow with the new version of the specification? Sure, having people comment on how useful the proposed categories are would help :-) Here are the relevant bugs: https://bugs.freedesktop.org/show_bug.cgi?id=20186 clash of Science and Education = new main Category Moving Science as a toplevel category is fine with me; no need for an additional category, though (economy or geography are sciences) https://bugs.freedesktop.org/show_bug.cgi?id=20187 mapping, navigation, GPS... Adding something like Maps (not fan of the name, though) makes sense. Not quite sure we need GIS. https://bugs.freedesktop.org/show_bug.cgi?id=20189 each Additional Category need Main Category Sounds like something we can just fix. https://bugs.freedesktop.org/show_bug.cgi?id=20191 request for GPE and XFCE No strong opinion there; as long as the projects (GPE, XFCE, ROX, etc.) still want something, let's add it. https://bugs.freedesktop.org/show_bug.cgi?id=20192 request for Spirituality and Philosophy Ah, this one is famous. At the moment, I would just go with Spirituality, and add Philosophy later on if it's really needed. https://bugs.freedesktop.org/show_bug.cgi?id=20197 add PIM support and RSS support Fine with me. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Need for new multimedia categories
Hi, Le mardi 04 août 2009, à 04:00 -0400, Orcan Ogetbil a écrit : After careful consideration we decided to use special X-... categories to classify the multimedia applications according to the demand. This suggests using these additional categories: FWIW, it'd help to have a short description for each of the proposed category :-) X-AudioVideo-Import X-AudioVideo-Capture Do we really need to differentiate those two? X-Digital_Processing X-Synthesis Same question, I guess. X-Jack Is it really needed? Sounds a bit weird to add this to me. X-Multitrack X-Trackers Need to differentiate? X-Notation Notation is probably too generic, but makes sense. Is it only for music stuff? If yes, we could use MusicNotation. X-Output-Generation X-Streamer Hrm. Not clear what app you would put there. So maybe those need better names ;-) Or at least the description. X-Subtitle-Editor Are there enough apps for this category to be worth existing? X-Audio_Tools This one sounds like something you could achieve with Utility;Audio; ? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: [desktop entry spec] new FullName key
Le lundi 03 août 2009, à 16:53 +0200, Christian Rose a écrit : So, as always with localization, you just can't concatenate sentences or pieces of sentences and get a result. It has to be translated as a whole. So it seems we have a good argument that %1$s - %2$s (with Name GenericName) is wrong. Christian, just out of interest: is it also true for %1$s (%2$s) (I would expect it is). And do you think the burden of adding a new translatable key to all desktop files would be okay for translator teams? Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: What constitutes user configuration files in the XDG basedir spec?
Le mardi 24 février 2009, à 22:01 +0100, Axel Liljencrantz a écrit : 2009/2/9 Dieter Plaetinck die...@plaetinck.be Actually I think your state vs configs splitup is a very similar approach to my suggested settings as configured by user/on behalf of user versus settings on behalf of the application itself splitup at http://lists.freedesktop.org/archives/xdg/2009-January/010157.html In practice, all settings that an app would like to store without explicitly requested by the user can probably all be categorised under state, so our ideas are very similar. Your wording is probably better then mine, so a huge +1 from me for adding a 4th concept 'state' to the current list of cache, configs and data. Am I correct in interpreting the above discussion as in the consensus being that for now, what you refer to as state should be saved in the .config directory, and that a future xdg version may separate it into a third directory, perhaps to be named .state? I actually didn't feel there was consensus on this. My main worry is that I'm not sure it's worth the effort for app developers to do that, so this might not work. And I'm also not convinced that you have a clear line between state and config -- it will be blurry in quite some cases. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
Le mardi 24 février 2009, à 13:49 +0100, Alexander Larsson a écrit : On Tue, 2009-02-24 at 13:27 +0100, Alexander Larsson wrote: 6. Make sure that launchers added to the Desktop and whatnot are marked as executable. This is actually kinda tricky. DnDing a launcher from the start menu or the panel in Gnome is just a regular copy operation of the source desktop file. We don't want the normal copy operation to rewrite and chmod a+x all desktop files in general, since people expect a standard copy of a filesystem tree to not modify any of the files. I guess we can special case the case of a single .desktop file being copied to the desktop. Are there other similar cases that seem likely to happen in practice? gnome-panel has some code to add a desktop file to the desktop from the applications menu (without drag and drop). I guess some other apps might have this too. Setting the +x bit isn't hard, but adding some #! header is, hrm, not fun... Oh well. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
Le dimanche 22 février 2009, à 12:41 +0100, Milan Bouchet-Valat a écrit : To sum up, I can see two ways of solving the issue: 1) Enforce what is already the custom: no big modifications except for a handful of non-standard apps (requires only a new paragraph in the Desktop spec) 2) Add the concept of app identifier in a different way, which implies - a new field in the Desktop spec - possibly a new WM property for all windows Isn't it simpler to add a _NET_WM_DESKTOP_ENTRY_NAME property that should contain the name of the relevant desktop file? Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file security
Le samedi 21 février 2009, à 18:07 -0500, Michael Pyne a écrit : Hi all, I'm just writing to let you know that I'm working on changing the handling of .desktop files for the next major version of KDE. The work itself is being tracked on kde-core-devel but a synopsis of the plan is: Here's the thread about this for GNOME: http://mail.gnome.org/archives/desktop-devel-list/2009-February/msg00132.html We should make sure to handle this the same way, IMHO. Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Identifying applications from windows to .desktop files
Le dimanche 22 février 2009, à 15:20 +0100, Milan Bouchet-Valat a écrit : Le dimanche 22 février 2009 à 15:12 +0100, Vincent Untz a écrit : Le dimanche 22 février 2009, à 12:41 +0100, Milan Bouchet-Valat a écrit : To sum up, I can see two ways of solving the issue: 1) Enforce what is already the custom: no big modifications except for a handful of non-standard apps (requires only a new paragraph in the Desktop spec) 2) Add the concept of app identifier in a different way, which implies - a new field in the Desktop spec - possibly a new WM property for all windows Isn't it simpler to add a _NET_WM_DESKTOP_ENTRY_NAME property that should contain the name of the relevant desktop file? Yes. That would be a variant of 2)b. But it still shares the drawbacks of this solution, namely that we need to update all apps one by one. I don't see this as a huge blocker. We could something like if _NET_WM_DESKTOP_ENTRY_NAME is set, use this, else try to guess the desktop file name like we already do. Another problem is that while this property would have to be set from the source code, .desktop file names are set by distributions. So at the end your proposal would force distributions to use the filename specified by upstream or to patch the source. To avoid the burden of such useless patches, they would adapt their filenames. And we would end with solution 1), with the complexity of a new property to get passed in non-standard apps (think of making this enter OO.o), and without the advantage of a simple standard. Well, I'd argue that distros shouldn't rename desktop files ;-) This will already be an issue in GNOME, since the new gnome-session and eggsmclient use the desktop file name. For example, look for egg_set_desktop_file() in http://svn.gnome.org/viewvc/gnome-terminal/trunk/src/terminal.c?revision=3310view=markup Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: shared-mime-info: image/x-fits - image/fits
Alexey asked to be cc'ed, so doing this ;-) Vincent Le mardi 17 février 2009, à 10:38 +0100, David Faure a écrit : On Thursday 12 February 2009, Alexey Shuvaev wrote: Hello all! The long history short: FITS image mime type is officially registered since 2005. So it is named image/fits and application/fits now. The history of acception: http://www.ucolick.org/~sla/fits/mime/ RFC 4047: http://www.rfc-editor.org/rfc/rfc4047.txt Indeed, http://www.iana.org/assignments/media-types/image/ knows about image/fits. As of image/fits, I think it should be fixed. Done. 2009-02-17 David Faure fa...@kde.org * freedesktop.org.xml.in: Rename image/x-fits to image/fits (IANA-registered name), and add image/x-fits as alias * tests/list: Update testcase accordingly However for you to benefit from this fix, a new shared-mime-info release has to be made, which is not in my hands. -- David Faure, fa...@kde.org, sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg -- Les gens heureux ne sont pas pressés. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
