You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 own
To 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
The text was updated successfully, but these errors were encountered:
....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)
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 own
To 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
The text was updated successfully, but these errors were encountered: