Replies: 4 comments 4 replies
-
This is an artefact of applying web UX to desktop apps. As mentioned in the last two sync calls, this behaviour needs to be investigated and properly defined. |
Beta Was this translation helpful? Give feedback.
-
Here is a simple mockup to using modals (based on the image list UI) |
Beta Was this translation helpful? Give feedback.
-
Using modals would require the modals to have a Save/Cancel action set(?) |
Beta Was this translation helpful? Give feedback.
-
I created issue #5284 for the "No Current Selection" highlighted in the image above. This is a bug that needs to be fixed regardless of the outcome of this discussion |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
On the Images tag, when we click "Add Images" we need to query the user for the image name.
Instead of displaying a dialog box, with a text entry field, and OK/Cancel1 buttons, we simulate a dialog in the window area:
It works like a non-modal dialog, but doesn't look like it at all. The Cancel button is in the top left corner (and labeled with a single
<
character), and the whole subwindow doesn't really look like a native dialog at all.It also works differently from other non-modal dialogs in that you cannot navigate back to it once you click somewhere else (you can click on "Add Images" again, and get a new empty dialog).
The same design is being proposed for taking snapshots.
I would like to understand why we shouldn't switch to using regular dialog boxes here; that's what they have been designed for: when an action triggered by a button requires additional input from the user before it can be performed.
Footnotes
I'm not arguing about the button text, labeling them Cancel/Pull or whatever is fine, but conceptually they are "Abort operation" / "Perform operation" buttons. ↩
Beta Was this translation helpful? Give feedback.
All reactions