Remove confirmation step from overlay selection

[tapetis]

This PR changes the OverlaySelectionDialog to require one less tap to change overlays by replacing the "OK" button with a "cancel" button and directly switching the active overlay when a row is tapped. The updated dialog looks like this:

As a button on the main screen to change overlays is currently not planned (see #4686), I think this change is still a step in the right direction to allow faster switching between overlays.

[westnordost]

Hmm, this UI is inconsistent with expectation. You wouldn't expect a radio button select group to immediately return.

Better would be if it looked like a context menu / selection dialog. E.g. like a selection dialog as used for selecting the surface in the surface overlay: No OK or Cancel button, no radio button graphics and the whole cell has the ripple animation on press down.

I don't know how to make a custom context menu that is anchored at any view on screen, but at least having a selection dialog as described should be possible.

[tapetis]

The same UI pattern is used by the list preferences in the settings menu, as shown in the screenshot below. The only difference is that in the overlay dialog the ripple is only shown for the radio button vs. a ripple for the entire row in the settings menu. That is why I thought this UI is acceptable.

If you want, I can remove the cancel button, the radio buttons, and update the ripple. However, if implemented this way, the user would not be able to check which overlay is currently active.

[westnordost]

Hmm, you are right, on both points...

Well, then it's fine like this.

However, I think the whole row should then update the ripple, because the whole row acts as a button

[tapetis]

OK, then I will have to look into this a bit more. With a quick search, I was not able to find an easy way to have the ripple fill the entire row when using a RadioButton. It is also not easily possible to use a CheckedTextView, like the preference dialogs, as there can only one Drawable per direction and both the radio button and the overlay icon would have to be on the left side of the text.

[westnordost]

If the radio button in the checked text view is a state drawable, you could just use that drawable in a linear layout that shows all of the radio button, the text and the icon and make that layout clickable.

[tapetis]

The ripple now spans the entire width of the row and looks like this:

[westnordost]

Cool, so you found a way! One comment though:

[westnordost]

Thank you!

[westnordost]

By the way, do you happen to know how to make a dialog like this behave like a context menu?

[tapetis]

Can you explain a bit more what you mean by context menu? The regular Android menu that is usually displayed when selecting the three dots in a Toolbar or something entirely different?

[westnordost]

Yeah, that one. I.e. a dialog that is anchored in a certain view and is animated from that view

[tapetis]

The regular Android menu is a PopupMenu. It is anchored at the specified view and can be created either based on an XML resource or programmatically. If you want more customizability, you can use the underlying PopupWindow directly.

[westnordost]

Thanks!

I was asking because people keep requesting to have the overlay switcher as a button in the main view. Since also the overlays make up an ever-increasing part of StreetComplete and thus quite a lot of functionality is "hidden" in an entry in the menu, maybe such a button could be added after all, just to make the availability of this feature more prominent. But then, it would look more naturally if not a full-screen dialog would pop up to select the overlay but a view that is anchored in that button.

[Helium314]

I had played with such a switcher as part of SCEE quick settings, but encountered issues with icons taking large amount of horizontal space for whatever reason.
Though that was in a sub-menu of the popup menu, maybe that's a relevant difference.