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