Skip to content
This repository has been archived by the owner on Oct 13, 2021. It is now read-only.

WIP: Add Dialog widget #103

Closed
wants to merge 4 commits into from
Closed

WIP: Add Dialog widget #103

wants to merge 4 commits into from

Conversation

marcusolsson
Copy link
Owner

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

ui.go Outdated
@@ -19,6 +19,9 @@ type UI interface {
Update(fn func())
// Quit shuts down the UI goroutine.
Quit()

ShowDialog(d *Dialog)
Copy link
Contributor

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).

Copy link
Owner Author

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?

Copy link
Contributor

@cceckman cceckman Jan 9, 2018

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.

Copy link
Owner Author

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.

@marcusolsson marcusolsson changed the title WIP: Add Dialog widget Paint to intermediate buffer Feb 24, 2018
@marcusolsson marcusolsson changed the title Paint to intermediate buffer WIP: Add Dialog widget Feb 24, 2018
@marcusolsson
Copy link
Owner Author

I'm closing this WIP for now as it, as it's not fit to be merged in the current design.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants