TEditor 50% complete
[nikiroo-utils.git] / docs / worklog.md
index a169b68cddb6d99c9386a40052d1694f33548df7..570404097cc2a5a1be28f3e90a24c07955945539 100644 (file)
@@ -1,6 +1,71 @@
 Jexer Work Log
 ==============
 
+August 12, 2017
+
+TEditor is stubbed in about 50% complete now.  I have a Highlighter
+class that provides different colors based on Word text values, but it
+is a lot too simple to do true syntax highlighting.  I am noodling on
+the right design that would let TEditor be both a programmer's editor
+(so Highlighter needs to have state and do a lexical scan) and a word
+processor (where Word needs to tokenize on whitespace).  I estimate
+probably a good 2-4 weeks left to get the editor behavior where I want
+it, and then after that will be the 0.0.5 release.
+
+Finding more minor paper cuts and fixing them: the mouse cursor being
+ahead of a window drag event, SwingTerminal resetting blink on new
+input, prevent TWindow from resizing down into the status bar.
+
+August 8, 2017
+
+Multiscreen is looking really cool!  Demo6 now brings up three
+screens, including one that is inside a TWindow of a different
+application.
+
+August 7, 2017
+
+Had trouble sleeping, what with a bunch of imaginative thoughts for
+this release.  jexer.backend will be the ultimate destination for
+jexer.session and most of jexer.io.  TerminalReader will be the
+interface for keyboard and mouse events.  cmScreenConnected and
+cmScreenDisconnected will be new events to represent a screen
+appearing/disappearing, and MultiBackend will be a new backend
+multiplexer that goes full XRandR.  Several new demos demonstrating
+multi-screen support will be coming along.
+
+August 6, 2017
+
+Time to clean up more API, particularly between Backend and Screen.
+Both of these will be interfaces soon, so that one could easily
+subclass JComponent and implement both Screen and Backend.  The
+original code evolved out of Qodem, where screen.c and input.c were
+two different things leading to ECMA48Screen and ECMA48Terminal, but
+now there is really no need to keep them separate.  It also
+complicates the constructors, as these are basically friend classes
+that have used package private access to get around their artificial
+separation.
+
+When I get this done it should be a lot easier to do any of:
+
+* Pass a JFrame or JComponent to SwingBackend and have it add itself,
+  like any other Swing widget.
+
+* Construct a SwingBackend and add it to any regular JComponent.
+
+* Have multiple TApplications running inside the same Swing
+  application, including having actions affect each other.  (Will also
+  need to ensure that TWidgets/TWindows are not in different
+  TApplication collections.)
+
+* Build a Backend/Screen multiplexer, so that one could have a ECMA48
+  TApplication listening on a port and a local Swing monitor for it.
+
+* Build a Backend/Screen manager, so that one could have multiple
+  ECMA48 screens acting as a single large screen (e.g. XRandR).
+
+Now I need to decide which package will collect Backend, SessionInfo,
+and Screen.  jexer.io has some java.io stuff, so it stays anyway.
+
 July 28, 2017
 
 Got very busy with my meatspace life, now getting a chance to come