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