[FileTypes] some images open in WebPositive

[diver]

PNG images in /boot/system/data/artwork now open in WebPositive and not in ShowImage.
Could be related to hrev36471.

Tested with hrev36482 in VirtualBox.

[stippi]

Yes, the problem is that WebPositive claims direct support for image/png (and gif and jpeg). I consider the behavior of hrev36471 generally correct. We could either remove the supported types from WebPositive, since there is really no good point to show images in WebPositive, or we could make ShowImage the preferred applications of some image types that we specify ourselves. Both would fix the problem. The algorithm introduced in hrev36471 cannot be smarter about preferring applications, since from its point of view, ShowImage is more generic than WebPositive, and WebPositive is thus the better choice. The same situation would be if you installed an image viewer with special support for JPEG files. In that case you would also prefer that image viewer for JPEG files over a generic image viewer like ShowImage, even if neither is defined as preferred app for image/jpeg.

[axeld]

I think this shows a general issue with hrev36471 - it dictates a specific use of the supported file types that we currently don't really adhere to.

While there is nothing wrong with this per se, it pretty much renders the preferred application of the super type useless, as well as specifically supporting a super type.

If an application says it can handle all image types, and is even set as the preferred application for the image super type, I think the assumption that the user prefers to open a sort of random application that supports the type directly is wrong. In that light, I would change hrev36471 such that it always use the preferred applications first, and only then refers to the apps that can handle the file.

[stippi]

I think you didn't think this through. For image/*, ShowImage is a really adequate default/preferred application. For text/* however, StyledEdit is in no way similar to ShowImage. In fact, if I changed the behavior to what you suggest, I would be back to square one and the behavior which I tried to fix would be back in place. text/html would launch with StyledEdit again, since it is the preferred handler for text/*. I think the solution is really to remove image/* from the supported types of WebPositive. Why would a user want to open an image file with WebPositive? Why would anyone even want it to appear in the "Open With" menu of some image?

[axeld]

StyledEdit is fine as a generic text/ handler IMO. What you tried to solve was what should happen when the preferred handler is missing in action, but ultimately this is a configuration issue. Your change weakens the preferred application meaning for no good reason; you are making the user configuration of this a lot harder than necessary this way, as one has to choose a preferred application for all sub-types now to prevent some random application from coming up.

