Opened 4 years ago

Closed 2 years ago

#285 closed enhancement (fixed)

Proper multiselect support for Listview.mui

Reported by: Andreas Falkenhahn Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2017R4
Component: List.mui Version: 4.0-2015R3
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:


Multiselect has always kind of sucked in MUI. The fact that MUI allows an active listview entry next to other selected entries is outright confusing and totally non-standard.

Now, after more than 20 years, there should be a new flag for MUIA_Listview_MultiSelect which implements proper, standard multi-selection, e.g. range select with SHIFT, individual entry select AND deselect with CTRL.

To see what a mess MUI's multi selection really is, just do the following:

1) Open MUI prefs
2) Goto to the "Lists" page
3) Select all entries in the listview on the left
4) Now hold down SHIFT and click on "with some"
5) Nothing happens (but keep holding down SHIFT)
6) Now click on "selected" (SHIFT must still be down)
7) Now "with some" is suddenly deselected! WTF!

You can repeat this procedure as you like. The previous entry is always deselected when clicking on a new entry with SHIFT down. It's completely confusing, unintuitive and weird.

It's ok to keep this behaviour for compatibility but there really should be a new mode which makes MUI's listview behave like listviews on other platforms do and which also removes this weird mode where there can be an active entry alongside multiselected entries. This is really utterly confusing for the end-user.

Change History (8)

comment:1 Changed 4 years ago by Andreas Falkenhahn

By the way, the behaviour you see in the MUI prefs (as described above) might even be a bug in the OS3 build. In the OS4 build of MUI the active entry can clearly be distinguished from the other selected entries because the other selected entries are drawn with a bitpattern fill on OS4 whereas the active entry on OS4 is drawn with a static fill. On OS3, however, all entries, no matter if active or just selected, are drawn with a static fill. The bitpattern fill doesn't seem to work on OS3.

Nevertheless, I still think we need a proper multi-select mode without this active entry vs. selected entries nuisance.

comment:2 Changed 4 years ago by Thore Böckelmann

I think you are a bit mislead here. Just clicking an entry sets the active entry only. If you want to select multiple entries you must click the same entry again with the SHIFT qualifier pressed. This is different to how Windows handles multiselection. In Windows clicking an entry makes it active and selected and further clicks with SHIFT/CTRL extend this initial selection.

Perhaps MUI should mimic the Windows approach and mark the active entry by a frame only instead of different colors. Doing multiselection by keyboard should also be possible, like it is done on Windows (keeping SHIFT/CTRL pressed while moving the cursor by the arrow keys).

Regarding the highlighting of AmigaOS3, there is absolutely NO difference to AmigaOS4. However, the default AmigaOS3 settings use the same color for all three states (active, selected, active+selected). I admid this is an unlucky situation, especially because changing this requires a key file. The AmigaOS4 build uses different colors/patterns. This definitely needs to be changed.

comment:3 Changed 4 years ago by Andreas Falkenhahn

Yes, I'd recommend such a change. I have never seen this kind of multiselection anywhere. I think it's confusing that in a multiselection listview you have to click twice to actually select an entry. It's really confusing.

BTW, R4 on OS3 still has the old coloring scheme with the same colors for all three states. Please change this as it certainly makes the confusion complete :)

comment:4 Changed 4 years ago by Thore Böckelmann

In 5094:

  • tools/makeconfig.c: changed the default list cursor colors for the AmigaOS3 build back to 3 different colors to let people distinguish between the 3 modes. This refs #285.

comment:5 Changed 2 years ago by Thore Böckelmann

Component: Listview.muiList.mui
Milestone: future release5.0-2017R4
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

Recent changes (i.e. r6103) address this issue. Please check whether the current nightly builds already fulfil your expectations regarding the initial multiselection issue. Please also note that something like a Windows-like multiselection has NOT been implemented. Only the handling of the SHIFT key when extending the selection after the first element has been selected has been enhanced.

comment:6 Changed 2 years ago by Thore Böckelmann

Any comments from your side?

comment:7 Changed 2 years ago by Andreas Falkenhahn

Yes, feels much better now. Thanks for changing the behaviour her. The old one was really confusing..

comment:8 Changed 2 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.