Re: mime apps specification
On 15.04.2014 23:13, David Faure wrote: When looking for the default app, we'll get app2, from the very first file in the list. When looking for the full list of associated apps: (the step numbers correspond to the items in the algorithm in the spec) (*) step 1: result = (), blacklist = () step 2: opening $XDG_CONFIG_HOME desktop-specific list, no Added or Removed group, skipping. Then opening $XDG_CONFIG_HOME list. step 3: result = (app2) step 4: blacklist = (app4) step 5 and 6: no desktop files here, skipping Then moving up one dir, to $XDG_DATA_HOME applications: step 3,4: no mimeapps.list found, nothing to do step 5: result = (app2, app5) step 6: blacklist = (app4, app5) Then moving up one dir, to $XDG_CONFIG_DIRS list: step 3: none step 4: blacklist = (app4, app5, app2) step 5 and 6: no desktop files here, skipping Then moving up one dir, to $XDG_DATA_HOME applications, nothing to do Then moving up one dir, to $XDG_DATA_DIRS (has both mimeapps.list and apps) step 3: nothing (do not append app4 to result since it's in the blacklist) step 4: none step 5: add app1 and app3 (not app2, it's in the blacklist) => result = (app2, app5, app1, app3) Is the result app2.desktop;app3.desktop;app1.desktop;app5.desktop? No. I think you missed the fact that we go up the dirs in order, and process both (or either, whatever is available) mimeapps.list and .desktop files. So app5 gets added before we go up to more global dirs. While I was writing this message, you've already answered most of the questions in another, so I'm sending the following only as a side notes. I'll put updated thoughts in reply to your message the neighboring branch... -- OK, at least the set is the same, different order... Why app5 got into blacklist in $XDG_DATA_HOME step 6? Thank you, now I have more understanding of the algorithm. But maybe I'm missing some basic thing here which prevents me from understanding the choice of direction. My point of view comes from perceiving the whole override thing as the result of actions consecutively applied to some inital set. In this case, initial set is $XDG_DATA_DIRS .desktop files. And actions - all that goes on the way from that to the user-level. That view just looks natural and simplier to me, but it does not look natural to you. Have you any idea why? Because i'm really curious. Maybe some rule i'm [blindly] ignoring, or you [blindly] following? By the way, the result "app2, app5, app1, app3" can also be achieved by going global>local while making additions to the beginning of the list. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Monday 14 April 2014 11:14:41 Vladimir Kudrya wrote: > On 14.04.2014 01:28, Vladimir Kudrya wrote: > > Maybe example would clarify things? The spec would need an example anyway. > > I will update this question taking into account the new patch and > inability for desktop-specific list to add/remove apps. > > $XDG_CONFIG_HOME desktop-specific list: > [Default Applications] > foo/bar=app2.desktop > > $XDG_CONFIG_HOME list: > [Added Associations] > foo/bar=app2.desktop > [Removed Associations] > foo/bar=app4.desktop > > $XDG_DATA_HOME applications: > app5.desktop > > $XDG_CONFIG_DIRS list: > [Removed Associations] > foo/bar=app2.desktop > > $XDG_DATA_DIRS desktop-specific list: > [Default Applications] > foo/bar=app3.desktop > > $XDG_DATA_DIRS list: > [Default Applications] > foo/bar=app1.desktop > [Added Associations] > foo/bar=app4.desktop > > $XDG_DATA_DIRS applications: > app1.desktop;app2.desktop;app3.desktop > > > Please show how to iterate through the list. When looking for the default app, we'll get app2, from the very first file in the list. When looking for the full list of associated apps: (the step numbers correspond to the items in the algorithm in the spec) (*) step 1: result = (), blacklist = () step 2: opening $XDG_CONFIG_HOME desktop-specific list, no Added or Removed group, skipping. Then opening $XDG_CONFIG_HOME list. step 3: result = (app2) step 4: blacklist = (app4) step 5 and 6: no desktop files here, skipping Then moving up one dir, to $XDG_DATA_HOME applications: step 3,4: no mimeapps.list found, nothing to do step 5: result = (app2, app5) step 6: blacklist = (app4, app5) Then moving up one dir, to $XDG_CONFIG_DIRS list: step 3: none step 4: blacklist = (app4, app5, app2) step 5 and 6: no desktop files here, skipping Then moving up one dir, to $XDG_DATA_HOME applications, nothing to do Then moving up one dir, to $XDG_DATA_DIRS (has both mimeapps.list and apps) step 3: nothing (do not append app4 to result since it's in the blacklist) step 4: none step 5: add app1 and app3 (not app2, it's in the blacklist) => result = (app2, app5, app1, app3) > Is the result app2.desktop;app3.desktop;app1.desktop;app5.desktop? No. I think you missed the fact that we go up the dirs in order, and process both (or either, whatever is available) mimeapps.list and .desktop files. So app5 gets added before we go up to more global dirs. -- 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: mime apps specification
On 14.04.2014 01:28, Vladimir Kudrya wrote: Maybe example would clarify things? The spec would need an example anyway. I will update this question taking into account the new patch and inability for desktop-specific list to add/remove apps. $XDG_CONFIG_HOME desktop-specific list: [Default Applications] foo/bar=app2.desktop $XDG_CONFIG_HOME list: [Added Associations] foo/bar=app2.desktop [Removed Associations] foo/bar=app4.desktop $XDG_DATA_HOME applications: app5.desktop $XDG_CONFIG_DIRS list: [Removed Associations] foo/bar=app2.desktop $XDG_DATA_DIRS desktop-specific list: [Default Applications] foo/bar=app3.desktop $XDG_DATA_DIRS list: [Default Applications] foo/bar=app1.desktop [Added Associations] foo/bar=app4.desktop $XDG_DATA_DIRS applications: app1.desktop;app2.desktop;app3.desktop Please show how to iterate through the list. Is the result app2.desktop;app3.desktop;app1.desktop;app5.desktop? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On 14.04.2014 00:50, Jerome Leclanche wrote: You add it in [Added Applications] (or [Default Applications] if you need it as default), lower downstream. When the spec says "read from most local to most global", it does imply you should pick up the results in the order they were read. You seem very intent on the spec not working the way you want, when it does exactly what you're asking it to. I'm sure it could use wording improvements but downstream (more-local) does override. Maybe example would clarify things? The spec would need an example anyway. Here is the list of items from local to global: local desktop-specific list: [Default Applications] foo/bar=app2.desktop [Added Associations] foo/bar=app3.desktop [Removed Associations] foo/bar=app4.desktop local list: [Removed Associations] foo/bar=app3.desktop local applications: app5.desktop global desktop-specific list: [Default Applications] foo/bar=app3.desktop [Added Associations] foo/bar=app4.desktop global list: [Default Applications] foo/bar=app1.desktop global applications: app1.desktop;app2.desktop;app3.desktop Please describe iterations as they go by the spec. Will the result be app2.desktop;app3.desktop;app1.desktop;app5.desktop with default app2.desktop? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, Apr 13, 2014 at 9:39 PM, Vladimir Kudrya wrote: > On 14.04.2014 00:32, Jerome Leclanche wrote: > > That *is* the rule, downstream always overrides. You calculate the > list on each step while adding items to the blacklist as you find them > *from most local to most global*. > > I'm not really sure how to make it more clear. David made sure the > wording of the algorithm was easy to follow. > > That sounds more like upstream concatenates. > > Example: Upstream (system-level mimeapps.list) has app1.desktop in > [Removed]. How do I override this downstream (user-level mimeapps.list)? You add it in [Added Applications] (or [Default Applications] if you need it as default), lower downstream. When the spec says "read from most local to most global", it does imply you should pick up the results in the order they were read. You seem very intent on the spec not working the way you want, when it does exactly what you're asking it to. I'm sure it could use wording improvements but downstream (more-local) does override. J. Leclanche ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On 14.04.2014 00:32, Jerome Leclanche wrote: That *is* the rule, downstream always overrides. You calculate the list on each step while adding items to the blacklist as you find them *from most local to most global*. I'm not really sure how to make it more clear. David made sure the wording of the algorithm was easy to follow. That sounds more like upstream concatenates. Example: Upstream (system-level mimeapps.list) has app1.desktop in [Removed]. How do I override this downstream (user-level mimeapps.list)? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, Apr 13, 2014 at 9:29 PM, Vladimir Kudrya wrote: > On 14.04.2014 00:20, Jerome Leclanche wrote: >> >> On Sun, Apr 13, 2014 at 9:15 PM, Vladimir Kudrya >> wrote: >>> >>> On 13.04.2014 21:54, Jerome Leclanche wrote: >>> >>> Reading local first, you will find the foo.desktop file *before* you >>> arrive to the item in the global blacklist. >>> >>> That is if you just need to find the default. And IF [Default >>> Application] >>> for the type even exists in the hierarchy. >>> >>> How to get whole list of associations of given mime type then? Spec says >>> to >>> iterate from local to global, concatenate [Added] and [Removed] >>> separately, >>> then use all [Added] minus [Removed] as blacklist. This means that local >>> [Added] does not override global [Removed]. >>> >> You proceed the same way for every kind of item you want, adding items >> to the blacklist ([Removed]) as you go along. You exclude items from >> ever being added to the list if they are blacklisted; this avoids >> dealing with blacklist priorities separately. >> >> >> J. Leclanche > > So if generic mimeapps.list removes an item, and $desktop-mimeapps.list adds > it, it still remains removed, despite $desktop-mimeapps.list has precedence > as more local? Why not just to follow simple rule: downstream overrides? That *is* the rule, downstream always overrides. You calculate the list on each step while adding items to the blacklist as you find them *from most local to most global*. I'm not really sure how to make it more clear. David made sure the wording of the algorithm was easy to follow. J. Leclanche ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On 14.04.2014 00:20, Jerome Leclanche wrote: On Sun, Apr 13, 2014 at 9:15 PM, Vladimir Kudrya wrote: On 13.04.2014 21:54, Jerome Leclanche wrote: Reading local first, you will find the foo.desktop file *before* you arrive to the item in the global blacklist. That is if you just need to find the default. And IF [Default Application] for the type even exists in the hierarchy. How to get whole list of associations of given mime type then? Spec says to iterate from local to global, concatenate [Added] and [Removed] separately, then use all [Added] minus [Removed] as blacklist. This means that local [Added] does not override global [Removed]. You proceed the same way for every kind of item you want, adding items to the blacklist ([Removed]) as you go along. You exclude items from ever being added to the list if they are blacklisted; this avoids dealing with blacklist priorities separately. J. Leclanche So if generic mimeapps.list removes an item, and $desktop-mimeapps.list adds it, it still remains removed, despite $desktop-mimeapps.list has precedence as more local? Why not just to follow simple rule: downstream overrides? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On 13.04.2014 21:54, Jerome Leclanche wrote: Reading local first, you will find the foo.desktop file *before* you arrive to the item in the global blacklist. That is if you just need to find the default. And IF [Default Application] for the type even exists in the hierarchy. How to get whole list of associations of given mime type then? Spec says to iterate from local to global, concatenate [Added] and [Removed] separately, then use all [Added] minus [Removed] as blacklist. This means that local [Added] does not override global [Removed]. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, Apr 13, 2014 at 9:15 PM, Vladimir Kudrya wrote: > On 13.04.2014 21:54, Jerome Leclanche wrote: > > Reading local first, you will find the foo.desktop file *before* you > arrive to the item in the global blacklist. > > That is if you just need to find the default. And IF [Default Application] > for the type even exists in the hierarchy. > > How to get whole list of associations of given mime type then? Spec says to > iterate from local to global, concatenate [Added] and [Removed] separately, > then use all [Added] minus [Removed] as blacklist. This means that local > [Added] does not override global [Removed]. > You proceed the same way for every kind of item you want, adding items to the blacklist ([Removed]) as you go along. You exclude items from ever being added to the list if they are blacklisted; this avoids dealing with blacklist priorities separately. J. Leclanche ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, Apr 13, 2014 at 6:34 PM, Vladimir Kudrya wrote: > Hello everyone! > I am translator and tester of SpaceFM file manager. > There were some heated discussion of the new mime spec > https://github.com/IgnorantGuru/spacefm/issues/450 > > As it is still in flux I'd like to share some thoughts. The ordering and > precedence in the spec is somewhat shady. For example current spec does not > allow removed association to be re-added further downstream. David Faure > replied that clarifications will follow. I think it was clarified in the spec but you are supposed to read the desktop files from most local to most global while maintaining "Removed Associations" as a blacklist. Example, simplifying to only "global" and "local" namespaces: GLOBAL: [Removed Associations] application/example=foo.desktop; LOCAL: [Added Associations] application/example=foo.desktop; Reading local first, you will find the foo.desktop file *before* you arrive to the item in the global blacklist. > > In the meantime, I would like to make some fresh-eyed input. > Do the following statements cover the intended meaning of the algorithm? > Let's say these are both questions and suggestions: > > The ordered list of associations of given mimetype is forming from upstream > to downstream, every downstream part takes precedence and overrides its > upstream part. > Items in [Default Applications] influence ordering only. > Items in [Added Associations] influence presence only (just as content of > .desktop files). > Items in [Removed Associations] are removed from list in current iteration. It's a lot simpler if you just look at it the other way. J. Leclanche > > The order of sources of item is this (from upstream to downstream): > $XDG_DATA_DIRS .desktop files > > $XDG_DATA_DIRS mimeapps.list > > $XDG_DATA_DIRS $desktop-mimeapps.list > > $XDG_CONFIG_DIRS mimeapps.list > > $XDG_CONFIG_DIRS $desktop-mimeapps.list > > $XDG_DATA_HOME .desktop files > > $XDG_DATA_HOME mimeapps.list > > $XDG_DATA_HOME $desktop-mimeapps.list > > $XDG_CONFIG_HOME mimeapps.list > > $XDG_CONFIG_HOME $desktop-mimeapps.list > > > Another opinion is voiced by IgnorantGuru, the developer of SpaceFM. He > points out that separate [Default Applications] is redundant and is a big > step away from KISS principle. List ordering in [Added Associations] should > be enough to change/determine default application. > > Thank you for your time! > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Hello everyone! I am translator and tester of SpaceFM file manager. There were some heated discussion of the new mime spec https://github.com/IgnorantGuru/spacefm/issues/450 As it is still in flux I'd like to share some thoughts. The ordering and precedence in the spec is somewhat shady. For example current spec does not allow removed association to be re-added further downstream. David Faure replied that clarifications will follow. In the meantime, I would like to make some fresh-eyed input. Do the following statements cover the intended meaning of the algorithm? Let's say these are both questions and suggestions: The ordered list of associations of given mimetype is forming from upstream to downstream, every downstream part takes precedence and overrides its upstream part. Items in [Default Applications] influence ordering only. Items in [Added Associations] influence presence only (just as content of .desktop files). Items in [Removed Associations] are removed from list in current iteration. The order of sources of item is this (from upstream to downstream): $XDG_DATA_DIRS .desktop files > $XDG_DATA_DIRS mimeapps.list > $XDG_DATA_DIRS $desktop-mimeapps.list > $XDG_CONFIG_DIRS mimeapps.list > $XDG_CONFIG_DIRS $desktop-mimeapps.list > $XDG_DATA_HOME .desktop files > $XDG_DATA_HOME mimeapps.list > $XDG_DATA_HOME $desktop-mimeapps.list > $XDG_CONFIG_HOME mimeapps.list > $XDG_CONFIG_HOME $desktop-mimeapps.list > Another opinion is voiced by IgnorantGuru, the developer of SpaceFM. He points out that separate [Default Applications] is redundant and is a big step away from KISS principle. List ordering in [Added Associations] should be enough to change/determine default application. Thank you for your time! ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Hi Ryan, (sorry for the delay, I was travelling) On Wednesday 09 April 2014 13:20:01 you wrote: > hi, > > On Wed, Apr 9, 2014, at 11:31, David Faure wrote: > > Yes. But don't forget that there are mimeapps.list at other levels > > (XDG_CONFIG_*), where there are no desktop files at all. > > > > And therefore no cache there, but the point is that the algorithms in our > > libs > > have to take this into account as well. For instance we can't say that a > > mimeapps.list can only refer to .desktop files of that current level and > > below, since at the /etc level that would mean: none. > > I think we crossed meanings somewhere along the way. From my view, > *all* of the desktop files are "below" ~/.config and /etc, because they > are in directories that come later in the list (in precedence order). You are right, I remembered wrong the ordering from the spec. OK, the main point remains though: we need our library code to be able to handle mimeapps.list files that are not in a binary cache -- it in fact sits on top of the binary cache. So my proposal is to extend that to the mimeapps.list files that live within the data dirs, i.e. where the binary caches are. If we follow your suggestion to even deprecate added/removed in data dirs, then we can expect that this will not hurt performance, compared to integrating the added/removed into the binary caches. -- 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: mime apps specification
hi, On Wed, Apr 9, 2014, at 11:31, David Faure wrote: > Yes. But don't forget that there are mimeapps.list at other levels > (XDG_CONFIG_*), where there are no desktop files at all. > > And therefore no cache there, but the point is that the algorithms in our > libs > have to take this into account as well. For instance we can't say that a > mimeapps.list can only refer to .desktop files of that current level and > below, since at the /etc level that would mean: none. I think we crossed meanings somewhere along the way. From my view, *all* of the desktop files are "below" ~/.config and /etc, because they are in directories that come later in the list (in precedence order). I don't mean "below" in the sense of "inside of exactly the same directory". I suspect we should make sure we understand the same thing before proceeding further :) Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Tuesday 08 April 2014 13:36:28 Ryan Lortie wrote: > On Tue, Apr 8, 2014, at 3:55, David Faure wrote: > > Adding and removing mimetypes (at all levels) is "patching the complete > > view of .desktop files for the current user". > > I have come to think of this as a mistaken idea. There are just too > many steps in the process if we handle it this way. > > Let's say we have the desktop cache available at each level which has > desktop files (which is the ideal case for considering the performance > characteristics). Yes. But don't forget that there are mimeapps.list at other levels (XDG_CONFIG_*), where there are no desktop files at all. And therefore no cache there, but the point is that the algorithms in our libs have to take this into account as well. For instance we can't say that a mimeapps.list can only refer to .desktop files of that current level and below, since at the /etc level that would mean: none. > When constructing the desktop cache, I want to be able to make a simple > list of which mime associations are added and removed by this directory. > I specifically don't want to have to keep a separate list of "mime > types added via desktop files here" vs. "mime types added via > mimeapps.list". I think we have no other choice, given the above. We need code that handles mime types added by mimeapps.list, for the handling of mimeapps.list in config dirs, anyway. So once we have that, we might as well use the same code for the data dirs - either directly opening the file, or grabbing the file from the cache if it makes things faster. At this point I'm not even sure it makes things faster/simpler, so I'd be ok with just using the mimeapps files directly. Which would mean, in turn, that the cache is really about the .desktop files only. > This allows a very simple algorithm: I go through the directories once > and collect the added types (applying the blacklist at each step). I > don't then have to make a second pass through all the directories > checking the mime information from the desktop files. This is > particularly problematic when considering 'removed' associations added > at an intermediate level. > > For example, this (perhaps slightly ridiculous case): > > /usr/share/applications/foo.desktop: > > MimeTypes=text/plain > > /usr/local/share/applications/mimeapps.list: > > Removes foo.desktop from text/plain > > ~/.local/share/applications/foo.desktop > > MimeTypes=text/plain This particular example could be argued both way Way 1: foo.desktop in ~/.local is most local so it wins. Way 2: our merged database from the user's point of view (aka "complete view") of .desktop files says "foo supports text/plain", but an administrator removed that at the /usr/local level for a given group of users, which applies after looking at the desktop files, so it should be ignored. I think I don't really mind which outcome we pick for this particular example. > In order to know that the mime type in foo.desktop in ~/ are to be > ignored, I first have to go down through the list a first time to > collect the mimeapps.list information and then come back up for a second > go through the desktop file information. Recall that both of these sets > of information are in the same cache file. Maybe that's where the "will to optimize further" comes from :) If we don't cache mimeapps.list, what would be the problem with saying "first parse all mimeapps.list, then query the .desktop database, which is composed of a (small) number of binary caches" ? > [...] > Even assume that these extra checks are expensive. So maybe that means > in terms of performance, the situation is actually a wash -- but I still > think that the expectation would be that a mimeapps.list in > /usr/share/applications acts as a modification to the MimeTypes= lines > in the files that we find there. What about mimeapps.list in /etc/xdg or in ~/.config? You are back to trying to associate config dirs with data dirs, and this cannot possibly be done (one could have 2 config dirs and 3 data dirs, actually that's even the default setup). So no, I don't think this is the expectation. The most common use case will actually be a single set of .desktop files (/usr/share/applications) and a hierarchy of mimeapps.list to modify them. The handling of .desktop files in ~/.local is only something we have to take care of in addition, but I don't think it makes a major difference whether this has more or less priority than lines in mimeapps.list. I.e. I'm fine either way, it just seems to me that treating all mimeapps.list on top of all .desktop files is a simpler rule than trying to mix and match in dirs that have both, then have different handling in config dirs (which only have mimeapps.list)... > Certainly, I might be confused if I install an app that lists support > for a particular mime type, but it's not supporting it due to something > listed in a lower-level directory. Yes. However I don't e
Re: mime apps specification
hi, On Tue, Apr 8, 2014, at 3:55, David Faure wrote: > Adding and removing mimetypes (at all levels) is "patching the complete > view of .desktop files for the current user". I have come to think of this as a mistaken idea. There are just too many steps in the process if we handle it this way. Let's say we have the desktop cache available at each level which has desktop files (which is the ideal case for considering the performance characteristics). When constructing the desktop cache, I want to be able to make a simple list of which mime associations are added and removed by this directory. I specifically don't want to have to keep a separate list of "mime types added via desktop files here" vs. "mime types added via mimeapps.list". This allows a very simple algorithm: I go through the directories once and collect the added types (applying the blacklist at each step). I don't then have to make a second pass through all the directories checking the mime information from the desktop files. This is particularly problematic when considering 'removed' associations added at an intermediate level. For example, this (perhaps slightly ridiculous case): /usr/share/applications/foo.desktop: MimeTypes=text/plain /usr/local/share/applications/mimeapps.list: Removes foo.desktop from text/plain ~/.local/share/applications/foo.desktop MimeTypes=text/plain In order to know that the mime type in foo.desktop in ~/ are to be ignored, I first have to go down through the list a first time to collect the mimeapps.list information and then come back up for a second go through the desktop file information. Recall that both of these sets of information are in the same cache file. If I want to do it in one go, I must keep track of which additions to the applications for a supported mime type came from mimeapps.list and which came from (universally lower-priority) desktop files. The caveat of this is that at each level, I have to take care not to do anything for mimeapps entries that refer to desktop files present at a higher level. This is not a substantial problem with the way my code is already structured. Even assume that these extra checks are expensive. So maybe that means in terms of performance, the situation is actually a wash -- but I still think that the expectation would be that a mimeapps.list in /usr/share/applications acts as a modification to the MimeTypes= lines in the files that we find there. This implies that a new desktop file at the homedir level would ignore these modifications. Certainly, I might be confused if I install an app that lists support for a particular mime type, but it's not supporting it due to something listed in a lower-level directory. Note: this discussion is _only_ about added/removed. We might sidestep the whole issue by saying that only the ~/.config and /etc versions of the files can add and remove associations (since this feature is of questionable usefulness in the files installed directly alongside the .desktop files where such changes could be made directly). Effectively, then, all mimeapps.list added/removed tweaks are above all desktop file MimeTypes= lines by simple geography of directory precedence, as well as by the spec. That's sort of nice. This would give us trouble for compatibility with ~/.local/share/applications/ however, where these features are in active use today. It's also a weird arbitrary restriction. > > In order to simplify the above logic we should separate the handling of > > defaults entirely. Any language about 'default' implying 'added' should > > be removed. > > I'm ok with that. I think that the handling of defaults, on the other hand, should not pay any mind to desktop files installed at particular directories. This is something that always makes sense to inherit from the system. This is yet another reason that it makes sense to cleanly divide these concepts, I think. > > I consider it to be an open question as to what happens if Defaults > > "picks" an application that is installed but not listed as supporting > > the mimetype (either by not having it listed in the desktop file, or by > > the user having removed the association). I think this is actually not > > a very interesting question because anyone who sets something as a > > default should either make sure that it is supported (and not 'Removed' > > by user config) and/or explicitly mentioned in 'Added'. > > Yes. > > > I would even be happy to leave this implementation defined. > > I don't think we need to say that. If it's marked as default, it's > selected as > default, there is nothing implementation-specific there. I've firmed up my thinking here, as well: if we find an app that has been listed as the default for a given type, but after handling MimeTypes/Added/Removed for this mime type, we find that the app is not on the list, then we must fallback to the next default. This will nicely deal with the case of having an app listed as the defa
Re: mime apps specification
On Monday 07 April 2014 10:08:51 Ryan Lortie wrote: > hi, > > On Mon, Apr 7, 2014, at 9:45, Bastien Nocera wrote: > > Using this example. > > > > System-wide: > > - eog.desktop isn't available > > - gthumb.desktop is available > > - mimeapps.list says: > > image/bmp=eog.desktop;gthumb.desktop; So basically the distribution, or the DE, is saying "eog is better than gthumb". > > User-wide: > > - no mimeapps.list > > - eog.desktop is available > > > > I would expect gthumb.desktop being the default for the user. No, I would expect eog to be selected. After all, it's the better app, according to the distro/DE. > > Meaning > > that even if the mimeapps.list contains multiple values, it would only > > check for desktop files/applications availability at the same level. > > This matches my expectations as well (at least I think it does...) I'm pretty sure it doesn't :) Remember, we talked about this during the summit, and we both said "parsing mimeapps.list is orthogonal to collecting the .desktop files available to the user, which happens first and provides us with a complete view of all .desktop files available to the user, then we refine that with mimeapps.list". > but this is not how the spec is currently written. The spec doesn't say anything about the way "foo.desktop" gets resolved. It says neither "at the same level (or below)" nor "globally (= at all levels)". But since this is creating ambiguity, yes, we need to decide and write it down. > > I don't think we ever supported that, unless the mime-type was added at > > the user-level. Eg. if x.desktop has support for text/plain, it always > > does even at the user-level. If you have a x.desktop in ~/.local/share/applications/ then it masks the global one, it doesn't get merged with it (as discussed last week, too). This is exactly why we need to first collect a complete view of all .desktop files, and then to handle mimeapps.list. So maybe having both in the same cache is not a good solution. When Ryan said that things like the mimetype-lookup in the cache wouldn't handle mimeapps.list, I actually assumed the cache would only be used for the "complete view of the .desktop files", and that it wouldn't contain mimeapps.list. If it also contains mimeapps.list, as later discussed, then we still need to keep in mind that it can point to .desktop files outside the current level. (if the cache simply has .desktop files as strings, that's fine). i.e. we shouldn't try to fully merge mimeapps.list and .desktop files in the cache at a given level. > After a bit more thinking, it seems desirable to make the following > tweaks: > > At each level that we have added and removed associations referring to a > desktop file that resides in the same directory as the mimeapps.list > file, we should treat the Added and Removed associations as being > exactly equivalent to this file having been edited and those entries > added/removed from the MimeTypes field. Yes but not only "in the same directory". We moved mimeapps.list to XDG_CONFIG_*, there are no desktop files in these directories. Adding and removing mimetypes (at all levels) is "patching the complete view of .desktop files for the current user". > We should forbid [added] or [removed] entries in the desktop-specific > *-mimeapps.list files -- only defaults should be allowed here. This > means that I can now give a canonical list of "mime types supported by > this app" per desktop file in a given directory and not have it be > desktop-dependent. This simplifies the cache. I agree with this, there is no real use case for it. > When mimeapps.list exists in directories above the directories where the > desktop file exists (ie: in the homedir for a desktop file in /usr) then > we should treat added/removed here as equivalent to copying the file > from the lower directory to the current directory, with the MimeTypes= > line tweaked by any changes we found along the way. Given all the possible locations for mimeapps.list (config dirs and data dirs), the notion of "above" isn't clear. I would rather say: as viewed by the current user, the above is right, adding/removing is equivalent to a local copy of the .desktop file. But this means in the /usr/ cache, all we can do is write down the added/removed mimetypes, not apply them to the .desktop files from /usr. > In order to simplify the above logic we should separate the handling of > defaults entirely. Any language about 'default' implying 'added' should > be removed. I'm ok with that. > I consider it to be an open question as to what happens if Defaults > "picks" an application that is installed but not listed as supporting > the mimetype (either by not having it listed in the desktop file, or by > the user having removed the association). I think this is actually not > a very interesting question because anyone who sets something as a > default should either make sure that it is supported (and not 'Removed' > by user config)
Re: mime apps specification
hi,
On Mon, Apr 7, 2014, at 9:45, Bastien Nocera wrote:
> Using this example.
>
> System-wide:
> - eog.desktop isn't available
> - gthumb.desktop is available
> - mimeapps.list says:
> image/bmp=eog.desktop;gthumb.desktop;
>
> User-wide:
> - no mimeapps.list
> - eog.desktop is available
>
> I would expect gthumb.desktop being the default for the user. Meaning
> that even if the mimeapps.list contains multiple values, it would only
> check for desktop files/applications availability at the same level.
This matches my expectations as well (at least I think it does...), but
this is not how the spec is currently written.
> I don't think we ever supported that, unless the mime-type was added at
> the user-level. Eg. if x.desktop has support for text/plain, it always
> does even at the user-level. The glib API seems to match that
> interpretation with g_app_info_can_remove_supports_type().
static gboolean
g_desktop_app_info_can_remove_supports_type (GAppInfo *appinfo)
{
return TRUE;
}
After a bit more thinking, it seems desirable to make the following
tweaks:
At each level that we have added and removed associations referring to a
desktop file that resides in the same directory as the mimeapps.list
file, we should treat the Added and Removed associations as being
exactly equivalent to this file having been edited and those entries
added/removed from the MimeTypes field.
We should forbid [added] or [removed] entries in the desktop-specific
*-mimeapps.list files -- only defaults should be allowed here. This
means that I can now give a canonical list of "mime types supported by
this app" per desktop file in a given directory and not have it be
desktop-dependent. This simplifies the cache.
When mimeapps.list exists in directories above the directories where the
desktop file exists (ie: in the homedir for a desktop file in /usr) then
we should treat added/removed here as equivalent to copying the file
from the lower directory to the current directory, with the MimeTypes=
line tweaked by any changes we found along the way.
All of the above depends _only_ on Added and Removed.
In order to simplify the above logic we should separate the handling of
defaults entirely. Any language about 'default' implying 'added' should
be removed.
I consider it to be an open question as to what happens if Defaults
"picks" an application that is installed but not listed as supporting
the mimetype (either by not having it listed in the desktop file, or by
the user having removed the association). I think this is actually not
a very interesting question because anyone who sets something as a
default should either make sure that it is supported (and not 'Removed'
by user config) and/or explicitly mentioned in 'Added'. I would even be
happy to leave this implementation defined.
It would also be nice if we could see mention in the spec about "if
applications want to order the keys in added, it should do it by MRU
order, but this is optional" in order to document the only existing
implementation that cares about this order and to prevent other
implementations from thinking that it is appropriate to use the order
for something else. Implementations that do not care about order are
free to ignore it and certainly don't need to update it.
Cheers
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sun, 2014-04-06 at 19:50 -0400, Ryan Lortie wrote: > hi David, > > On Wed, Apr 2, 2014, at 11:06, David Faure wrote: > > After so many years, he's finally a proposal for a unified mechanism for > > selecting the default application for a given mimetype. > > A couple notes after my attempts to integrate this work with the desktop > file index: > > The multiple defaults thing is a bit strange and it makes the cache more > complex. It would be nice to just give the desktop file ID for each > type. This was something that was possible using the old defaults.list: http://pkgs.fedoraproject.org/cgit/shared-mime-info.git/tree/defaults.list#n13 But this is a fallback that's implemented based on the available desktop files. Using this example. System-wide: - eog.desktop isn't available - gthumb.desktop is available - mimeapps.list says: image/bmp=eog.desktop;gthumb.desktop; User-wide: - no mimeapps.list - eog.desktop is available I would expect gthumb.desktop being the default for the user. Meaning that even if the mimeapps.list contains multiple values, it would only check for desktop files/applications availability at the same level. > What is the interaction between the mime cache and replaced desktop > files? > > Specifically, imagine this situation: we have 'x.desktop' in ~ and /usr. > In /usr it supports MimeType=text/plain, but the .desktop file in ~ has > no such mention. In /usr it is listed in mimeapps.info as the default > for text/plain. > > As written, the spec suggests that because x.desktop is mentioned as the > default for text/plain we should implicitly add it. What if it was in > Added, though? It seems that, at any given level, having an Added > association for a desktop file that already lists the mime type among > its MimeTypes= should be redundant, but here we see that we would get a > different result. I don't think we ever supported that, unless the mime-type was added at the user-level. Eg. if x.desktop has support for text/plain, it always does even at the user-level. The glib API seems to match that interpretation with g_app_info_can_remove_supports_type(). > Is this desirable? What does it mean if the user replaces a desktop > file with one in their homedir that has a more restrictive set of > supported mimetypes? Probably that means that the version that they > install does not support the wider range, and then the added association > is probably inappropriate -- doubly so if it was only there in order to > break a tie over the choice of default. > > Thoughts? Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sat, 2014-04-05 at 15:04 -0400, Jasper St. Pierre wrote: > No idea how "DPNH" got there. Cat on a keyboard or something. > > > RealPlayer was an app known for making terrible forceful > customizations to the user's system on Windows. If you deleted the > Start Menu, Desktop, or Quick Launch shortcut and ran RealPlayer, it > would notice and re-add all the shortcuts. If it wasn't the default > MIME handler, it would silently reregister itself for all media types > it supported. > > > Having an official way to do this is a way to tell ISVs that they > *should* do this, We also have official ways to delete every user owned files... > that it's recommended practice if you have an app that handles a MIME > type. Apps that want to force their way into the user's customizations > are RealPlayer, and we should let them feel shameful hacking > up /usr/share/applications/mimeapps.list on install, and bare the > responsibility if it breaks, not give them an API for it. This is silly. In the long run, those files won't be accessible to applications. Right now, applications can already set themselves as the default application for each user when they're run, it was simply implemented in desktop/toolkit-specific ways. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
hi David, On Wed, Apr 2, 2014, at 11:06, David Faure wrote: > After so many years, he's finally a proposal for a unified mechanism for > selecting the default application for a given mimetype. A couple notes after my attempts to integrate this work with the desktop file index: The multiple defaults thing is a bit strange and it makes the cache more complex. It would be nice to just give the desktop file ID for each type. What is the interaction between the mime cache and replaced desktop files? Specifically, imagine this situation: we have 'x.desktop' in ~ and /usr. In /usr it supports MimeType=text/plain, but the .desktop file in ~ has no such mention. In /usr it is listed in mimeapps.info as the default for text/plain. As written, the spec suggests that because x.desktop is mentioned as the default for text/plain we should implicitly add it. What if it was in Added, though? It seems that, at any given level, having an Added association for a desktop file that already lists the mime type among its MimeTypes= should be redundant, but here we see that we would get a different result. Is this desirable? What does it mean if the user replaces a desktop file with one in their homedir that has a more restrictive set of supported mimetypes? Probably that means that the version that they install does not support the wider range, and then the added association is probably inappropriate -- doubly so if it was only there in order to break a tie over the choice of default. Thoughts? Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Once we get sandboxed applications (which afaict are still in the works), apps will no longer be able to touch ~/.local and will only see their own ~/.config. So it makes sense to let them control mime associations through a dbus call instead of having them do their own work. I have a feeling this is something else that will have to be standardized down the line as we would want apps to only have a single dbus interface for this. I'm just speculating though; I'll have a look at implementing something like this in LXQt once I'm back home. Cheers J. Leclanche On Sun, Apr 6, 2014 at 2:50 AM, Mark Edgington wrote: > On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote: >> For what it's worth, I agree. However the use case of browsers asking >> to be default has to be taken into account, and we are very far from >> being able to offer them an api to *properly* become so. > > Hi Jerome, > > I recall someone mentioning on this list not to long ago the idea of > having desktop-environment-specific applications which are able to run > with slightly higher privileges than "ordinary user applications". I > don't know what all would have to go into making something like this a > reality, but to me it makes a lot of sense. > > For example, if such a separation of privileges were possible, then a > user could, via standard desktop-environment configuration tools, > choose among a set of applications registered for a particular use, > deciding which one(s) should be default (or that the user should be > prompted to choose between when opening some kind of > resource/document). But, a mere web-browser or other application > would not have the necessary privileges to make such a change -- the > only thing they would be allowed to do is to launch the > desktop-environment "default apps" tool, and give the user > instructions on what they should do if they wish to make "browser X" > the default. Of course "ordinary apps" would be allowed to register > themselves as handlers for different MIME types, but they would not > have the authority / permissions to make themselves default -- that > decision would be something a user would explicitly need to choose via > the desktop-environment's config tools. > > Nonetheless, even if the above (separate permissions) scenario were to > exist, it would still be important to have some kind of standard API > for choosing a single default and/or preferred-set of apps to handle > different MIME-types, so that this information could be shared between > different desktop-environments, and so that desktop-environment > developers would have a standard by which to develop their > "default-app selection" tools. > > What do you think about this? How feasible would something like this > be to implement? If it could be implemented, it would certainly > guarantee a lot more user-control over preferred apps, etc. > > Regards, > > Mark ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote: > For what it's worth, I agree. However the use case of browsers asking > to be default has to be taken into account, and we are very far from > being able to offer them an api to *properly* become so. Hi Jerome, I recall someone mentioning on this list not to long ago the idea of having desktop-environment-specific applications which are able to run with slightly higher privileges than "ordinary user applications". I don't know what all would have to go into making something like this a reality, but to me it makes a lot of sense. For example, if such a separation of privileges were possible, then a user could, via standard desktop-environment configuration tools, choose among a set of applications registered for a particular use, deciding which one(s) should be default (or that the user should be prompted to choose between when opening some kind of resource/document). But, a mere web-browser or other application would not have the necessary privileges to make such a change -- the only thing they would be allowed to do is to launch the desktop-environment "default apps" tool, and give the user instructions on what they should do if they wish to make "browser X" the default. Of course "ordinary apps" would be allowed to register themselves as handlers for different MIME types, but they would not have the authority / permissions to make themselves default -- that decision would be something a user would explicitly need to choose via the desktop-environment's config tools. Nonetheless, even if the above (separate permissions) scenario were to exist, it would still be important to have some kind of standard API for choosing a single default and/or preferred-set of apps to handle different MIME-types, so that this information could be shared between different desktop-environments, and so that desktop-environment developers would have a standard by which to develop their "default-app selection" tools. What do you think about this? How feasible would something like this be to implement? If it could be implemented, it would certainly guarantee a lot more user-control over preferred apps, etc. Regards, Mark ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
"Default web browser" means "I handle x-scheme-handler/http and x-scheme-handler/https" from the current implementation's POV. J. Leclanche On Sun, Apr 6, 2014 at 12:12 AM, Jasper St. Pierre wrote: > Why do browsers want to be the default? For what MIME types? > > > On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote: >> >> For what it's worth, I agree. However the use case of browsers asking >> to be default has to be taken into account, and we are very far from >> being able to offer them an api to *properly* become so. >> J. Leclanche >> >> >> On Sat, Apr 5, 2014 at 9:04 PM, Jasper St. Pierre >> wrote: >> > No idea how "DPNH" got there. Cat on a keyboard or something. >> > >> > RealPlayer was an app known for making terrible forceful customizations >> > to >> > the user's system on Windows. If you deleted the Start Menu, Desktop, or >> > Quick Launch shortcut and ran RealPlayer, it would notice and re-add all >> > the >> > shortcuts. If it wasn't the default MIME handler, it would silently >> > reregister itself for all media types it supported. >> > >> > Having an official way to do this is a way to tell ISVs that they >> > *should* >> > do this, that it's recommended practice if you have an app that handles >> > a >> > MIME type. Apps that want to force their way into the user's >> > customizations >> > are RealPlayer, and we should let them feel shameful hacking up >> > /usr/share/applications/mimeapps.list on install, and bare the >> > responsibility if it breaks, not give them an API for it. >> > >> > >> > On Sat, Apr 5, 2014 at 5:12 AM, David Faure wrote: >> >> >> >> On Friday 04 April 2014 16:54:01 Jasper St. Pierre wrote: >> >> > > No. Application here means ISVs. E.g. if a third-party application >> >> > > like >> >> > > Skype, Google Earth, etc. absolutely wants to make itself default >> >> > > upon >> >> > > installation. >> >> > >> >> > This seems like a poor choice to me. Do we have any use cases for >> >> > this? >> >> > It >> >> > seems to me like this would be giving the app the RealPlayer API, >> >> > which >> >> > is >> >> > not something I'm comfortable doing. DPNH >> >> >> >> I don't understand the relation to RealPlayer or "DPNH", >> >> but about the whole ISV idea is: since I suspect some apps will want to >> >> set >> >> themselves as default upon installation (even if we don't agree with >> >> it), >> >> we >> >> might as well provide a way to do this cleanly rather than seeing these >> >> apps >> >> hack into /usr/share/applications/mimeapps.list. >> >> In any case this is the same level as sysadmin customizations, so >> >> whether >> >> or >> >> not ISVs use it doesn't change anything to the spec. >> >> >> >> -- >> >> 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 >> > >> > >> > >> > >> > -- >> > Jasper >> > >> > ___ >> > xdg mailing list >> > xdg@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/xdg >> > > > > > > -- > Jasper ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Why do browsers want to be the default? For what MIME types? On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote: > For what it's worth, I agree. However the use case of browsers asking > to be default has to be taken into account, and we are very far from > being able to offer them an api to *properly* become so. > J. Leclanche > > > On Sat, Apr 5, 2014 at 9:04 PM, Jasper St. Pierre > wrote: > > No idea how "DPNH" got there. Cat on a keyboard or something. > > > > RealPlayer was an app known for making terrible forceful customizations > to > > the user's system on Windows. If you deleted the Start Menu, Desktop, or > > Quick Launch shortcut and ran RealPlayer, it would notice and re-add all > the > > shortcuts. If it wasn't the default MIME handler, it would silently > > reregister itself for all media types it supported. > > > > Having an official way to do this is a way to tell ISVs that they > *should* > > do this, that it's recommended practice if you have an app that handles a > > MIME type. Apps that want to force their way into the user's > customizations > > are RealPlayer, and we should let them feel shameful hacking up > > /usr/share/applications/mimeapps.list on install, and bare the > > responsibility if it breaks, not give them an API for it. > > > > > > On Sat, Apr 5, 2014 at 5:12 AM, David Faure wrote: > >> > >> On Friday 04 April 2014 16:54:01 Jasper St. Pierre wrote: > >> > > No. Application here means ISVs. E.g. if a third-party application > >> > > like > >> > > Skype, Google Earth, etc. absolutely wants to make itself default > upon > >> > > installation. > >> > > >> > This seems like a poor choice to me. Do we have any use cases for > this? > >> > It > >> > seems to me like this would be giving the app the RealPlayer API, > which > >> > is > >> > not something I'm comfortable doing. DPNH > >> > >> I don't understand the relation to RealPlayer or "DPNH", > >> but about the whole ISV idea is: since I suspect some apps will want to > >> set > >> themselves as default upon installation (even if we don't agree with > it), > >> we > >> might as well provide a way to do this cleanly rather than seeing these > >> apps > >> hack into /usr/share/applications/mimeapps.list. > >> In any case this is the same level as sysadmin customizations, so > whether > >> or > >> not ISVs use it doesn't change anything to the spec. > >> > >> -- > >> 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 > > > > > > > > > > -- > > Jasper > > > > ___ > > xdg mailing list > > xdg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xdg > > > -- Jasper ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
For what it's worth, I agree. However the use case of browsers asking to be default has to be taken into account, and we are very far from being able to offer them an api to *properly* become so. J. Leclanche On Sat, Apr 5, 2014 at 9:04 PM, Jasper St. Pierre wrote: > No idea how "DPNH" got there. Cat on a keyboard or something. > > RealPlayer was an app known for making terrible forceful customizations to > the user's system on Windows. If you deleted the Start Menu, Desktop, or > Quick Launch shortcut and ran RealPlayer, it would notice and re-add all the > shortcuts. If it wasn't the default MIME handler, it would silently > reregister itself for all media types it supported. > > Having an official way to do this is a way to tell ISVs that they *should* > do this, that it's recommended practice if you have an app that handles a > MIME type. Apps that want to force their way into the user's customizations > are RealPlayer, and we should let them feel shameful hacking up > /usr/share/applications/mimeapps.list on install, and bare the > responsibility if it breaks, not give them an API for it. > > > On Sat, Apr 5, 2014 at 5:12 AM, David Faure wrote: >> >> On Friday 04 April 2014 16:54:01 Jasper St. Pierre wrote: >> > > No. Application here means ISVs. E.g. if a third-party application >> > > like >> > > Skype, Google Earth, etc. absolutely wants to make itself default upon >> > > installation. >> > >> > This seems like a poor choice to me. Do we have any use cases for this? >> > It >> > seems to me like this would be giving the app the RealPlayer API, which >> > is >> > not something I'm comfortable doing. DPNH >> >> I don't understand the relation to RealPlayer or "DPNH", >> but about the whole ISV idea is: since I suspect some apps will want to >> set >> themselves as default upon installation (even if we don't agree with it), >> we >> might as well provide a way to do this cleanly rather than seeing these >> apps >> hack into /usr/share/applications/mimeapps.list. >> In any case this is the same level as sysadmin customizations, so whether >> or >> not ISVs use it doesn't change anything to the spec. >> >> -- >> 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 > > > > > -- > Jasper > > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
No idea how "DPNH" got there. Cat on a keyboard or something. RealPlayer was an app known for making terrible forceful customizations to the user's system on Windows. If you deleted the Start Menu, Desktop, or Quick Launch shortcut and ran RealPlayer, it would notice and re-add all the shortcuts. If it wasn't the default MIME handler, it would silently reregister itself for all media types it supported. Having an official way to do this is a way to tell ISVs that they *should* do this, that it's recommended practice if you have an app that handles a MIME type. Apps that want to force their way into the user's customizations are RealPlayer, and we should let them feel shameful hacking up /usr/share/applications/mimeapps.list on install, and bare the responsibility if it breaks, not give them an API for it. On Sat, Apr 5, 2014 at 5:12 AM, David Faure wrote: > On Friday 04 April 2014 16:54:01 Jasper St. Pierre wrote: > > > No. Application here means ISVs. E.g. if a third-party application like > > > Skype, Google Earth, etc. absolutely wants to make itself default upon > > > installation. > > > > This seems like a poor choice to me. Do we have any use cases for this? > It > > seems to me like this would be giving the app the RealPlayer API, which > is > > not something I'm comfortable doing. DPNH > > I don't understand the relation to RealPlayer or "DPNH", > but about the whole ISV idea is: since I suspect some apps will want to set > themselves as default upon installation (even if we don't agree with it), > we > might as well provide a way to do this cleanly rather than seeing these > apps > hack into /usr/share/applications/mimeapps.list. > In any case this is the same level as sysadmin customizations, so whether > or > not ISVs use it doesn't change anything to the spec. > > -- > 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 > -- Jasper ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Friday 04 April 2014 16:54:01 Jasper St. Pierre wrote: > > No. Application here means ISVs. E.g. if a third-party application like > > Skype, Google Earth, etc. absolutely wants to make itself default upon > > installation. > > This seems like a poor choice to me. Do we have any use cases for this? It > seems to me like this would be giving the app the RealPlayer API, which is > not something I'm comfortable doing. DPNH I don't understand the relation to RealPlayer or "DPNH", but about the whole ISV idea is: since I suspect some apps will want to set themselves as default upon installation (even if we don't agree with it), we might as well provide a way to do this cleanly rather than seeing these apps hack into /usr/share/applications/mimeapps.list. In any case this is the same level as sysadmin customizations, so whether or not ISVs use it doesn't change anything to the spec. -- 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: mime apps specification
On Apr 3, 2014 4:31 AM, "David Faure" wrote: > > On Thursday 03 April 2014 01:39:27 Luc Menut wrote: > > The previous freedesktop specification was > > http://www.freedesktop.org/wiki/Specifications/mime-actions-spec > > I guess it will be deprecated by the current proposal. > > Yes. That wasn't even a spec, just a current state of affairs :) > As soon as I push the spec I'll update that wiki page to point to the spec. > > > What about KDE's InitialPreference and Gnome's defaults.list? > > IIUC, I guess that they are deprecated too, and will be respectively > > replaced by kde-mimeapps.list and gnome-mimeapps.list. > > Yes. > > > But at which level? "application vendors" (= $XDG_DATA_HOME/applications)? > > No. Application here means ISVs. E.g. if a third-party application like Skype, > Google Earth, etc. absolutely wants to make itself default upon installation. This seems like a poor choice to me. Do we have any use cases for this? It seems to me like this would be giving the app the RealPlayer API, which is not something I'm comfortable doing. DPNH > The recommended location for the initial kde-mimeapps.list and gnome- > mimeapps.list provided by the distribution (or by kde/gnome themselves when > compiling from source) is $XDG_DATA_DIRS/applications/$xdc-mimeapps.list > > > The proposed lookup order = preferences order is > > users > sys-admin > vendors > distribution > > Depends what you mean by vendor. If you mean KDE, it's part of the > distribution. If you mean Skype, it's at the same level as sysadmins. > > > If desktop environments install their default preferences > > ($xdc-mimeapps.list) at vendors level, desktop environments preferences > > will override distribution preferences (when they overlap). > > No, distributions will adjust the desktop environment preferences. > > > Then, if a distribution wants to modify a desktop environment preference > > for a mimetype, the only way seems to patch the desktop environment > > $xdc-mimeapps.list? or have I missed something? > > Yes. Is there a strong need to keep the "upstream mimeapps.list" unchanged? It > just seems to add yet another level in the list, which is already quite big. > > -- > 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 ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Le 03/04/2014 10:31, David Faure a écrit : On Thursday 03 April 2014 01:39:27 Luc Menut wrote: The previous freedesktop specification was http://www.freedesktop.org/wiki/Specifications/mime-actions-spec I guess it will be deprecated by the current proposal. Yes. That wasn't even a spec, just a current state of affairs :) As soon as I push the spec I'll update that wiki page to point to the spec. What about KDE's InitialPreference and Gnome's defaults.list? IIUC, I guess that they are deprecated too, and will be respectively replaced by kde-mimeapps.list and gnome-mimeapps.list. Yes. But at which level? "application vendors" (= $XDG_DATA_HOME/applications)? No. Application here means ISVs. E.g. if a third-party application like Skype, Google Earth, etc. absolutely wants to make itself default upon installation. The recommended location for the initial kde-mimeapps.list and gnome- mimeapps.list provided by the distribution (or by kde/gnome themselves when compiling from source) is $XDG_DATA_DIRS/applications/$xdc-mimeapps.list OK, thanks for the clarification. The proposed lookup order = preferences order is users > sys-admin > vendors > distribution Depends what you mean by vendor. If you mean KDE, it's part of the distribution. If you mean Skype, it's at the same level as sysadmins. OK If desktop environments install their default preferences ($xdc-mimeapps.list) at vendors level, desktop environments preferences will override distribution preferences (when they overlap). No, distributions will adjust the desktop environment preferences. Then, if a distribution wants to modify a desktop environment preference for a mimetype, the only way seems to patch the desktop environment $xdc-mimeapps.list? or have I missed something? Yes. Is there a strong need to keep the "upstream mimeapps.list" unchanged? It just seems to add yet another level in the list, which is already quite big. You are right, this looks good. Thanks regards, Luc -- Luc Menut Mageia Contributor ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Thursday 03 April 2014 10:01:49 Alexander Larsson wrote: > On ons, 2014-04-02 at 17:06 +0200, David Faure wrote: > > In the absence of such an entry, the next mimeapps.list is checked. > > Once all levels have been checked, if no entry could be found, the > > implementations can pick any of the .desktop files associated with the > > mimetype, taking into account added and removed associations as per > > the previous section. > > In the *next* section. (I guess you moved the section). Indeed. > Otherwise this looks good to me. Thanks! Thanks for the review. The spec is now up at http://www.freedesktop.org/wiki/Specifications/mime-apps-spec/ -- 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: mime apps specification
On Thursday 03 April 2014 01:39:27 Luc Menut wrote: > The previous freedesktop specification was > http://www.freedesktop.org/wiki/Specifications/mime-actions-spec > I guess it will be deprecated by the current proposal. Yes. That wasn't even a spec, just a current state of affairs :) As soon as I push the spec I'll update that wiki page to point to the spec. > What about KDE's InitialPreference and Gnome's defaults.list? > IIUC, I guess that they are deprecated too, and will be respectively > replaced by kde-mimeapps.list and gnome-mimeapps.list. Yes. > But at which level? "application vendors" (= $XDG_DATA_HOME/applications)? No. Application here means ISVs. E.g. if a third-party application like Skype, Google Earth, etc. absolutely wants to make itself default upon installation. The recommended location for the initial kde-mimeapps.list and gnome- mimeapps.list provided by the distribution (or by kde/gnome themselves when compiling from source) is $XDG_DATA_DIRS/applications/$xdc-mimeapps.list > The proposed lookup order = preferences order is > users > sys-admin > vendors > distribution Depends what you mean by vendor. If you mean KDE, it's part of the distribution. If you mean Skype, it's at the same level as sysadmins. > If desktop environments install their default preferences > ($xdc-mimeapps.list) at vendors level, desktop environments preferences > will override distribution preferences (when they overlap). No, distributions will adjust the desktop environment preferences. > Then, if a distribution wants to modify a desktop environment preference > for a mimetype, the only way seems to patch the desktop environment > $xdc-mimeapps.list? or have I missed something? Yes. Is there a strong need to keep the "upstream mimeapps.list" unchanged? It just seems to add yet another level in the list, which is already quite big. -- 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: mime apps specification
On ons, 2014-04-02 at 17:06 +0200, David Faure wrote: > In the absence of such an entry, the next mimeapps.list is checked. > Once all levels have been checked, if no entry could be found, the > implementations can pick any of the .desktop files associated with the > mimetype, taking into account added and removed associations as per > the previous section. In the *next* section. (I guess you moved the section). Otherwise this looks good to me. Thanks! ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Thu, Apr 3, 2014 at 12:39 AM, Luc Menut wrote: > Le 02/04/2014 17:06, David Faure a écrit : > >> After so many years, he's finally a proposal for a unified mechanism for >> selecting the default application for a given mimetype. >> >> The mechanism is unified, but note that it supports different defaults for >> different desktop environments, if so desired. >> >> This is the result of a discussion with Ryan Lortie, Alex Larsson and >> myself, >> I'm sending it here for further comments before pushing it to the git >> repo. >> >> > > Great work. Many thanks, it's really nice to see improvements and > standardization on this. > > I have some questions about this specification proposal. > > The previous freedesktop specification was > http://www.freedesktop.org/wiki/Specifications/mime-actions-spec > I guess it will be deprecated by the current proposal. > > What about KDE's InitialPreference and Gnome's defaults.list? > IIUC, I guess that they are deprecated too, and will be respectively > replaced by kde-mimeapps.list and gnome-mimeapps.list. > But at which level? "application vendors" (= $XDG_DATA_HOME/applications)? We were going to include defaults.list in the spec, but we decided to just ignore it. GNOME will still be reading it as fallback but it will be deprecated. > > The proposed lookup order = preferences order is > users > sys-admin > vendors > distribution > > If desktop environments install their default preferences > ($xdc-mimeapps.list) at vendors level, desktop environments preferences will > override distribution preferences (when they overlap). > > Then, if a distribution wants to modify a desktop environment preference for > a mimetype, the only way seems to patch the desktop environment > $xdc-mimeapps.list? or have I missed something? I think you're correct. It's 6am though so I can hardly say "I think", but it seems acceptable to me. > > > regards, > Luc > > -- > Luc Menut > Mageia Contributor > ___ > xdg mailing list > xdg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg J. Leclanche ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
Le 02/04/2014 17:06, David Faure a écrit : After so many years, he's finally a proposal for a unified mechanism for selecting the default application for a given mimetype. The mechanism is unified, but note that it supports different defaults for different desktop environments, if so desired. This is the result of a discussion with Ryan Lortie, Alex Larsson and myself, I'm sending it here for further comments before pushing it to the git repo. Great work. Many thanks, it's really nice to see improvements and standardization on this. I have some questions about this specification proposal. The previous freedesktop specification was http://www.freedesktop.org/wiki/Specifications/mime-actions-spec I guess it will be deprecated by the current proposal. What about KDE's InitialPreference and Gnome's defaults.list? IIUC, I guess that they are deprecated too, and will be respectively replaced by kde-mimeapps.list and gnome-mimeapps.list. But at which level? "application vendors" (= $XDG_DATA_HOME/applications)? The proposed lookup order = preferences order is users > sys-admin > vendors > distribution If desktop environments install their default preferences ($xdc-mimeapps.list) at vendors level, desktop environments preferences will override distribution preferences (when they overlap). Then, if a distribution wants to modify a desktop environment preference for a mimetype, the only way seems to patch the desktop environment $xdc-mimeapps.list? or have I missed something? regards, Luc -- Luc Menut Mageia Contributor ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: mime apps specification
On Wednesday, 2014-04-02, 17:06:47, David Faure wrote: > After so many years, he's finally a proposal for a unified mechanism for > selecting the default application for a given mimetype. > > The mechanism is unified, but note that it supports different defaults for > different desktop environments, if so desired. > > This is the result of a discussion with Ryan Lortie, Alex Larsson and > myself, I'm sending it here for further comments before pushing it to the > git repo. Great work guys! Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
