Configurations, last loaded Item is automatically selected for no reason on Save / Delete..

Describe the bug I already pointed out some irritations in the Configurations panel in regards to the currently selected item and how it affects a single click (https://github.com/BlitterStudio/amiberry/issues/1316). There is additional irritation in that panel with some magic selection going on, if an item was loaded via "Load" or via the --config command line switch. The selection will always restore to that loaded config item when using "Save" or "Delete" buttons.

Restoring the selection to the last loaded item could make sense, as long as there was no other configuration saved yet and also no other settings (RAM, floppy etc.) have been toggled around yet, but that is not the case either. I can load a config, toggle a lot of settings around and the Configuration panel will still restore the selection to the last loaded item. If there is usefulness in seeing what item was loaded last, it should be a separate indicator in that configuration item list view and it should not interfere with the regular item selection, maybe make it bold(?) or have two columns to reflect "Loaded" -> "Yes" and another one called "Changed", which toggles to "Yes" once you flipped any emulator switch? Just a quick idea, out of the scope of this issue I guess.. o)

To Reproduce In the Configurations panel: "Save" button influences configuration item selection:

Select "config-01" by single click
Click "Load".
Select "config-02" by single click.
Save a new configuration as "config-03".

Unexpected: Selection will switch back to "config-01" (the one being loaded with "Load"). Expected: Selection should stay on "config-02" or maybe jump to the newly saved item "config-03", but not jump back to that config item, which was loaded last.

Same applies to "Delete" button, also influences item selection:

Select "config-01" by single click
Click "Load".
Select "config-02" by single click.
Select "config-03" by single click
Delete "config-03".

Unexpected: Selection will switch back to "config-01" (the one being loaded with "Load"). Expected: Selection should clear, so no item is selected after deleting the selected item or select next item further up/down in the list, but do not switch back the selection to that config item, which was loaded last.

Details: OS: Debian12 / PC x86 Version: 6.3preview

Thank you! o)

I cannot recreate this here either on Debian 12.5/x86-64 ... in fact it behaved as expected.. but that said, this is somewhat atypical usage, and some of it I feel may be interpretation/procedural wrt GUI usage itself. For example...

Select "config-01" by single click --> this highlights the config-01 entry

Click "Load". --> this will load the currently selected config-01.uae file into the emulator

Select "config-02" by single click. --> this highlights the config-02 entry [Note: config-01.uae is still loaded]

Save a new configuration as "config-03". --> this will clone/save the config-01.uae file as config-03.uae

