-
Notifications
You must be signed in to change notification settings - Fork 864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI: Station popup should hide when context deselection is requested #522
Comments
We know... I think we're only forcing this to enable drag and drop. On Windows, it is also default to hide the window/popup when you click outside of it. What do you think @diasdavid? |
@hacdias Here's another datapoint from the Pushbullet menu bar app: The "stickiness" is only exhibited here when drag-and-drop is expected, otherwise the popup behaves conventionally and disappears when the context is lost. |
@machawk1 yup, we could do that but since the left pane defaults to Files, it would always be expected to drag'n'drop unless we had some kind of button to enable drag'n'drop. |
@hacdias What if there were some toggle switch, disabled by default, that allowed a user to keep the Station UI visible? This would be useful in cases where they drag-and-drop files en-masse from a variety of locations but less so for one-offs, where they might use the "+" or folder buttons in the bottom right. Something akin to "pinning" (like a browser tab, though this is a bad term choice due to overloading the IPFS pin concept/cmd) could make such functionality clear and available for those that would use it. |
In macOS, a common UX pattern is to select (full mousedown-then-mouseup) a menu item, which shows the popup even when the mouse is no longer pressed. Clicking elsewhere when this popup is open closes the popup. For example:
Station does not allow this "deselection" though. When the Station popup is open and somewhere outside of the popup is clicked, the popup remains visible. Selecting the Station icon again closes the menu but with most programs with a menu item, clicking outside of the popup is usually sufficient. This also means that while Station is displaying its popup, other menu item (e.g., Sound control) can be selected and displayed on top of the Station UI.
...which gets awkward. It would be more natural as a native application if the selection scheme followed that of the system. It might be useful to look at the windowing/display model used by other Electron apps with a menu item to see how they handle this pattern.
The text was updated successfully, but these errors were encountered: