Unexpected "Load" configuration behaviour.. about amiberry HOT 5 CLOSED

Modified to 500ms

from amiberry.

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.

from amiberry.

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).

from amiberry.

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)

from amiberry.

Thank you, top notch! o)

from amiberry.