Porting code from gui.cs Tracking Issue

[migueldeicaza]

This issue tracks my notes on the porting bits that I have done while moving code from gui.cs written in C# and TermKit written in Swift.

Generally, TermKit uses the same model of gui.cs, but has been adapted to the Swift language, and among other things, takes advantage of "Char" being a proper Unicode character.

While I have been porting most of the code from gui.cs to TermKit, in a few instances in the core, I have either not embraced a particular change, either because I do not like what is there on the C# code base, or because I am planning on using something different in TermKit. Some of those are documented here, and I will update as I audit or remember more things

Design Differences

While gui.cs embraced a more powerful View by default, one that contains text and rendering options, I chose to not put this into TermKit for now.

To deal with boundaries and the cursor location, in TermKit, I am using a drawing context that keeps track of this during the drawing stage, so it does not take space on the View itself to track.

Future Directions

Currently, TermKit is using ncurses for its Unix backend, but I am going to provide a direct version that speaks directly to the terminal, because (a) it is not that hard to write, (b) we would have a lot better control what what ncurses offer, but (c) would help me avoid dealing with the various versions and configurations of ncurses that ship in the wild that are nothing but a source of pain (specially dealing with colors, timeouts and unicode).

Audit Results

I have recently completed an Audit (as of Jan 2021) and the following pieces of code are either fully ported, or I consider them done for the purposes of the port. The checked options mean completed, others are open tasks:

• [x] Dim
• [x] Pos
• [ ] Core/Driver
  • [ ] Recently introduced capability to send KeyDown before ProcessKeyEvent, followed by KeyUp. This looks useful in Windows where we can tell the difference, and in particular is leveraged by MenuBar.OnKeyDown which checks for “Alt” key being set to close the menu
• [ ] Core/Application
  • [ ] Not convinced I need this:
    • [ ] HeightAsBuffer
    • [ ] AlwaysSetPosition
  • [ ] Application/postProcessEvent
    • [ ] This is where I do layout/redraw, and I think this could be different, rather than being done ad-hoc after processing one keystroke, we could do this after we process several. This is there because we do not really “own” the main loop, so we basically do the layout/paint here. What we should do instead is any layoutNeeded/setDisplayNeeded need to set a flag that triggers an execution before going back to reading more data from input, so that we process all of these at once.
  • [ ] ProcessKeyDownEvent/ProcessKeyUpEvent
    • [ ] Currently not implemented, used in Windows.
  • [x] RequestStop() is much simpler in C# that Swift - audit why
• [x] Core/TopLevel
  • [x] Whether we should have an ISupportInitialize support (DECIDED: no)
  • [x] Events: Loaded/Ready/Unloaded
  • [ ] StatusBar
  • [x] Needs support in Application for “requestStop”, which should trigger something in DispatchIO to trigger Swift code to terminate the current top-level
  • [ ] PostProcessEvent - needs shortcut lookup, FindAndOpenByShortcut
• [ ] Core/ConsoleDrier
• [x] Core/Event
• [x] Core/MainLoop
• [x] Core/Responder
• [ ] Core/ShortcutHelper
  • [ ] Not clear to me how this ShortcutHelper is used across the codebase
• [ ] Core/TextFormatter
• [ ] Core/View
  • [x] UPCOMING: layoutSubviews JUST ÇOMPLETED
  • [ ] Pending:
    • [x] PENDING: Move the various Draw methods out
    • [ ] PENDING: remove “MoveTo”
    • [ ] PENDING: Draw event
    • [ ] Pending: raise keyboard events using Combine
    • [ ] Pending: if we are raising events, we should have a way of stopping events, which for the mouse, I currently do not do/
    • [ ] Data on the fence about this payload
  • [ ] Debatable:
    • [ ] AutoSize relies on the Text being part of the View, which I didn't make it. I need to think whether AutoSize should be a property, or if it should be the default. I suspect that views that change internally need to have their layout recomputed, but need to think about this.
    • [ ] ShortcutHelper if I were to add this, I would probably introduce a protocol, and introduce a default implementation, rather than putting this on View.
    • [ ] HotKey, HotKeySpecified is not supported, because I do not think that the View should have this. This probably should be a protocol, or specific to a View.
    • [ ] Shortcut, ShortcutTag, ShortcutAction: same rationale as HotKey above.
    • [ ] Will ignore HotKeySpecifier
• [x] Core/Window

Views are now tracked as individual bugs

Clipping:

• [x] Currently the clipping when creating a painter will draw outside the screen if the terminal is bigger.

Rendering:

• [x] View.drawFrame should be rewritten with Painter
• [x] View.drawHotString should be rewritten with Painter

Some of these controls either exist, but have not been synced to the fixes and features of gui.cs, or I have not ported them yet:

Most of the Dialogs:

• [x] FileDialog
• [x] MessageBox
• [ ] Make driver.constants for characters part of the painter.