Clarify that we always prefer specific subtypes (like text/html) to the more generic types (like text/plain) when deciding on associations and default apps. This avoids some strange cases where applications that operate on text/plain are being taken in preference to more-specific applications, just because they are present in 'higher' directories, or explicitly listed in defaults files.
Created attachment 114832 [details] [review] mime apps: clarify precedence vs. subtypes Clarify that we always prefer specific subtypes (like text/html) to the more generic types (like text/plain) when deciding on associations and default apps. This avoids some strange cases where applications that operate on text/plain are being taken in preference to more-specific applications, just because they are present in 'higher' directories, or explicitly listed in defaults files.
This sounds logical. What is the way to determine if given MIME type is specific or generic?
Each mime-info entry has the ability to specify something like <sub-class-of type="text/plain"/> to designate itself as a special-case of another type.
Comment on attachment 114832 [details] [review] mime apps: clarify precedence vs. subtypes Yep, looks good to me. We completely failed to talk about mimetype inheritance indeed.
You asked in the email: "do we reset the blacklist (removed apps) between each iteration of the algorithm for the different types in the inheritance chain when building the list of apps that support a given type?". I would say no. If I blacklist gedit from text/plain, that means I don't want to see it popping up for a text/plain subclass either.
Sorry for the noise, reassigning to new (since 2 years) maintainers (Ryan & David).
Attachment 114832 [details] pushed as 01c809e - mime apps: clarify precedence vs. subtypes
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.