Unexpected "Load" configuration behaviour..

[tbone2k-git]

Describe the bug
If you have configurations stored in ./conf, these will show up in the configuration panel of course. What happens on what click on one of these configuration items, is kind of difficult to tell though, maybe some double click handling has gone wrong/missing?

To Reproduce
Single click a configuration which is NOT currently selected, will NOT load it and will NOT start the emulation, it just changes the name in the field below, but if you click that item again some time later, all of a sudden the configuration is loaded and the emulation is started (which is very unexpected behaviour).

I think loading and running the emulation should happen on double click at least? Right now you have to be very careful in that section to not click accidentally on an already selected entry, to not lose your current configuration. Also when saving to an existing configuration, you need to make sure, you select another item first, then select the configuration item you want to be reused, then click Save. You could click "Save" right away, if you notice the right configuration item is already selected, but hey.. this is very tricky in day to day use and something you probably can't remember if some weeks have past since last use.

Expected behavior
Load and run emulation on double click only would help a lot to prevent unwanted loading/running.

• OS: Debain12
• Version v5.7 and 6.3preview

Love Amiberry?
Yes! o)

Thank you for taking the time! o)

[tbone2k-git]

More unexpected things, please watch this..

• I load Amiberry by double clicking the binary
• I go to "Configurations"
• There are multiple configurations listed:
  • "tb_script_startup_defaults"
  • "tb_script_startup_defaults2"
  • "tb_script_startup_defaults3"
• I Select "tb_script_startup_defaults"
• I Set text cursor by mouse into configuration file name text field at end / last position
• I enter / add a single "3" -> the text field now reads "tb_script_startup_defaults3", which matches an existing config
• Then I click (once) on the config item "tb_script_startup_defaults3" and..
  instead of just selecting that config, it will load and start the emulation.

Wrapping up:
If the name in the text field is equal to what item is being single clicked, it will load and run the emulation unexpectedly.

[midwan]

Improved the behavior somewhat:

• Now you need a proper double click (the second click must be within 1 second) to trigger a Load/Start action on a config file. You can select an item with a single click again, and if it's not detected as a double-click action, nothing will happen except updating the Text fields (in case they don't match).

[tbone2k-git]

Very nice! o) I will test drive once available.. o)

One more suggestion to that fix:
If you don't respect system settings, maybe it's better to use the default of Linux or Windows as double click delay time (around 400-500ms)? An unusual long double click delay time will also the lower the user experience (for no reason I guess, unless you have a technical barrier, not supporting shorter double click delay time). This sounds like nit picking for sure, but sticking to what worked for 35+ years and what is expected standard on major platforms and GUI based tools, is probably not a bad thing?

Some background on my "nit picking":
I am investigating the Linux world for more than a year now, and some things are just unnecessarily hard or diverging from expected standards - like drag 'n drop operations on a Linux desktop. On Linux, clicking an application window will bring it to the front on "mouse-down" already, instead of on "mouse-up" (as on Windows e.g.). Sounds like a minor difference, but has following huge, negative side effect: If you want to drag 'n drop something from a source-window to a target-window which is in front of the source-window , you can't!

The source-window will come to the front and hide the target window while you are aiming for your drop target. The target window might be hidden completely if you are in bad luck, at least the drop target section will be hidden most of the time. So you end up with drag-things dangling useless on your mouse-pointer! o)

I'm not sure why this is and it sounds like a mini minor detail not worth talking about, but it's enough to ruin the desktop experience for advanced users (I think). Workaround? Resize and position windows on the Linux desktop before you start dragging and dropping, which is obviously very inconvenient for single or quick drag 'n drop actions (and for no reason I assume).

So, maybe you agree?
This is actually less of nit picking, it's keeping usability as high as the standards we developed over the last few decades.

Thank you for taking the time and have a nice day! o)

[midwan]

Modified to 500ms

[tbone2k-git]

Thank you, top notch! o)