Gargoyle on Haiku

[extrowerk]

@cspiegel

I’m still learning Haiku’s method of package management (this sort of virtual filesystem overlay based on the hpkg files is really slick), so I’m not sure if it’s possible to include the XML file in that directory on install.

If you package the interpreter, you can package the xmls files with it, so they can land in that folder.
Or you can create an own recipe for the xml files and make your program package depend on it, so it gets automatically selected and installed.

[waddlesplash]

@cspiegel

But there’s a big difference with GNUInstallDirs on Haiku vs Unix: on Unix systems, CMAKE_INSTALL_LIBEXECDIR is a relative path, relative to CMAKE_INSTALL_PREFIX. So it’s just the bare string “libexec”. On Haiku, it’s the full path. This is allowed by CMake but since I’d never seen it before, I didn’t even think about it.

This actually might be something we should change in HaikuPorter’s CMake scripts. Haiku packages can technically be installed in more than just /, though sometimes hardcoded paths make this difficult; we should try to improve this.

On a different note, it is always nice to see upstream developers enthusiastically embrace support for Haiku, so kudos to you

[cspiegel]

@extrowerk

If you package the interpreter, you can package the xmls files with it, so they can land in that folder.
Or you can create an own recipe for the xml files and make your program package depend on it, so it gets automatically selected and installed.

Great, thanks. I wasn’t sure if that was a protected system directory or not.

[cspiegel]

@waddlesplash

On a different note, it is always nice to see upstream developers enthusiastically embrace support for Haiku, so kudos to you

And the support here has been great. I appreciate all the help and explanations as I’m stumbling my way through things.

[cspiegel]

@cspiegel

I think it’s worth trying, on Haiku, the approach of giving interpreters their own MIME types. The launcher would still be necessary for the types which can’t be sniffed, but otherwise, things can be launched directly. I’m still going to have to mull over some of the possible side effects of this, but it’s definitely something to try.

At this point I think it’s purely a packaging thing. There was one issue where I’d given two major versions of one game system the same MIME type, but I’ve now got a pull request in to change it to separate types. If Haiku learns these MIME types, then it should be possible to properly assign MIME types to interpreters now.

I’m also adding file-type probing to the launcher. This will take precedence over extensions, though not all file types are able to be probed, so extensions will exist as a fallback. So the launcher should be more robust on systems like Haiku where extensions aren’t really used. I’ll have that in within a day or so.

Thanks for all the help, everybody. It’s late here, so I’m done for the day, but I think tomorrow I’ll have Gargoyle’s source in a position where it’s ready for a proper Haiku release. Then it’ll be a matter of getting the recipe just right.

[waddlesplash]

@cspiegel

If Haiku learns these MIME types, then it should be possible to properly assign MIME types to interpreters now.

Haiku doesn’t actually need to learn the MIME types; you can ship definitions for them along with your application to be included as part of the system MIME database (at least this is theoretically supposed to work, but I don’t know how many applications actually do it.)

[nephele]

@waddlesplash

(at least this is theoretically supposed to work, but I don’t know how many applications actually do it.)

I’ve worked on a patch for the love2d recipe today to do just that, and it definetely is doable

@cspiegel

I’m also adding file-type probing to the launcher. This will take precedence over extensions, though not all file types are able to be probed, so extensions will exist as a fallback. So the launcher should be more robust on systems like Haiku where extensions aren’t really used. I’ll have that in within a day or so.

I found the api Haiku has to make it do the work for you as an alternative, though this won’t work with all file types always (haiku definetely can’t tell video/mp4 from audio/mo4 for example)
https://www.haiku-os.org/docs/api/Mime_8h.html

[cspiegel]

I think I’m missing something fundamental here. I’ve been able to add, programmatically, to the file type database with code similar to this:

BMimeType mime = BMimeType("application/x-blorb");
mime.Install();
mime.SetSnifferRule("0.5 ('FORM    IFRS' & 0xffffffff00000000ffffffff)");

Tracker now shows Blorb files appropriately. However this has the obvious problem that it requires the app to run first, which is a chicken and egg problem (I mean, it’s easy to fix by running it once, but that’s not the point). You guys are saying that definitions can be shipped, but I’m just not finding out how that works. Is it a file that’s just installed somewhere? I can write all the rules, but I don’t know where they go.

In short, I know there must be a way, non-programmatically, to specify MIME types + sniff rules as well as to specify which MIME types an application supports, but I’m just not following how that’s done on Haiku.

[waddlesplash]

Yes, there is a way to specify this information via resource definition files. Here, for example, is the one for ODT files. These get compiled, then resattr'd, and then the resulting file is installed to the relevant mime_db directory (I don’t recall the precise mechanism for this however; it sounds like @nephele may?)

[nephele]

In the additional-files folder of the recipe you can add rdef definition files for new MIMEtypes

As an example (The one I worked on yesterday)

x-love-game.rdef

resource(0, "BEOS:TYPE") #'MIMS' "application/x-vnd.Be-meta-mime";

resource(1, "META:TYPE") "application/x-love-game";

resource(2, "META:S:DESC") #'MSDC' "LÖVE game";

resource(3, "META:L:DESC") #'MLDC' "A LÖVE based game archive";

resource(4, "META:PREF_APP") #'MSIG' "application/x-vnd.love";

resource(5, "META:ICON") #'VICN' array {
    $"6E6369660403E74A9904004C0327AAE105FF040607FF1FC6D5B92DC6D5B92DC3"
    $"E7B632BFB9B354C0A2B354BE55B354B382BF8BB382BE47B382C025B945C651B6"
    $"52C358B982C62AB9F7C5CCB9BDC5FEBE5FC1A9C6D5B92DC38ABE34C6D5B92DB9"
    $"2D0607FF1FC731B9B7C731B9B7C3E6BEBEBA53C655BEBBC233BA19C688B9A1C6"
    $"DBB9DEC6B4BC6DC9AEC015CC4DBF57CC4DC1C3CC4DCC4DC015CC4DC130CC4DBF"
    $"4DC731B9B7C9E5BC75C731B9B7B9B70607FF1FC6D5B92DC6D5B92DC38ABE34B9"
    $"F7C5CCBE5FC1A9B9BDC5FEB945C651B982C62ABC11C925BFB9CBC3BEFBCBC3C1"
    $"67CBC3CBF1BF8BCBF1C0A6CBF1BEC3C6D5B92DC989BBEBC6D5B92DB92D0608FE"
    $"7FC01BBCBABCCABAE8BF08BA5FBA8CBB71BFC1C5B8B5DEC005BFC1C5B8BFBFC5"
    $"B840C5B8C9A2C005C2B7BAE8C4F4BB71C079BA5FBF66BCBABF66BCBABFA2BCBA"
    $"C01BBCBABFDFBCBAC01BBCBABCBA040A000100000A010101000A020102000A03"
    $"010300"
};

You then need to compile this source file to a .rsrc file, either during the build or before it, personally I would do it beforehand and ship both the .rsrc and .rdef file since I consider that a bit more obvious

rc -o x-love-game.rsrc x-love-game.rdef

After you have compiled the ressource add it to the recipe as an additional entry under ADDITONAL_FILES so that the build can pick it up.

afterwards just add it to the mime_db during the build INSTALL phase like so:

 # copy mimetype rsrc for love2d games
        mkdir -p $dataDir/mime_db/application/
        resattr -o $dataDir/mime_db/application/x-love-game $portDir/additional-files/x-love-game.rsrc

Basically: .rdef is the “source” text format for ressources, this gets compiled with rc, the ressource compiler, to a binary format and this then gets converted with resattr to a file that has all this information in different file attributes

I hope this was understandable, you can read more about rc here: Compile them resources | Haiku Project

You might also want to add sniffer rules to your mime type directly, I did not above because the love2d archive cannot be sniffed (It’s just a zip file), you can let yourself be inspired by other sniffer rules here: https://git.haiku-os.org/haiku/tree/src/data/mime_db (I don’t know the exact syntax either… I’ve only written the mp4 sniffer rule : D https://git.haiku-os.org/haiku/tree/src/data/mime_db/video/mp4 )

[PulkoMandy]

@nephele

I don’t know the exact syntax either…

The only place where the syntax is currently documented is in Darkwyrm’s “Programming with Haiku” book series. We should add docs to api.haiku-os.org about it.

[cspiegel]

OK, thank you guys for the pointers to resources and packaging. I’ve hacked up an ugly script to convert freedesktop.org XML MIME files to something that Haiku might understand; the example resource files were a huge help. It’s available here.

I’ve included a few sample resource files it generated. rc seems to handle them fine, though I haven’t been able to actually test whether they match files properly. It’s also really hacky, including lack of support for more complex matching (e.g. if there are multiple possible rules), breakage if the magic string contains quotes (needs escaping), and just hacking around the fact that globs are supported by the fdo XML (special-casing *.z[1-8] for example). It’s enough to convert the stuff I need, though.

I think this is the best plan for the next release: Include these resource files (once they’re verified as being good) with the Gargoyle source code; update the recipe to compile and install them; continue using custom probing in Gargoyle to handle files thrown at it; and associate MIME types with the launcher for the time being, not individual interpreters.

For the last point, I prefer maintaining status quo for the first Haiku-supported release; now that I’m getting more comfortable with Haiku development I can spend more time after the release improving things, but it looks like that will largely be recipe hacking, meaning updates to the recipe can happen in between Gargoyle releases.

A few people are working on HiDPI/Retina support for Gargoyle, and that’s the last roadblock, I think, before a real release. @nephele, is the recipe you created in a git branch somewhere? I can fork the appropriate repo to make contributing changes back to you easier before you get it into master (or whatever the appropriate release process is for ports).

[nephele]

It is not on a branch currently, I can make one if you would like, but I can’t submit it to haikuports directly since the workflow there is github pull requests and I lack a github account, so it might be faster if you submit it yourself : ).