| 1 | Jexer Work Log |
| 2 | ============== |
| 3 | |
| 4 | December 15, 2017 |
| 5 | |
| 6 | We now have 24-bit RGB colors working with Swing backend. |
| 7 | EMCA48Terminal isn't happy though, let's try to fix that... still no |
| 8 | dice. So RGB is there for ECMA48 backend, but it sometimes flickers |
| 9 | or disappears. I'm not sure yet where the fault lies. Ah, found it! |
| 10 | Cell.isBlank() wasn't checking RGB. |
| 11 | |
| 12 | Well, I do say it is rather pretty now. Let's get this committed and |
| 13 | uploaded. |
| 14 | |
| 15 | December 14, 2017 |
| 16 | |
| 17 | TComboBox is stubbed in, and it was quite simple: just a TField and |
| 18 | TList, and a teeny bit of glue. Along the way I renamed TCheckbox to |
| 19 | TCheckBox, which was almost more work than TComboBox. Heh. Things |
| 20 | are starting to come together indeed. |
| 21 | |
| 22 | TSpinner is in. Now working on TCalendar... ...and TCalendar is in! |
| 23 | |
| 24 | December 13, 2017 |
| 25 | |
| 26 | A user noticed that the example code given in the README.md caused the |
| 27 | main window to freeze when clicking close. Turns out that was due to |
| 28 | the addWindow(new TWindow(...)) line, which led to TWindow appearing |
| 29 | in TApplication's window list twice. Fixed the README, and then made |
| 30 | TApplication.addWindow a package private function plus a check to |
| 31 | ensure it isn't added twice. |
| 32 | |
| 33 | On the home front, my main box is now a Fedora 26 running Plasma |
| 34 | desktop. That ate a few weekends getting used to. Current-era Linux |
| 35 | is pretty nice, systemd so far (cross fingers) isn't creating any real |
| 36 | problems, audio and wifi worked out of the box (thanks to Intel |
| 37 | chipsets), and I can finally have all of my books and references on |
| 38 | the same box as dev. So woohoo! |
| 39 | |
| 40 | SwingTerminal is getting the insets wrong, which is a bit aggravating. |
| 41 | So let's add adjustable insets in SwingComponent with a default |
| 42 | 2-pixel border around the whole thing, which I can tweak for my |
| 43 | laptop. Done! |
| 44 | |
| 45 | Alright, so where are we? Well, I will have some time in the evenings |
| 46 | over the next couple weeks to put into projects. This one will get a |
| 47 | little bit of love, probably a new widget or two; Qodem might get |
| 48 | libssh2 + mdebtls support in Windows if those aren't too involved; |
| 49 | Jermit will get a little more push towards a Kermit implementation. |
| 50 | |
| 51 | October 17, 2017 |
| 52 | |
| 53 | I finally gave up the ghost on using gcj as the default compiler due |
| 54 | to its awesome unused imports messages, and learned how to get PMD to |
| 55 | do that job. Which promptly created 1000+ warning messages related to |
| 56 | class item order (variables, constructors, methods), nested ifs, |
| 57 | useless checks, and so on. So now we go on a code sweep to fix those, |
| 58 | and along the way set a new class template. Since this is so large |
| 59 | and invasive, I will bite the bullet now and get it done before the |
| 60 | next release which will get it out on Maven finally. |
| 61 | |
| 62 | August 16, 2017 |
| 63 | |
| 64 | Holy balls this has gotten so much faster! It is FINALLY visibly |
| 65 | identical in speed to the original d-tui: on xterm it is glass |
| 66 | smooth. CPU load is about +/- 10%, idling around 5%. |
| 67 | |
| 68 | I had to dramatically rework the event processing order, but now it |
| 69 | makes much more sense. TApplication.run()'s sole job is to listen for |
| 70 | backend I/O, push it into drainEventQueue, and wake up the consumer |
| 71 | thread. The consumer thread's run() has the job of dealing with the |
| 72 | event, AND THEN calling doIdles and updating the screen. That was the |
| 73 | big breakthrough: why bother having main thread do screen updates? It |
| 74 | just leads to contention everywhere as it tries to tell the consumer |
| 75 | thread to lay off its data structures, when in reality the consumer |
| 76 | thread should have been the real owner of those structures in the |
| 77 | first place! This was mainly an artifact of the d-tui fiber threading |
| 78 | design. |
| 79 | |
| 80 | So now we have nice flow of events: |
| 81 | |
| 82 | * I/O enters the backend, backend wakes up main thread. |
| 83 | |
| 84 | * Main thread grabs events, wakes up consumer thread. |
| 85 | |
| 86 | * Consumer thread does work, updates screen. |
| 87 | |
| 88 | * Anyone can call doRepaint() to get a screen update shortly |
| 89 | thereafter. |
| 90 | |
| 91 | * Same flow for TTerminalWindow: ECMA48 gets remote I/O, calls back |
| 92 | into TTerminalWindow, which then calls doRepaint(). So in this case |
| 93 | we have a completely external thread asking for a screen update, and |
| 94 | it is working. |
| 95 | |
| 96 | Along the way I also eliminated the Screen.dirty flag and cut out |
| 97 | calls to CellAttribute checks. Overall we now have about 80% less CPU |
| 98 | being burned and way less latency. Both HPROF samples and times puts |
| 99 | my code at roughly 5% of the total, all the rest is the |
| 100 | sleeping/locking infrastructure. |
| 101 | |
| 102 | August 15, 2017 |
| 103 | |
| 104 | I cut 0.0.5 just now, and also applied for a Sonatype repository. |
| 105 | It was a reasonable spot: TEditor was working albeit buggy, and a bug |
| 106 | had just come in on the main TApplication run loop. So we are about |
| 107 | to embark upon some performance work again, it's been probably version |
| 108 | 0.0.2 or so since the last cycle. |
| 109 | |
| 110 | Code size: 40446 lines. |
| 111 | |
| 112 | Now switching head to 0.0.6 and taking a small break. |
| 113 | |
| 114 | August 14, 2017 |
| 115 | |
| 116 | TEditor is basically done. Mouse movement, keyboard movement, |
| 117 | backspace / delete / enter / etc. are all in. Things are starting to |
| 118 | look pretty good. |
| 119 | |
| 120 | I'm going to prep for a final cut and release tag tomorrow or the next |
| 121 | evening. I need to take a break and get some meatspace life dealt |
| 122 | with. |
| 123 | |
| 124 | August 12, 2017 |
| 125 | |
| 126 | TEditor is stubbed in about 50% complete now. I have a Highlighter |
| 127 | class that provides different colors based on Word text values, but it |
| 128 | is a lot too simple to do true syntax highlighting. I am noodling on |
| 129 | the right design that would let TEditor be both a programmer's editor |
| 130 | (so Highlighter needs to have state and do a lexical scan) and a word |
| 131 | processor (where Word needs to tokenize on whitespace). I estimate |
| 132 | probably a good 2-4 weeks left to get the editor behavior where I want |
| 133 | it, and then after that will be the 0.0.5 release. |
| 134 | |
| 135 | Finding more minor paper cuts and fixing them: the mouse cursor being |
| 136 | ahead of a window drag event, SwingTerminal resetting blink on new |
| 137 | input, prevent TWindow from resizing down into the status bar. |
| 138 | |
| 139 | August 8, 2017 |
| 140 | |
| 141 | Multiscreen is looking really cool! Demo6 now brings up three |
| 142 | screens, including one that is inside a TWindow of a different |
| 143 | application. |
| 144 | |
| 145 | August 7, 2017 |
| 146 | |
| 147 | Had trouble sleeping, what with a bunch of imaginative thoughts for |
| 148 | this release. jexer.backend will be the ultimate destination for |
| 149 | jexer.session and most of jexer.io. TerminalReader will be the |
| 150 | interface for keyboard and mouse events. cmScreenConnected and |
| 151 | cmScreenDisconnected will be new events to represent a screen |
| 152 | appearing/disappearing, and MultiBackend will be a new backend |
| 153 | multiplexer that goes full XRandR. Several new demos demonstrating |
| 154 | multi-screen support will be coming along. |
| 155 | |
| 156 | August 6, 2017 |
| 157 | |
| 158 | Time to clean up more API, particularly between Backend and Screen. |
| 159 | Both of these will be interfaces soon, so that one could easily |
| 160 | subclass JComponent and implement both Screen and Backend. The |
| 161 | original code evolved out of Qodem, where screen.c and input.c were |
| 162 | two different things leading to ECMA48Screen and ECMA48Terminal, but |
| 163 | now there is really no need to keep them separate. It also |
| 164 | complicates the constructors, as these are basically friend classes |
| 165 | that have used package private access to get around their artificial |
| 166 | separation. |
| 167 | |
| 168 | When I get this done it should be a lot easier to do any of: |
| 169 | |
| 170 | * Pass a JFrame or JComponent to SwingBackend and have it add itself, |
| 171 | like any other Swing widget. |
| 172 | |
| 173 | * Construct a SwingBackend and add it to any regular JComponent. |
| 174 | |
| 175 | * Have multiple TApplications running inside the same Swing |
| 176 | application, including having actions affect each other. (Will also |
| 177 | need to ensure that TWidgets/TWindows are not in different |
| 178 | TApplication collections.) |
| 179 | |
| 180 | * Build a Backend/Screen multiplexer, so that one could have a ECMA48 |
| 181 | TApplication listening on a port and a local Swing monitor for it. |
| 182 | |
| 183 | * Build a Backend/Screen manager, so that one could have multiple |
| 184 | ECMA48 screens acting as a single large screen (e.g. XRandR). |
| 185 | |
| 186 | Now I need to decide which package will collect Backend, SessionInfo, |
| 187 | and Screen. jexer.io has some java.io stuff, so it stays anyway. |
| 188 | |
| 189 | July 28, 2017 |
| 190 | |
| 191 | Got very busy with my meatspace life, now getting a chance to come |
| 192 | back around. |
| 193 | |
| 194 | I gave up on TEditor knowing about graphemes, instead pulling back to |
| 195 | simple Cells. This will be better anyway in the long run, as getting |
| 196 | grapheme support in Screen someday will also get it for me in TEditor |
| 197 | for free. But it does mean that TEditor will chew through much more |
| 198 | RAM than it needs to for a text file. Performance optimization will |
| 199 | come someday. But this means I can also go back to gcj, because I |
| 200 | really like its warnings about unused imports. |
| 201 | |
| 202 | I've got a POM stubbed in, and created an account over at sonatype. |
| 203 | If it isn't too hard, I will try to get 0.0.5 released into the maven |
| 204 | universe. But that is still a bit away, I need TEditor running with |
| 205 | syntax highlighting first. |
| 206 | |
| 207 | July 17, 2017 |
| 208 | |
| 209 | Focus-follows-mouse is in, as is NOCLOSEBOX. |
| 210 | |
| 211 | July 15, 2017 |
| 212 | |
| 213 | I think I have cleaned up most of the window show/hide/activate mess |
| 214 | in TApplication. Demo4 has some cool interactions between a |
| 215 | background TDesktop and several foreground TWindows, which helped |
| 216 | expose bugs. |
| 217 | |
| 218 | July 9, 2017 |
| 219 | |
| 220 | While working on TWindow.hide/show I decided that I am sick of |
| 221 | TApplication's active window handling. TApplication makes lots of |
| 222 | assumptions, things are too fragile between modal and not, and one |
| 223 | cannot easily say window.activate(). So I will also be changing that |
| 224 | too. ... Code is still a bit of a mess, but hooks are in place at |
| 225 | least for show/hide/activate. |
| 226 | |
| 227 | July 8, 2017 |
| 228 | |
| 229 | Qodem 1.0.0 released last month, I had a vacation, and a Jexer user |
| 230 | (nikiroo) started opening up pull requests. :-) So back unto the |
| 231 | breach we go! |
| 232 | |
| 233 | TButton is now animated so that there is some feedback when selected |
| 234 | via keyboard. StringJustifier was written which permits TText's to |
| 235 | have left/centered/right and full justification. TDesktop is now in |
| 236 | too which can act as a permanent max-sized window without borders. |
| 237 | |
| 238 | Next up is Viewport, an interface to collect scrollbar API, and then a |
| 239 | cleaner API for scrollable widgets and windows. After that is more |
| 240 | window API: hide/show/maximize/restore, and unclosable windows. I am |
| 241 | cherry-picking bits from @nikiroo's PRs, which will likely break them |
| 242 | before it fixes things, but I will find some way to get Niki credited |
| 243 | with those pieces. |
| 244 | |
| 245 | March 21, 2017 |
| 246 | |
| 247 | I am starting to gear up for making Jexer a serious project now. I've |
| 248 | created its SourceForge project, linked it back to GitHub, have most |
| 249 | of its web page set up (looks like Qodem's), and released 0.0.4. And |
| 250 | then this morning saw an out-of-bounds exception if you kill the main |
| 251 | demo window. Glad I marked it Alpha on SourceForge... |
| 252 | |
| 253 | Yesterday I was digging around the other Turbo Vision derived projects |
| 254 | while populating the about page, and made a sad/happy-ish realization: |
| 255 | Embarcadero could probably get all of them shut down if it really |
| 256 | wanted to, including Free Vision. I uncovered some hidden history in |
| 257 | Free Vision, such that it appears that Graphics Vision had some |
| 258 | licensed Borland code in it, so there might be enough mud in the air |
| 259 | that Free Vision could be shut down the same way RHTVision was. But |
| 260 | even worse is the SCOTUS ruling on Oracle vs Google: if APIs are |
| 261 | copyrighted (regardless of their thoughts on fair use), then any |
| 262 | software that matches the API of a proprietary project might find |
| 263 | itself subject to an infringement case. So that too could shut down |
| 264 | the other API-compatible TV clones. |
| 265 | |
| 266 | Fortunately, Jexer (and D-TUI) is completely new, and has no API |
| 267 | compatibility with Turbo Vision. Jexer could be a new root to a whole |
| 268 | generation of TUI applications. |
| 269 | |
| 270 | March 18, 2017 |
| 271 | |
| 272 | TStatusBar is working, as is "smart" window placement. Overall this |
| 273 | is looking quite nice. Found a lot of other small paper cut items and |
| 274 | fixed them. It looks absolutely gorgeous on Mac now. |
| 275 | |
| 276 | Tomorrow I will get to the public wifi and get this uploaded. |
| 277 | |
| 278 | Time to call this 0.0.4 now though. We are up to 32,123 lines of |
| 279 | code. |
| 280 | |
| 281 | March 17, 2017 |
| 282 | |
| 283 | Jexer is coming back to active development status. I had a lot of |
| 284 | other projects ahead of it in the queue, mostly Qodem but also Jermit |
| 285 | and of course lots of actual day job work keeping me too tired for |
| 286 | afterhours stuff. But here we are now, and I want to get Jexer to its |
| 287 | 1.0.0 release before the end of 2018. After that it will be a |
| 288 | critical bit of function for IWP and NIB, if I ever get those going. |
| 289 | I need to re-organize the demo app a bit so that it fits within 80x25, |
| 290 | and then get to TStatusBar. |
| 291 | |
| 292 | A status bar will be an optional part of TWindow. If it exists, then |
| 293 | it will be drawn last by TApplication and get events routed to it from |
| 294 | TWindow's event handlers. This will have the nice effect that the |
| 295 | status bar can change depending on which window is active, without any |
| 296 | real extra work on TApplication's part. |
| 297 | |
| 298 | Putting together a proper TODO now, with release and regression |
| 299 | checklists. I think I will see if jexer is available at SourceForge, |
| 300 | and if so grab it. Perhaps I can put together some good Turbo Vision |
| 301 | resources too. At the very least direct people to the Borland-derived |
| 302 | C++ releases and Free Vision. |