Replace UI confirmations and alerts from native_dialog with own iced based implementation

[sluedecke]

What's your idea?

To warm up with iced [no pun intended], I am exploring how one can implement simple alert and confirmation dialogs with iced. In the long run this would give ludusavi more control over the UI (I hope to be able to confirm dialogs using gamepad controls on the Steam Deck).

So far I manage to open a window and get the state of a cancel or ok button pressed here: https://github.com/sluedecke/iced-dialog/tree/master

Mind having a look at it and provide some feedback regarding these items?

• do you think this is worth the effort?
• Do you prefer A: static variable with unsafe access or B: using a mutex?
• Do you know a better way to get a result from an iced::Application?

TIA

[mtkennerly]

I hope to be able to confirm dialogs using gamepad controls on the Steam Deck

Hmm, I'm surprised it doesn't have a way to do that normally.

• Could you map a button to toggle mouse behavior for the trackpad? I found this, but not sure if it helps: https://www.reddit.com/r/SteamDeck/comments/13n63hm/how_can_i_set_trackpad_click_as_mouse_click/
• Does the touchscreen work for dialogs?
• If you have bindings for left/right arrow and enter, do those work for selecting an option? That works for Windows dialogs via
  keyboard, but not sure about Linux and the Steam Deck controls.

do you think this is worth the effort?

For Ludusavi, my gut feeling is that I'd rather keep it simple and stick to native-dialog for the wrap dialogs, at least for now. Subjectively, I don't mind custom widgets in the context of a full app, but for an isolated dialog, I'd usually expect it to match the OS style.

That said, I think it's definitely something that people using Iced could be interested in, so an iced-dialog would still be a nice project :)

Do you prefer A: static variable with unsafe access or B: using a mutex?

I'd vote for the mutex. I think unsafe is a last resort.

Do you know a better way to get a result from an iced::Application?

Not offhand. Since run is a static method and returns Result<(), ...>, I think you found a good alternative.

[sluedecke]

I hope to be able to confirm dialogs using gamepad controls on the Steam Deck

Hmm, I'm surprised it doesn't have a way to do that normally.

• Could you map a button to toggle mouse behavior for the trackpad? I found this, but not sure if it helps: https://www.reddit.com/r/SteamDeck/comments/13n63hm/how_can_i_set_trackpad_click_as_mouse_click/

Indeed I could, but it would require other users to do the same. I assume most will just want it to work with the existing controls. I don't see zenity support gamepads at the moment.

• Does the touchscreen work for dialogs?

It does, but it is kind of a media break. Having to touch the screen which is a bit of an inconvenience when playing with the device in my hands. Some games - e.g. Horizon Zero Dawn - work very well on the Steam Deck and I played it with the deck connected to my living room TV. Everything works using the gamepad controls, but for confirming the backup, I would have to go to the TV where the device is, push the button and then return to my comfy sofa. Very inconvenient :)

Even on my PC where I use Heroic, it is a media break for games played with controller only (put the controller away, reach for the mouse, target the button, ...).

• If you have bindings for left/right arrow and enter, do those work for selecting an option? That works for Windows dialogs via
  keyboard, but not sure about Linux and the Steam Deck controls.

I think it would work with such bindings, but I don't know ATM where to configure it in Linux...

do you think this is worth the effort?

For Ludusavi, my gut feeling is that I'd rather keep it simple and stick to native-dialog for the wrap dialogs, at least for now. Subjectively, I don't mind custom widgets in the context of a full app, but for an isolated dialog, I'd usually expect it to match the OS style.

When selecting files and folders one interacts with the system. I personally very much disliked the file selection dialogs which came with the first versions of Java. Then we hat Qt based file dialogs. Gnome has one, too. For this use case I also expect the dialog to match my system.

But the confirmations are interactions with the application and I would be fine for them to match the style of the application.

That said, I think it's definitely something that people using Iced could be interested in, so an iced-dialog would still be a nice project :)

Do you prefer A: static variable with unsafe access or B: using a mutex?

I'd vote for the mutex. I think unsafe is a last resort.

Thanks for the feedback!

I will continue to explore the idea a bit further - maybe I can get it to work with a gamepad. It would really make things feel a bit more integrated.

[sluedecke]

And then I accidentially closed this issue ...

[sluedecke]

Actually this is a fun excercise. And it is doable.

Dialog without gamepad:

Connecting the gamepad changes it into:

And I can both cancel and ok the dialog using my gamepad.

[sluedecke]

And blocked due to: rust-windowing/winit#2431 which is fixed in winit 0.29.0 which in turn has yet to be picked up by iced and then by ludusavi.

Closing this for now to keep list of open issues low. Will revisit at a later time.

PS: also somewhat related: iced-rs/iced#27