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