If you want to have a smart solution, I think the best would be to only fall back to an application supporting the type instead of a preferred one, if a) there is no preferred app, or b) if the sub-type already overrides the preferred super-type application (but the override couldn't be opened). IMO this would neatly solve your problem without the drawbacks your solution introduced.

[stippi]

Ok we agree it's a configuration issue. What I don't agree with is that it's always better to fall back to the preferred application of the super type, even if a supporting application exists that would handle the specific type better than the preferred application of the super type. Consider the example of image/svg+xml. The user has conveniently configured ShowImage for image/* even though there may actually be image types, such as image/svg+xml, which ShowImage doesn't even handle at all. So I believe the misconfiguration is at the application level, when applications claim to support a specific type, even though they don't have a good reason for this at all. Indeed WebPositive directly supports image/png, but there is no good reason to inject this information into the MIME type database resolving system, since WebPositive is a web browser, not an image viewer.

To address your specific proposal for a solution, I don't believe it would solve the issue. That there is no preferred type configured for the sub-type should be the common case, so how would that be different to what I implemented? And there being a misconfiguration with the preferred app missing should be the minority of cases, which is again addressed by my change.

[axeld]

Considering the svg+xml case: this is indeed a configuration issue as well, but this is how it should work, and is far simpler to fix than going the other way around (for the user).

You haven't commented yet on the random application launch. Because this is what will happen for the majority of the cases.

You also didn't comment on making the preferred application configuration unbearable to the user. What you implemented will generally ignore the preferred application, as that is usually only done for the super type -- out of convenience.

So IMO, unless you come up with a better configuration of the preferred application, please revert your changes. It solves a corner case, and causes a bad user experience.

And while my suggestion obviously wouldn't replicate your solution's features (intentionally so), it would solve the problem that urged you to look into the issue.

I would welcome other people's insights on this.

[stippi]

In the case when there are many applications with support for the specific type indeed a seemingly random application will be picked. This can easily be solved by specifying a preferred application for the specific type. I don't believe we will or should have applications which claim support for the same specific type in the default image. So this problem comes up when the user installs many similar applications and then he will know what's going on and can fix this easily.

The second case of seemingly random applications launching is when there are many applications claiming support for the super type. But this is exactly the situation that you point out, which is that one application will already be configured as preferred for the super type.

So for me, it boils down to your argument that there is now more configuration necessary than before, which I believe is wrong. Let me show you how that is not the case for me: Haiku predefines several MIME types for text. Many of which have a preferred application hard-coded. For x-email it's Mail. For x-source-code it's Pe, a 3rd party package. For html it is BeZillaBrowser, another 3rd party app. This just shows how broken the system was before. When I run a clean image of Haiku for the first time, I always have to configure Pe to be the preferred app for several text/ MIME types, since I want makefiles and jamfiles to open in Pe. With my change, I won't have to do this anymore, since Pe should claim support for these specific types, while StyledEdit should not and with my change, the system will automatically pick Pe (granted, as long as I have only one editor installed, but that should be the case). If we were to put another editor on the image to replace Pe, the system would still work, without having to mess with the predefined MIME types, just like we would have had to mess with text/html prior to my change.

IMHO, the different super types have very different needs actually. With image/* it's almost sensible to have a preferred application, but already image/svg+xml shows how the system can be flawed. With text/*, StyledEdit is not a preferred application, it is a fall-back application at best. And in fact I believe this is the situation for the majority of types, i.e. application/*. For video/* and audio/* we have another case similar to image/*. But here it is even more sensible to control the preferred application via the super type and handle special cases with sub-types.

In any of these cases, I find it more practical, if the system automatically choses an application that handles a type well, and not a fall-back application that just handles the super type. I believe it will require less configuration, as seen in my example for text files where I have to manually configure Pe to replace StyledEdit.

As for reverting the changes, you have not managed to convince me at all and I would like feedback from other users before I would revert this change.

[axeld]

Thanks for the in-depth answer :-)

Anyway, the examples with the 3rd party apps is really not that bad, as those actually were installed on the alpha. I agree with the fall-back notion of StyledEdit, but Pe cannot be really called a fall-back solution anymore (this is my preferred text/ application).

Now on for a real life example: my own Haiku installation. Under "image" I have about 15 different types - none of those (besides x-tiff, x-iff, x-iff-ilbm which point to ArtPaint) have a preferred application set. For good reason, as each of those types list about 5 different applications that support them, like ArtPaint, WonderBrush, Thumbnail, "ShowImage to EXIF" (only for JPEG), and BeZillaBrowser as well as WebPositive (still the old version here). ShowImage never supports any of the types directly, as it already handles the super type.

Now, if I wanted to retain current behaviour after your patch, I would have to change the preferred applications of all of those types manually. Moreover, I certainly wouldn't like to launch Tracker add-ons this way accidently. How does that result in less configuration? The situation looks better for video, but equally or worse for audio, and text (how does "Mark as Read" sound as a default app when double clicking a mail?).

The system is indeed flawed, but I don't think your patch actually really improves the situation overall. Adding all supporting types to something like ShowImage doesn't really make sense, as it doesn't even know what types it supports - only the translators do know that. If that wouldn't be the case, a simple improvement over your patch would drastically improve the situation: if one of the supporting apps is also the preferred app for the super-type, choose that one (that would also rectify the existence of the preferred apps for the super types). However, due to applications not possibly being able to know what specific types they support, this will never be able to solve the situation completely.

[stippi]

The core problem that you describe only results from applications declaring the supported types too verbosely, and I don't yet know if that is a theoretical problem, or a problem that exists, but could be fixed by removing needlessly declared supported types from some apps. There are certainly some that declare too many. You are absolutely right that ShowImage does not know which image/* type it supports. The same is true for ArtPaint, WonderBrush and a dosen other apps that load images via the Translation Kit. If all these apps declare to support image/* and then only their native image type (image/x-wonderbrush, image/x-artpaint or whatever) and no other types needlessly, then the problem you describe doesn't actually exist in practice, since you can configure ShowImage as the preferred app for image/* and it will always be chosen except for image/x-wonderbrush and image/x-artpaint.

Similarily with Tracker add-ons, I don't know what part of your argument is a real problem versus a theoretical problem, since I am pretty sure that text/x-email is associated with Mail, so Mark-As-Read should not randomly open if you double click a Mail. If it does, then it's a bug.

To sum up, the problem that you describe can be fixed once, by removing needlessly declared support for specific types (in packages and our own apps). MediaPlayer is a good example, it should only declare audio/* and video/*, I don't even know why it declares so many specific types as supported. I think this still stems from a time when the MIME database was not properly setup on a fresh image.

[tangobravo]

It seems the issue stems from two possible interpretations of what a super-type "preferred" app is actually for.

With ShowImage, it should probably be the "default" app for image/* whereas StyledEdit is probably more of a fall-back for text/*. The correct thing to do for these two cases is different, hence which solution is better is not clear.

My vote would be for keeping the original behaviour, despite thinking that it seemed a good solution when I read Stephan's commit. I like to understand the decisions the OS is making on my behalf, and though I like it to do the right thing, in some ways it's more helpful if it does the wrong thing and yet it is clear why it has done that and it can be easily fixed. Adding the additional layer of possibility to the app that might be loaded (along with the intrinsically "random" choice) makes it harder to come up with a good mental model of what's going on.

After breaking binary compatibility it would be good to separate the concepts of preferred default handler and fall-back handler for the super-type. In the fall-back case other applications that support the type would win whereas in the default case the preferred super-type handler would win.

[tangobravo]

Not sure I agree with myself really!

The specific case Stippi fixed was the one where a subtype preferred handler is defined and could not be found, and is different to the preferred handler for the supertype. That seems like it should be a fairly rare occurrence (only after removing the preferred application). So maybe it's reasonable to put up the full Open With... dialog, with some text at the top explaining "The preferred handler for HTML Files (BezillaBrowser) could not be found. Please select the application to use to open this file."

[tangobravo]

So the cases would be:

Preferred handler set for subtype - use that one. Preferred handler not set for subtype but set for supertype - use the supertype handler. The "best" handler that is set (subtype > supertype) could not be found - full Open With dialog. No preferred handlers set - full Open With dialog.

A handler that is set preferred but not found is a configuration problem, and one which the open with dialog will allow the user to fix straight away.

[stippi]

I will implement Axel's suggestion to only use other supporting apps as fallback, i.e. when there is a misconfiguration in the MIME database. If a sub-type has no preferred app configured, the new algorithm would immediately fall back to the super type preferred handler, even if there are apps installed that claim direct support for the sub-type. This allows any app to declare support for specific sub-types (even when it makes no sense to do so) and still have a deterministic behavior.

[stippi]

Done in hrev36500.

[bonefish]

Replying to tangobravo:

So the cases would be:

Preferred handler set for subtype - use that one. Preferred handler not set for subtype but set for supertype - use the supertype handler. The "best" handler that is set (subtype > supertype) could not be found - full Open With dialog. No preferred handlers set - full Open With dialog.

That would be pretty close to the situation before hrev36471. Though with the exception that previously, if there was no preferred application for sub- or supertype, some application supporting the requested type would be chosen. If there is only one application, that's pretty certainly what the user would want. If there are several apps, you may be right, asking the user may be the best option (at least the one the user can see through easily).

A handler that is set preferred but not found is a configuration problem, and one which the open with dialog will allow the user to fix straight away.

Yep, that might indeed be the least surprising option. The question would be how to change the API to not break applications that expect a certain behavior. The "Open with..." dialog is built into Tracker. Applications using BRoster::Launch() won't automatically have it.

Regarding the general discussion:

• Yes, the current MIME database concept is insufficient. As is it can't describe the actual relationships between types. E.g. SVG is XML and that is text, but it is also an image format. The subtype/supertype concept doesn't fit at all.
• Yes, the default handler for supertypes is kind of nonsense. It does somehow work for text/, because in the end all text can be opened with some fallback plain text editor, but that obviously doesn't work the same way for audio/, image/, or video/ (and not at all for the other, more obscure, types). For those types we just have generic mechanisms (translation/media kit), and applications using those mechanisms can open all the thusly supported types. They still cannot open all subtypes.
• I disagree with Stippi that "needless" supported types should be removed from applications. If WebPositive supports PNG, I don't see a good reason for it not to announce that. Maybe some PNGs look prettier in WebPositive, or sometimes the user wants to use the built-in histogram or watermark analyzer features. Removing supported types just to make the broken algorithm work is not a good solution.
• I agree with Axel that in absence of a preferred app for the subtype favoring the preferred app of the supertype, if it supports the subtype explicitly, is a good solution. The problem that applications using the translation/media kit do not know what subtypes they actually support can be solved by introducing dummy types (e.g. image/x-vnd.haiku.translation-kit) and adding explicit recognition of those in BRoster. As a temporary solution for the alpha 2 release I would simply add all the subtypes manually.