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.
git://git.nikiroo.be / nikiroo-utils.git / blobdiff