Many changes:
[fanfix.git] / docs / worklog.md
index 379d3fcfe8a04721b3b777a0a6566516386fa346..24aa4e71528b4565baa61ce6255029fb02db5907 100644 (file)
@@ -1,6 +1,247 @@
 Jexer Work Log
 ==============
 
+December 15, 2017
+
+We now have 24-bit RGB colors working with Swing backend.
+EMCA48Terminal isn't happy though, let's try to fix that...  still no
+dice.  So RGB is there for ECMA48 backend, but it sometimes flickers
+or disappears.  I'm not sure yet where the fault lies.  Ah, found it!
+Cell.isBlank() wasn't checking RGB.
+
+Well, I do say it is rather pretty now.  Let's get this committed and
+uploaded.
+
+December 14, 2017
+
+TComboBox is stubbed in, and it was quite simple: just a TField and
+TList, and a teeny bit of glue.  Along the way I renamed TCheckbox to
+TCheckBox, which was almost more work than TComboBox.  Heh.  Things
+are starting to come together indeed.
+
+TSpinner is in.  Now working on TCalendar...  ...and TCalendar is in!
+
+December 13, 2017
+
+A user noticed that the example code given in the README.md caused the
+main window to freeze when clicking close.  Turns out that was due to
+the addWindow(new TWindow(...)) line, which led to TWindow appearing
+in TApplication's window list twice.  Fixed the README, and then made
+TApplication.addWindow a package private function plus a check to
+ensure it isn't added twice.
+
+On the home front, my main box is now a Fedora 26 running Plasma
+desktop.  That ate a few weekends getting used to.  Current-era Linux
+is pretty nice, systemd so far (cross fingers) isn't creating any real
+problems, audio and wifi worked out of the box (thanks to Intel
+chipsets), and I can finally have all of my books and references on
+the same box as dev.  So woohoo!
+
+SwingTerminal is getting the insets wrong, which is a bit aggravating.
+So let's add adjustable insets in SwingComponent with a default
+2-pixel border around the whole thing, which I can tweak for my
+laptop.  Done!
+
+Alright, so where are we?  Well, I will have some time in the evenings
+over the next couple weeks to put into projects.  This one will get a
+little bit of love, probably a new widget or two; Qodem might get
+libssh2 + mdebtls support in Windows if those aren't too involved;
+Jermit will get a little more push towards a Kermit implementation.
+
+October 17, 2017
+
+I finally gave up the ghost on using gcj as the default compiler due
+to its awesome unused imports messages, and learned how to get PMD to
+do that job.  Which promptly created 1000+ warning messages related to
+class item order (variables, constructors, methods), nested ifs,
+useless checks, and so on.  So now we go on a code sweep to fix those,
+and along the way set a new class template.  Since this is so large
+and invasive, I will bite the bullet now and get it done before the
+next release which will get it out on Maven finally.
+
+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
+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
@@ -59,4 +300,3 @@ checklists.  I think I will see if jexer is available at SourceForge,
 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.
-