Toplevel/Application redesign ideas

[migueldeicaza]

I think it would be useful to redesign Toplevel, because:

• It currently handles view-navigation, defaults like Control-L, control-Z, Control-C (not really)
• Handles navigation in/out
• Introduces "modal" flag, tracked by Application to determine whether to bubble up an event
• Tracks menubar/statusbar if present, without being a full desktop.

Application:

• Feels like the name is intended for things that this is not
• Tracks the current toplevel
• Is the place where events are dispatched from (via static method to the top-level list)
• Tracks mouse grabbing
• Display refresh is handled here
• Application suspend/Resize

Currently, Window subclasses Toplevel.

So we could have something like this:

Toplevel:

• Backing store for rendering
• Default handlers for control-l, control-z, control-c
• StandardToplevel, a Toplevel subclass with standard elements
  • Provide a standard dialect for menubar, statusbar, desktop
  • tiled windows
  • But not be the only way to run, I could for example want to run the toolkit, without hijacking the full screen

Question: what is the shared base class for Window and Application? Maybe TopLevel become just the host for the backing store and the modal attribute?

Application (not sure if this is the best name)

• Refresh, resize, suspend logic gets moves here
• Modality of the current

• In addition, I want to introduce a "layer" backing store where views draw at some level, and that one feels like it should be "Window", or maybe a base class for Window. This is discussed here #30

TBD:

• What is the "toplevel" equivalent in TermProgram? Because currently we use the toplevel.modal flag to determine whether to propagate the event.

Modality alternative: maybe making something modal creates a full-screen view that captures all mouse and keyboard events, but does not draw everything (or is transparent).

[migueldeicaza]

Pending tasks:

• We need a way of notifying a Toplevel that the frame has changed, currently View set _frame behind its back, so there is no way to trigger a buffer reallocation

The redraw method on the Toplevel probably needs to check if the backingStore is still correct? But that might get a clipped region, so it wont be able to paint the real region.

So what is needed is when the size of the Toplevel changes, it needs to have its backing store invalidated, and the view redrawn. And currently this is not the case.

• Probably should not use an [Cell] as the backing store, but instead a proper Layer that wraps the cell, and tracks columsn/rows, just to track the information and enforce the data.
• Optimize: no need to reallocate the buffer if it moves, only if the size changes.

Other things:

• Drivers probably should not expose add (rune) as an API, and instead use add (character) only, as the column tracking is now done in various places, and I do not think it is necessary
• ConsoleDriver should expose a "size" property, rather than cols/rows