X-Git-Url: https://git.nikiroo.be/?a=blobdiff_plain;f=docs%2Fworklog.md;h=24aa4e71528b4565baa61ce6255029fb02db5907;hb=051e29138b18fb4b731a72f8727475b10e4c74e4;hp=570404097cc2a5a1be28f3e90a24c07955945539;hpb=e8a11f986bfe2556e450d7b8ad6ef0059b369bbc;p=fanfix.git diff --git a/docs/worklog.md b/docs/worklog.md index 5704040..24aa4e7 100644 --- a/docs/worklog.md +++ b/docs/worklog.md @@ -1,6 +1,126 @@ 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 @@ -180,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. -