Re: defaults.list or mimeapps.list?
David Faure wrote: > On Tuesday 21 January 2014 11:01:17 Rex Dieter wrote: >> Jerome Leclanche wrote: >> > I'm finding a lot of conflicting information. Which to use? I'm using >> > mimeapps.list currently, I was certain defaults.list was the >> > deprecated one but I need an official word on this. >> >> See "Default application ordering" on >> http://www.freedesktop.org/wiki/Specifications/mime-actions-spec/ >> >> In effect, its a bit implementation specific... gnome uses defaults.list, >> kde uses a mixture of InitialPreference= key and mimeapps.list > > This is a strange way of presenting it. The same mixture exists > everywhere. > > The environment defaults are environment-specific, using defaults.list in > Gnome and InitialPreference= in KDE. > > On top of that, mimeapps.list is standard, and can be used at the system > level (/usr/share) by ISVs In my experience, stuff set in mimeapps.list in /usr/share isn't used by gnome. Should I go retest that? -- Rex ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: defaults.list or mimeapps.list?
On Tuesday 21 January 2014 11:01:17 Rex Dieter wrote: > Jerome Leclanche wrote: > > I'm finding a lot of conflicting information. Which to use? I'm using > > mimeapps.list currently, I was certain defaults.list was the > > deprecated one but I need an official word on this. > > See "Default application ordering" on > http://www.freedesktop.org/wiki/Specifications/mime-actions-spec/ > > In effect, its a bit implementation specific... gnome uses defaults.list, > kde uses a mixture of InitialPreference= key and mimeapps.list This is a strange way of presenting it. The same mixture exists everywhere. The environment defaults are environment-specific, using defaults.list in Gnome and InitialPreference= in KDE. On top of that, mimeapps.list is standard, and can be used at the system level (/usr/share) by ISVs or at the user-level to store user-specific overrides. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: expanding the inhibit spec
On Thursday 09 January 2014 12:49:19 Ryan Lortie wrote: > That's why I prefer two completely separate mechanisms: block to stop > the process from occurring in the first place, and (if no blocks are > there) a round of signals, after which there is absolutely nothing that > apps can do to prevent the shutdown from proceeding. Note that this is exactly how good old X11 session management works :-) I don't know the low-level XSMP names for these things, but that the Qt level it ends up with "commitDataRequest" (where users can be prompted to save unsaved data) and "saveStateRequest" in the second round, for saving just before exiting. I much rather prefer that over SIGTERM, which is not modular (can't have more than one handler) and awkward to integrate in C++. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Desktop file spec improvements (was: Binary name in the desktop file)
On Tuesday 31 December 2013 16:48:30 Jerome Leclanche wrote: > On Tue, Dec 31, 2013 at 4:20 PM, Jasper St. Pierre > > wrote: > > On Tue, Dec 31, 2013 at 6:12 AM, Jerome Leclanche wrote: > >> So that detail should be in the menu spec, not the desktop file spec. > >> I see no mention of TryExec in > >> http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html > > > > Speaking with my GNOME hat on, GNOME is now ignoring the menu spec > > upstream, in favor of allowing the user to create their own categories > > and folders in the GNOME Shell Overview. > > > > Personally, I do not feel the menu-spec should be extended anymore, or > > considered something we recommend to OEMs. > > > >> In my mind, desktop files are as declarative as possible; and so, the > >> desktop file spec should not dictate implementations as that is > >> completely counter-intuitive. Maybe the TryExec key can be used to > >> hide files in the menu spec, and maybe it can be used for something > >> completely different in another. The former usage is only relevant to > >> the menu spec. > > > > I strongly feel that TryExec should be well-defined and used for hiding > > apps. Otherwise, we don't really have a specification, we just agree that > > TryExec is a key that contains a path, and maybe it will hide apps when it > > doesn't exist, and maybe it will launch green army men to the moon when it > > doesn't exist. > > > > There are plenty of cases where we don't use the menu-spec at all, but > > need > > to launch apps. One simple example is the "Open With..." prompt in > > Nautilus/Files: we show a list of apps to the user, and need to run > > TryExec > > by the standard. menu-spec was not involved here. > > Wouldn't it make more sense to keep the TryExec key, and have an > additional key to define the behaviour if TryExec is missing? > > You could have something like: > > gmail.desktop > TryExec=firefox > MissingExecutable=X > > where X could be ignore (default), hide (current behaviour) or even > something like delete, where the desktop file would be deleted > altogether (if that is possible) if the TryExec is missing. > > Or you could just have a boolean key HideIfMissing=true, defaulting to > either. This looks like a solution in search of a problem. "ignore" the same as not having a TryExec key at all, "hide" is what we have, and "delete", well, I certainly wouldn't want to enable a feature that deletes my carefully crafted .desktop file because of a typo in TryExec. (and system desktop files are typically not deletable, so this is indeed really only about user desktop files) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Trash spec: directory size cache
On Wednesday 24 April 2013 17:33:45 Mikhail Ramendik wrote: > On 24 April 2013 17:26, David Faure wrote: > > Sure, please do. Maybe do that as an additional commit on top of mine, and > > in > > the end one of us pushes both commits together? This way it'll be easier > > to > > review your changes (without diff'ing diffs). > > I'm not sure I know how to commit or have the access, but I suggest we > handle this later. I will try to have my version ready no later than the > weekend and post it at a temporary location. Once everything is approved I > am sure we can sort out the commit part without bothering the entire list > with it. Wrapping this up almost a year later :) Given that everyone was in agreement with this spec change, I have now pushed these two commits, after receiving the style update by Mikhail: commit 41d01202368d5296da77cda72a0f18f3590e9ca9 Author: Mikhail Ramendik Date: Sun Feb 2 10:47:52 2014 +0100 Style review of the language in the trash spec commit 4636efe0c39c332886b8ba704e2345eba1c2a7a3 Author: David Faure Date: Wed Apr 24 18:36:22 2013 +0200 Add "directorysizes" spec, bump version to 1.0 and I updated the information in web-export/specs.idx (how do I trigger an update on the website now?) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
