Jexer Work Log
==============
+August 16, 2017
+
+Holy balls this has gotten so much faster! It is FINALLY visibly
+identical in speed to the original d-tui: on xterm it is glass
+smooth. CPU load is about +/- 10%, idling around 5%.
+
+I had to dramatically rework the event processing order, but now it
+makes much more sense. TApplication.run()'s sole job is to listen for
+backend I/O, push it into drainEventQueue, and wake up the consumer
+thread. The consumer thread's run() has the job of dealing with the
+event, AND THEN calling doIdles and updating the screen. That was the
+big breakthrough: why bother having main thread do screen updates? It
+just leads to contention everywhere as it tries to tell the consumer
+thread to lay off its data structures, when in reality the consumer
+thread should have been the real owner of those structures in the
+first place! This was mainly an artifact of the d-tui fiber threading
+design.
+
+So now we have nice flow of events:
+
+* I/O enters the backend, backend wakes up main thread.
+
+* Main thread grabs events, wakes up consumer thread.
+
+* Consumer thread does work, updates screen.
+
+* Anyone can call doRepaint() to get a screen update shortly
+ thereafter.
+
+* Same flow for TTerminalWindow: ECMA48 gets remote I/O, calls back
+ into TTerminalWindow, which then calls doRepaint(). So in this case
+ we have a completely external thread asking for a screen update, and
+ it is working.
+
+Along the way I also eliminated the Screen.dirty flag and cut out
+calls to CellAttribute checks. Overall we now have about 80% less CPU
+being burned and way less latency. Both HPROF samples and times puts
+my code at roughly 5% of the total, all the rest is the
+sleeping/locking infrastructure.
+
+August 15, 2017
+
+I cut 0.0.5 just now, and also applied for a Sonatype repository.
+It was a reasonable spot: TEditor was working albeit buggy, and a bug
+had just come in on the main TApplication run loop. So we are about
+to embark upon some performance work again, it's been probably version
+0.0.2 or so since the last cycle.
+
+Code size: 40446 lines.
+
+Now switching head to 0.0.6 and taking a small break.
+
+August 14, 2017
+
+TEditor is basically done. Mouse movement, keyboard movement,
+backspace / delete / enter / etc. are all in. Things are starting to
+look pretty good.
+
+I'm going to prep for a final cut and release tag tomorrow or the next
+evening. I need to take a break and get some meatspace life dealt
+with.
+
+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
and if so grab it. Perhaps I can put together some good Turbo Vision
resources too. At the very least direct people to the Borland-derived
C++ releases and Free Vision.
-