When I Save that configuration, the name "config-03" appears in the list highlighted, and the Name: field is likewise populated with "config-03", however config-01.uae is still loaded in the emulator (because I haven't loaded any other config.uae file), and the list highlight & config Name: box jump back to "config-01", as that's the currently loaded config.uae file...

Same goes for the second example above ~ the actions of highlighting/selecting or deleting/saving any config.uae files, are ostensibly just that... 'file operations' ; in that passage you've loaded config-01.uae, selected config-02, then config-03 and deleted the latter ; same as above, everything jumps back to the currently loaded config.uae file.

As said though, this is atypical usage wrt amiberry, in as much as the configuration files entertained here are 'esoteric' in nature ... for example, following the steps above, I had to create a config-01.uae ...I actually loaded an ADF file (forgetting I had a matching .uae file for that disk image), and named it config-01 and clicked save, and in the GUI it jumped to the top of the list and the matching config.uae for that disk, because that's how the detection logic in amiberry works here =)

edit: 'typical' usage is having a config.uae file which is Named appropriately for the current Amiga media (floppy image/cd/hhd files) being loaded into the emulator. In normal practice there's never really the need for more than one config.uae for any Amiga game/workbench setup ... (there will always be corner cases ;).

There are two separate issues here, all caused by the "refresh" operation that happens after an action is taken in this panel (e.g. Load, Save, Delete). During the Refresh, the last loaded config will be highlighted automatically, among other things.

When you Save a new config, after having loaded another, the highlighted item should indeed be changed to that of the newly saved config. After all, it represents what's currently loaded as well, since what got saved, was what was currently in the settings. This will be fixed.
When Deleting a config, after having loaded another, the behavior is correct. The deleted one is removed from the list, a refresh operation is requested and the last loaded config is highlighted again.
When Deleting the same config you had loaded, the behavior is correct again. The deleted one is removed from the list, a refresh operation is requested, and since the last loaded config doesn't exist anymore, no item is highlighted in the list.

I cannot recreate this here either on Debian 12.5/x86-64 ... in fact it behaved as expected.. but that said, this is somewhat atypical usage, and some of it I feel may be interpretation/procedural wrt GUI usage itself. For example...

I don't know, I'm interpreting in correspondence to my 35+ years of GUI experience, whatever that's worth here! o)

When I Save that configuration, the name "config-03" appears in the list highlighted, and the Name: field is likewise populated with "config-03", however config-01.uae is still loaded in the emulator (because I haven't loaded any other config.uae file), and the list highlight & config Name: box jump back to "config-01", as that's the currently loaded config.uae file...

The question here is, what defines a loaded / saved configuration? As mentioned, I am thinking that whenever I toggled something around in the Amiberry prefs, I cannot really call a previous config "loaded" or "saved", since current settings could diverge heavily from what was set in the loaded or saved config file.

and in the GUI it jumped to the top of the list and the matching config.uae for that disk, because that's how the detection logic in amiberry works here =)

You are sure, you did not just load "the matching config.uae for that disk" before?

EDIT: I looked this up: https://github.com/BlitterStudio/amiberry/blob/13f4c1eb03e7cbd4ab133ba153798beeb073d1e6/src/osdep/gui/PanelConfig.cpp#L278

RefreshPanelConfig() and the selection only takes into account what was set as "last_active_config" it seems(?), it's a String. It does not take into account what disk image was set anywhere. I'm not familiar with the code, but since I could not reproduce what you described, it seems the highlight should not automatically switch to any config file, which also contains the currently configured disk image?!

Thinking some more about it and because the recent fix now also highlights the last configuration item saved, I think overloading the list view with "what was loaded or saved" recently, does not make any sense at all!? Now we have even more confusion? Always highlighting the last "loaded" config until we "saved" something, while there is still no dependency on a matching disk image (which might make some sense) or whether I completely changed all the Amiberry settings, highlighting any config has no real value.

The solution probably is to not overload the highlight, just let the list view behave as any other list view on the system and add some columns if there is the need to mark specific entries. The last saved config item could easily be determined by sorting "Modified" e.g., no need to highlight. The last loaded item could be displayed in bold and whether it's still unchanged could be shown in the Status column. If there actually is a feature, which scans existing configurations for the same disk, another column "Same disk" could visualize that, not sure though how many configuration files are there (scanning some thousend files is probably not a good idea).

Btw: I never realized that 1 configuration file per 1 program/game is the common use case, is it? I set up various systems in different configuration files so far (hardware settings and joystick maybe). I would think that one config for each game gives huge headaches if you want to change input/joystick for your setup, you'd need to edit hundreds(?) of config files to reflect your changed control settings, right? I would tackle that with a little program I guess If I had to, or building something that merges my current control settings into each game config, but that's not something the average emulation user will/could do? EDIT2: Using command line parameters to override control settings could work as well, but is a bit clunky to use I guess. Is there support for multiple config files already? Which get merged one by one upon launch? So I could "inject" different control settings, depending on where I come from? Standalone Amiberry launch or from RetroArch, GU start or not? I guess there is no such config file loading mechanic yet, sounds useful to me, unless you have another idea how to solve this?! o) Ok, way offtopic here, I will stop, sorry.

@tbone2k-git I'm quite happy to discuss/explain, but here in a closed ticket is not the place ;) If you want to move your reply here, over into the Discussions section, we can natter about such there.

@midwan ..unless there's something you can do to move the above reply?

BlitterStudio / amiberry

Configurations, last loaded Item is automatically selected for no reason on Save / Delete.. #1317