This app is a Tracker add-on that helps bridge the missing link for opening apps not yet supported with the default Haiku’s Open With menu and/or editing FileTypes.
For example, even if you tell FileTypes to open all PNG files with GIMP, GIMP will open but fail to show the png file.
This also supports other apps that may not normally show up in the open with menu, like Kottan which I find really handy.
All you do is symlink your favorites apps to ~/config/settings/OpenWith folder and when you right click a file, select the Tracker add-on “Open With”. A popup will show on the screen giving you a choice which of your favorite apps to open the selected file with.
I understand what he is saying. This happens to me a lot, where I get only binary-hex options to read a simple text file off a CD, DVD, or USB stick, such as a simple text file like a ‘README’ file.
The graphics options, such as he stated, occurs with me as well…especially with JPGs and PNGs…where the Open With does not present graphic programs to select from.
I learnt to open the app before attempting to read what I want open and work with by drag and drop. The reason is the Open With menu option does not always work as intended; however, for most times it does.
If double-clicking on the file does not work, the Open With menu option should provide all apps to select from regardless of file type filtering.
Currently, if Open With cannot determine what file type the file is and what appropriate apps to present in some situations, it should not provide only binary-hex apps. It should all available apps that are installed to select from.
I will try to duplicate a scenario and provide a picture showing what I commonly encounter later.
From a read-only NTFS volume, I can perfectly open text files or image files with Open with..., it show StyledEdit and Pe (and any other text editor installed) for files detected as text ones, and for images there is ShowImage, ArtPaint, etc.
Here my Windows NTFS volume, mounted in readonly, when I right-click on a .txt file:
So either I don’t understand which action you’re referring, or there is something buggy that I’m not victim (yet?), maybe related to the kind of foreign file system? With what kind of file systems are you facing such issue ?
That’s because by default there is no Preferred application defined for “Flattened BMessage” (MIME type: application/x-vnd.Haiku-BMessage), and Kottan don’t declare itself as being able to accept this MIME type.
Another tool, msgdump, does, and it shows up in “Open with…” for BMessage files (like many settings files).
Configuring in FileTypes app to defined your preferred app will fix your issue. And maybe file a ticket to ask Kottan developer to modify his app so that it register as being able to open this MIME type.
Perhaps I should clarify the apps main intentions. it’s really for GTK apps like GIMP where open with and/or setting FileTypes does not work. Gimp will open but not load the selected file.
On a side note, I found it to be a perk it would work with Kottan. But again, the apps main intention was to help users open GTK apps when selecting a file to open with.
Probably the most useful case is in the example, a non native application that won’t accept file refs from tracker, or , since open with is based on mime types registered in the app, the user wants to open a file with a non registered mime with an app but surely it can be read (eg a text based file with a text editor)
Note: even if I set MD files to be read with Genio, in disks formatted with fat32 “open with” won’t show it as a suitable application for such MD files, and double clicking them will open them with the application set for the text super-type
Then you click the “Open with…” and select the app from the menu?
I guess the only difference is that it would use arguments to the command? but looking at the code it does not actually launch the app with either posix spawn or fork/exec but just goes through the roster instead
You mean the MIME sniffer don’t work on non BFS volumes ?
Then why it works for me on my NTFS volumes, mounted (always) as read-only ?
I think it’s supposed to works, or should, and deserve a defect ticket, if none already exists.
After, there is the suffix fallback, which indeed doesn’t seems to work at all, when it should.
It won’t change the situation for non native apps who don’t expose in there binary the resources to tell which MIME type they supports or not, I agree.
For those, there is two main issues
how can the OS discover which files suffixes and/or MIME types they support without any help from these binaries?
but if the user register such binary as their preferred app for a file type, it should works, even if MIME type was not sniffed, the suffix rules should works and the binary being called with the file(s) passed as their arguments.
This second part must be improved. For the first, there is not actual solution without an effort from the ported app/porter to do some registration. LibreOffice, for instance, does it, it’s part of the “addition” of the Haiku port.
at least it wont on fat32, while with an ntfs volume there is not this issue, both mounted RO; the file is the same, a readme.md shipped with the refind theme im using copied in that ntfs drive
the same file and its info window in a fat32, ntfs and bfs volume (mime type manually selected); ntfs recognize its as a plain text file not as a markdown file - that has not a sniffer rule
Weird, while both volumes are readonly, it’s like because NTFS has attributes support, MIME sniffer seems to be behaving differently, while in both case all what it has at hand is the file content, nothing else.
Maybe the registrar don’t run the MIME sniffer on volumes without attributes, considering it would be waste of time without a way to store it, dunno.
Deserves a deeper investigation. Could you repost this in a ticket?
Or it’s just a way for Micrsoft to promote again NTFS over FAT32!
