Option to autostart double clicked file in smart attach
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
You can just select the .prg and click 'Autostart', which happens to be very close to the dir preview ?
Which is kind of far from the actual filelist to the left. I find this super annoying when browsing around testing stuff. I think this worked differently in the win32 gui, always autostarting. And now that I think of it also kept the last selected .d64 selected upon entering the dialog again.
Anyway, just a suggestion. If everyone wants open as default smart attach action, who am I do disagree. :)
That said, the issue is that we cannot reliably differenciate between the various file formats we support, so either double-click would mean autostart for all media, or open.
I don't like changing UI behaviour back and forth, double-click used to be 'autostart' but we changed it. I suppose I could look into a secondary-click on the files that pops up a menu with 'autostart'?
For me, I prefer autostart directly on double click for all files. I don't know what the reasoning behind changing it was, but a tick box somewhere in settings to toggle the default perhaps?
Secondary-click could be a nice bonus too of course. It would simplify doing open if autostart was the default and vice versa.
BTW, the fact that double clicking in the disk image directory currently autostarts is kind of inconsistent too, even though I personally find that useful.
I tried adding a resource to make the the double-clicking configurable. Alas, Gtk3 will not play along, both clicking the 'Open' button and double-clicking trigger the GTK_RESPONSE_ACCEPT response, which means at that point it's too late to check the resource (Open should at all times just attach an image). Adding a GTK_REPSONSE_ACCEPT just for the double-click isn't supported.
So, I'm closing this. If you really want double-click to autostart images, a patch shouldn't be too hard to write and apply whenever you check out and build VICE.
This works in r38622 assuming x64sc -autostart-on-doubleclick is used.
Double clicking a file in the left view (file list) or right view (image view) will autostart it.
Selecting an image file in the left view (file list) and clicking "autostart" will autostart the first file on that image using LOAD "*",8,1. This however happens even if there is a file selected in the right view (image view).
The behaviour of "open" is strange, it seems to attach an image if one was selected. For an .prg it seems to do nothing.
...and to clarify in r38622 without -autostart-on-doubleclick it then isn't possible to autostart specific files from the right view (image view) at all. On top of that no files can be "load":ed because "open" behaves in a strange way.
The 'Open' and 'Autostart' buttons indeed attach images. Opening/autostarting a file inside an image is a separate action, triggered from the directory widget.
The 'load file from image when double-clicking' doesn't work yet, that requires new code that attaches the image and then loads, but not runs, the selected file. Easiest way to do that seems to be to alter the autostart code to optionally not issue "RUN:<cr>" in the emulated machine, but working on the autostart code makes me a sad panda =)</cr>
So I'm still working on this, but the going is slow.
Can't you plug into the "-autoload" code?
Not sure I understand, but after grepping for 'autoload', it looks like I can set
autostart_modetoAUOSTART_MODE_LOAD. So I should then be able to use the autostart code to load without running? And afterwards restoreautostart_modeto its resource value?One small issue might be people saving settings during autoload/autostart, like I did when loading a demo and noticing the vicii border was 'normal', so I switched to 'full' and saved settings and every time after that x64sc would start with warp active :)
I'm going to revert this. Doesn't make things any more logical from a UI-standpoint and leads to very messy/unmaintainable code.
It'll also lead to more imcomprehensible bug reports. (ie we'd have to ask "did you check the autostart-on-doublelclick" checkbox, did you click or doubleclick in the left file list or did you use the 'Open', 'Autostart' buttons? Did you select a file in the directory preview on the right. Did it even exist, and so, did you click or doubleclick and what was the status of the "Autostart-on-doubleclick" check somewhere else in the UI? And finally did you svn up and use -default?".
Open will mean 'attach image', Autostart will attempt to attach the image and then autostart the first file in the image. Double-clicking in the directory listing will randomly autostart/autoload.
I can understand abandoning it if it's too hard to implement. Just looking at this from a UI consistency view.
I just feel that, what I assume is the most common operation (autostart), should be the default on double click. It does not really need to be switchable.
In the GTK version it is not the default for .prg files which I personally use extensively when developing for the target machine. For WinVICE autostart is the default, and maybe in other ports too?
If it always autostarted on double click there'd be a lot of accidental autostarts when someone wanted to swap disks during a demo or game. The impact of an accidental open is a lot lower, no lost state
I thought swapping disks was done with the attach disk dialog? Never tried doing that with smart-attach, but I guess that's because WinVICE didn't work this way.
As we discussed back and forth on IRC, an autostarting dialog could even be separate. Two menu entries, one for the current "Smart attach disk/tape/cartridge..." and one for "Smart autostart disk/tape/cartridge...". I assume this is also at least as messy to code as the abandoned solution though.
Current process: ALT-A, click file, move mouse to click "autostart". Still, compyx made fantastic improvements in keeping the last selected items in view when re-entering the dialog, so the process is much less of a pain now.
Sorry about the rant, but I got a little frustrated I couldn't even follow my own code anymore, so to avoid weird behaviour/bugs, I felt it was in the UI to just remove what I had so far, =)
About swapping disks, I usually do that via 'attach disk', but at some point that dialog also did the autostart-on-doubleclick, which indeed ruined some demo viewing sessions for me, trying to autostart the new image instead of just attaching and letting the demo load.
knowing VICE developments, i am willing to bet that - once again - WinVICE was the only port behaving different, and once again ppl think its how all ports behaved and should behave
i also like to stress what dqh said. that was pretty much the main reason behind making it work like it does work.
Perhaps. I only note that it mildly frustrates me when I browse around to run different software. I swap disks much more rarely than I start different stuff. I do acknowledge both usecases are valid, hence the suggestion for different dialogs for attach vs autostart.
Let's keep this open. There are decent arguments here. For me personally, and not because I wrote a lot of the Gtk3 UI code, I prefer a consistent UI and clean and understandable code.
I think we have some plans to refactor a lot of the Gtk3 UI code, so perhaps then we can pick this back up.
Having a separate 'autostart' dialog, next to the 'smart-attach' would probably only lead to confusion in my opinion. But people are free to work on that, I'm not the Gtk3 UI dictator, cough
I don't like the idea of having a seperate dialog at all. We already have two of them, instead of one as we should have :)
I wouldn't mind having a single 'attach' dialog. This will work for disk image, tape image, containers (t64, zipdisk, lynx) and .crt files. It will not work for .bin cart images. I just tried smart-attaching and autostarting 0-3-Generic8K-Centide.bin, didn't work.