Open giantclambake opened 3 days ago
On the proviso that amiberry can direct-load a savestate.uss file, you could add the following XML snippet to packaging/linux/mime/amiberry.xml
file ~
<mime-type type="application/x-UAE-savestate-file">
<comment>UAE SaveState file</comment>
<generic-icon name="amiberry"/>
<magic-deleteall/>
<magic priority="60">
<match type="string" value="UAE" offset="16:18"/>
</magic>
<glob pattern="*.uss"/>
</mime-type>
....and include the following in the packaging/linux/Amiberry.desktop
file MimeType=
string ~
application/x-UAE-savestate-file
Note: Unlike floppy disk images and whdload game archives. there is no 'generic' icon file that really symbolizes a savestate.uss filetype (actions/edit-redo kinda works for me).... so I left it set to the amiberry icon. We could include another icon file for this purpose, or, choose another icon...but it would need be a 'generic' icon, to be assured of all systems actually having it present....(which is why applications include their own if needed 8)
HTH
Further to our discussions about this, I've just now discovered that...
gcb@gallah:~$
amiberry --statefile "Stunt Car Racer (1989)(Micro Style).uss" -G
..works as expected -> Note: to really leverage this,
amiberry "Stunt Car Racer (1989)(Micro Style).uss"
should work too ;)...it currently doesn't of course, but consider user might do ie;
savestate_dir=/home/gcb/Desktop
, and in that case [this] mime-type association would create a desktop launcher icon for these .uss files, which could be launched directly with amiberry, without the need for the --statefile switch ... more background.......I need your feedback wrt mime-type detection of the .uss filename extension ..chocky blocks...
the filename extension
.uss
is not declared in the current shared-mime-info database XML however, the.uss
extension is at the same time, (erroneously) claimed by the x-ms-asx mime-type detection the actual cause of this detection, is due to a match in the leading bytes of the.uss
file being ASF as with the *.lha file type mime-type handling, etiquette dictates overriding existing detection magic, and providing our ownTo that end, we can match the 7th byte (1E) but that seems a bit flimsy to me, but a better match is to be had by testing bytes 16 thru 18 (UAE) ... it seems sane enough to me... BUT..
..I have to ask you ~ can I rely on those bytes? I appears like I can, but it never hurts to ask (seeing as there's a version number thereafter, which is likely to change? ;)
TIA