+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
+back around.
+
+I gave up on TEditor knowing about graphemes, instead pulling back to
+simple Cells. This will be better anyway in the long run, as getting
+grapheme support in Screen someday will also get it for me in TEditor
+for free. But it does mean that TEditor will chew through much more
+RAM than it needs to for a text file. Performance optimization will
+come someday. But this means I can also go back to gcj, because I
+really like its warnings about unused imports.
+
+I've got a POM stubbed in, and created an account over at sonatype.
+If it isn't too hard, I will try to get 0.0.5 released into the maven
+universe. But that is still a bit away, I need TEditor running with
+syntax highlighting first.
+
+July 17, 2017
+
+Focus-follows-mouse is in, as is NOCLOSEBOX.
+
+July 15, 2017
+
+I think I have cleaned up most of the window show/hide/activate mess
+in TApplication. Demo4 has some cool interactions between a
+background TDesktop and several foreground TWindows, which helped
+expose bugs.
+
+July 9, 2017
+
+While working on TWindow.hide/show I decided that I am sick of
+TApplication's active window handling. TApplication makes lots of
+assumptions, things are too fragile between modal and not, and one
+cannot easily say window.activate(). So I will also be changing that
+too. ... Code is still a bit of a mess, but hooks are in place at
+least for show/hide/activate.
+
+July 8, 2017
+
+Qodem 1.0.0 released last month, I had a vacation, and a Jexer user
+(nikiroo) started opening up pull requests. :-) So back unto the
+breach we go!
+
+TButton is now animated so that there is some feedback when selected
+via keyboard. StringJustifier was written which permits TText's to
+have left/centered/right and full justification. TDesktop is now in
+too which can act as a permanent max-sized window without borders.
+
+Next up is Viewport, an interface to collect scrollbar API, and then a
+cleaner API for scrollable widgets and windows. After that is more
+window API: hide/show/maximize/restore, and unclosable windows. I am
+cherry-picking bits from @nikiroo's PRs, which will likely break them
+before it fixes things, but I will find some way to get Niki credited
+with those pieces.
+
+March 21, 2017
+
+I am starting to gear up for making Jexer a serious project now. I've
+created its SourceForge project, linked it back to GitHub, have most
+of its web page set up (looks like Qodem's), and released 0.0.4. And
+then this morning saw an out-of-bounds exception if you kill the main
+demo window. Glad I marked it Alpha on SourceForge...
+
+Yesterday I was digging around the other Turbo Vision derived projects
+while populating the about page, and made a sad/happy-ish realization:
+Embarcadero could probably get all of them shut down if it really
+wanted to, including Free Vision. I uncovered some hidden history in
+Free Vision, such that it appears that Graphics Vision had some
+licensed Borland code in it, so there might be enough mud in the air
+that Free Vision could be shut down the same way RHTVision was. But
+even worse is the SCOTUS ruling on Oracle vs Google: if APIs are
+copyrighted (regardless of their thoughts on fair use), then any
+software that matches the API of a proprietary project might find
+itself subject to an infringement case. So that too could shut down
+the other API-compatible TV clones.
+
+Fortunately, Jexer (and D-TUI) is completely new, and has no API
+compatibility with Turbo Vision. Jexer could be a new root to a whole
+generation of TUI applications.
+