We should have better housekeeping wrt screenshots...

[giantclambake]

Keep in mind ....

savestate_dir=/home/gcb/Desktop
screenshot_dir=/home/gcb/.local/share/amiberry/screenshots/

....over time, things can end up looking like this (or worse ;)...

ls ~/Desktop/*.uss
 /home/gcb/Desktop/AceBall_v1.0_Pl_AGA.uss      /home/gcb/Desktop/AmigaTestKit-2.uss    /home/gcb/Desktop/yyyyyy.uss
 /home/gcb/Desktop/amiga-os-134-workbench.uss   /home/gcb/Desktop/Apocalypse.uss
 /home/gcb/Desktop/AmigaTestKit-1.uss          '/home/gcb/Desktop/Stunt Car Racer (1989)(Micro Style).uss'

ls ~/.local/share/amiberry/screenshots
 1001StolenIdeas_v1.01_Airwalk-14.png       Apidya_v2.05_Audios_2465-14.png   MegaAGS-1.png
'242_v1.2_Fairlight&VirtualDreams-14.png'   Apocalypse.png                    MontyPythonsFlyingCircus_v1.3_0273.png
'242_v1.2_Fairlight&VirtualDreams.png'     'Cannon Fodder (Europe)-14.png'   'Stunt Car Racer (1989)(Micro Style)-1.png'
 AceBall_v1.0_Pl_AGA-13.png                 CannonFodder_v2.0_0860-14.png    'Stunt Car Racer (1989)(Micro Style)-2.png'
 AceBall_v1.0_Pl_AGA.png                    ClassicWB-P96-test.png           'Stunt Car Racer (1989)(Micro Style)-3.png'
 Akira_v1.2_CD32.png                        default-12.png                   'Stunt Car Racer (1989)(Micro Style)-4.png'
 amiga-os-134-workbench.png                 default-4.png                    'Stunt Car Racer (1989)(Micro Style).png'
 AmigaTestKit-1.png                         dpaint-14.png                     StuntCarRacerTNT_v1.3-12.png
 AmigaTestKit-2.png                         dpaint-2.png                      SysInfo.png
 AmigaTestKit.png                           dpaint.png                       'wb13 teststatusline-14.png'
 amikit12-3.png                             Frontier_v1.3_CD32-4.png

....I can see this getting very messy, in really short time, and keep in mind here... amikit12-3.png is a 380Kb big .png file =) Worse...irrespective of the fact that savestate didn't work for amikit12, there is no real way (using amiberry) to delete the .uss file and/or the associated screenshot....it's there forever, (and who goes digging about in ~/.local/share/amiberry/screenshots anyhow, to clean out no longer required files?)...

The example above, is the crossover between desktop file management, and perhaps what amiberry is not doing ...ie; creating .uss files directly on the Desktop (or some other directory thereon), maximizes the usage of mime-type actions --- the desktop environment allows the user to delete these *.uss files as desired, but, the screenshots will remain.

I suspect I'm just averse to the situation wherein the program is generating stale/unused/wasteful files, that it no longer needs.

In an ideal world, amiberry should scan $savestate_dir for any *.uss files, then scan $screenshot_dir for any matching *.png files ... and delete any other image files found ...err...caveat would be able to distinguish between 'Screenshots' and images associated with Savestates..... (sounds like a lot of work)....or...

....have a Delete State button of some sort... which would probably need to be a dialog window, that displays all screenshots associated with .uss files, and you can select/delete those (which also deletes the associated .uss file if it exists)...still sounds like a lot of work...

Still, the same situation exists for Screenshots anyway...ie; you can take a screenshot in amiberry, but there's no way to display or manage (read: delete) any screenshot....

...I look at this comparo, and I wonder....

....presuming one day that OpenGL works in amiberry, you can bet the GUI menu panel will have 'Filter' item/panel...

.....that still leaves room in the menu panel area, for a Screenshots item and associated panel, where you can view or delete any .png files in $screenshot_dir, and if you delete a screenshot associated with a .uss file, the savestate is deleted as well (if in $savestate_dir).

Not that this is mission critical or anything like that, it's just an area wrt amiberry usage that I find is largely unmanaged, and the screenshots file count/diskspace used can 'blow out' ... pretty much un-noticed by the user as it were (especially when nested under the ~/.local/share/ location).... I can't help but think things could be improved here...

Thoughts?

TIA

[midwan]

Looks like several items for discussion in here. Let's take them one by one:

• There is actually a separate directory meant for the savestate screenshots, but currently it's set to the same path as the screenshots. The one I'm talking about, is named saveimage_dir, and could be set as a separate one, whereas screenshots would then contain those you take manually only. It needs an update to the path, default directory creation logic and the get/set functions for it, but it's not too much work otherwise. Maybe we should set that to the same dir as the savestates, which would then make it easier to see which .uss files have a corresponding .png one alongside them, and which ones are orphans?
  UPDATE: I checked WinUAE, and that path is not used for saving "screenshots" of savestates, but rather disk images. It's not really used in Amiberry currently, but I still think we shouldn't mix it up.
• If we do the above, then Screenshots should probably be more exposed (under the $HOME/Amiberry dir?). Maybe even the Savestates should be out there?
• I think we can easily add a Delete button for the save state slots, which would also delete the associated screenshot. The rest sounds like a file manager's job, if the user wants to keep track/clean up after their stuff. Especially if we expose those directories under HOME :)

[midwan]

This is now improved with the latest commits...

[giantclambake]

Yeah, conceptually the crux issue was Savestates & Screenshots sharing the same directory for image files. I was unaware of the variable saveimage_dir ~ realistically this should not be exposed to the user ; these are 'operational' files amiberry GUI uses to display .uss screenshots (even though WinUAE doesn't do this), and should be nested away somewhere under ..ie; ~/.local/share/amiberry/savestate-images .. (the fact WinUAE might not do this, I tend to absolve by thinking "Amiberry is an optimized emulator", and stuff like this falls under the 'optimized for user experience' umbrella =)

The Screenshots directory (for screenshots alone), the user can define in the Paths panel to their liking... no biggy...

I believe you ended up at the same point of resolution I did ~ provide a "proper" way to Delete the Savestate files (and associated screenshot files)....and the Delete slot button achieves those ends....

..if, OTOH, the user chooses to delete .uss files via the desktop file management route, then the onus is on them to clean-up any 'stale' Savestate screenshots that are no longer needed (and if they wish to avoid this, use the Delete slot button instead 8^)

I'll be sure to document all of this....but I concur, this is likely the 'sanest' way to manage these files ...I gave it a quick once over, and it seemed to be fine.... but I'll keep testing to ensure there's no oddities =)