-
-
Notifications
You must be signed in to change notification settings - Fork 122
Conversation
ui.go
Outdated
@@ -19,6 +19,9 @@ type UI interface { | |||
Update(fn func()) | |||
// Quit shuts down the UI goroutine. | |||
Quit() | |||
|
|||
ShowDialog(d *Dialog) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So: the only possible floating widget is a Dialog
?
I have a different case for modal windows - "edit properties" pane, e.g. activate the control for an IRC network to change its properties (address, name, etc.) The Dialog
widget still seems useful, as a common confirmation-dialog thing- it's just not generic enough to cover some of the other stuff I'm interested in re: modal widgets.
Is there an opportunity for a more generic "floating window" here?
e.g. have a ZBox (like HBox and VBox) which has the same X and Y dimensions, but for which higher indices are rendered later (on top).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This an area where I feel tui-go should be opinionated. I'm a bit hesitant to floating windows as I don't believe window management is within the scope of tui-go. I want tui-go to promote good terminal UX, and I still have yet to see an example where the use of multiple floating windows have been justified.
That being said, I do think there is a case for modal dialogs, that goes away when you're done with them. Same goes for dropdowns, hint boxes etc.
The Dialog widget currently embeds the Box layout so you can set any content you want, where the size of the Dialog is currently set to the size hint of the contents.
Could you shed some more light on the use case you mentioned, and specifically why the Dialog is lacking in this regard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, yes, the term "floating window" was poorly chosen; I agree that tui
shouldn't be doing window management. (I use i3
and have at most one floating window on my display. :-) )
The fact that There Can Only Be One is lacking for me. Example of multiple modal dialogs:
- I'm in
discoirc
's client status view, which shows all of the open connections / channels. - I perform the "edit connection" action.
- A modal
Box
shows up on top of the main display, listing the properties of the connection in editable form. - I edit the text in one of those, then hit "escape" to return to the main display.
- A dialog shows up on top of the edit view: "Would you like to save your changes? [Yes] [No]"
If there can only be one pop-up, the above design can't be implemented (with provided widgets); it becomes tui
's opinion that there should only be one pop-up at a time. (I'm trying to distinguish "floating windows" - a layout / moving-around / etc. problem - from "popups" / "modal widgets" here. Does that make sense?)
I suspect this case for multiple modal widgets may also come up with dropdowns (cascading dropdowns), but admittedly I haven't thought in a lot of detail how to make those.
I'll try to prototype what I'm thinking of here in the next couple days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean. It's really stacked modal dialogs more than "windows" then. Hm, I can see the use case. The way I've imagined the engine would certainly make this possible - painting onto arbitrary number of layers and then compositing them back-to-front. The question is how to expose it in the API without making it to easy too shoot yourself in the foot. I'm leaning towards a initial PR with a minimal API change and then look at dropdowns in the next one to what comes out.
I'm closing this WIP for now as it, as it's not fit to be merged in the current design. |
This adds a new Dialog widget that overlays a floating VBox on top of the UI, typically used for asking for confirmation or other user input.
Fixes #46