This is an RFC. I'm not yet completely convinced that it's a great idea. There is quite some substantial complexity in implementing the list of removed associations, particularly at the point where this intersects with mime inheritence. There have been a couple of threads on the list about this. One "radical" idea that would solve this would be to remove the ability to remove associations entirely. ie: if app app claims that it can open image/jpeg, then it will always be on the list of apps that can open image/jpeg. You can't change that. "Remove association" APIs on libraries would be limited to removing associations that the user themselves established (ie: removing [Added Association] entries). If you really think about it, this is a somewhat questionable feature, and having it in the spec substantially complicates the implementation. Marking this feature optional would be a good first step toward eliminating it entirely.
IMHO, this is unneeded complication that breaks the logic. Simple iteration of hierarchical additions and removals should not be changed.
I disagree. Let the users be in charge. If they don't want to see a certain app being started (for a certain type of files, or for all), they should be able to say so.
(I meant: I disagree with this proposal; not with comment #1)
Sorry for the noise, reassigning to new (since 2 years) maintainers (Ryan & David).
If you're not convinced and I'm not convinced, I guess there's not much point in keeping this open :-)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.