On the 2018-07-30, I continued to work on the Change Tracking Text Editor. My approach was to port the C++/Qt4 code to JavaFX, but it turned out that the events differ from each other and do not follow the same paradigm. Herbert Schildt’s book indicated already that there’s a difference between the onKeyPressed and the onKeyTyped event, namely that the latter only triggers for key presses that actually change the text. Now, it turned out that Backspace and Delete key will also trigger the onKeyTyped event, and then is unable to obtain the pressed character via KeyEvent.getCharacter(). Note that onKeyReleased is usually not very useful for text editor programming because the user can hold a key pressed and release it after many minutes, and as one doesn’t want to calculate the time interrupt for the individual character additions, it’s usually not of interest.

On the 2018-08-11, I first found a way to handle Backspace and the Delete key press events apart from ordinary key press events. After that it became apparent that the output is incorrectly generated, and the reason for that was that both the onKeyPressed and onKeyTyped events are fired before the actual event is enacted, therefore the caret position and text in the input field are still the old ones despite the events are named “pressed” and “typed” in past tense. JavaFX is a little bit strange in some ways. This lead to off-by-one errors in the output and even to crashes when attempting to extract text beyond the actual text string limits. Because of this, I removed the handling of the “last position” entirely and now the JavaFX editor is entirely autosaving what happened until the current position, with the new keys as a different operation not being on the record yet, which is quite fine, while I wanted to avoid to calculate the possible future myself, adding and subtracting typed character lengths and constructing possible future text lengths, etc.

On the 2018-08-12, I added the handling of other caret position handling because of mouse clicking, arrow key navigation etc. The change event for the caretPosition property is also triggered for each ordinary character key press, so those are already handled and needed to be filtered, which hopefully doesn’t lead to timing issues and therefore incorrectness in the output as I assume to be or contribute to the reason why the Java and C++/Qt4 implementations don’t work properly. It’s always better to avoid such manual tricks in event handling as much as possible, because this might get into the way of processing interrupts/events. A very quick test looked promising enough for me to type this entire personal FTI report in the editor, hoping that my writing in the actual example won’t get corrupted because of mouse and navigation key movements. During the writing, it looked like the TextArea was inserting spaces at the right corner at the end of the text input field without me typing it. The analysis of the result will happen some time later.

Quite some time of the weeks is invested into observing the Global Challenges Collaboration Community hosted by Sam Hahn because there’s the vague possibility that they might decide to need some kind of Journal as their materials are unbelievably scattered, almost impossible to curate, and being inspired by Engelbart, they recognize the need, but it’s still unclear how this will turn out, if they care about other things even more or if they’re fine with already existing “solutions” like Sutra, Google Docs, YouTube, Facebook or WordPress (which is some of what they already use, I can work with the latter). My main entrance to their effort is the recordings of their meetings 20180721 GCC Saturday Barn Raising – Sam Day 1 (Google Doc), 20180728 GCC Saturday Barn Raising – Sam Day 2 (Google Doc) and 20180804 GCC Saturday Barn Raising – Sam Day 3 (Google Doc) as I don’t use Facebook, which seems to be the place of their main activities. In my comments to these recordings, I discuss some of my views on the solving of complex, urgent world problems and human systems, of which I in part remain pessimistic and suspicious. Besides my slow progress on my own little tools for the single user (in lack of a bootstrapping, co-evolving collaborator), I’m basically waiting for the 2018-08-24, on which there will be an initial Future of Text Institute call. Until then, I don’t have much to do besides reading, writing and working on tools/capabilities for the single user in solitude. Those are important too, but it’s time not invested in recreating the NLS/ARC Journal or building a FTI Journal or one for the GCC if it should later turn out to be of interest to end up with having such a capability eventually.

WordPress, as it is, as a piece of web software, shows another deficiency after I happen to have some more posts on the site: older articles become almost unfindable. It’s obviously designed to push new material, but the list of entries is limited to five, and whatever is in the backlog can only be found again by navigating through the pagination or by careful use of tags and categories, or the search of course if the random visitor miraculously knows in advance what to search for. The ViewSpecs of an OHS would allow the material to be presented as a long, full list of titles or even more importantly, as navigatable, interconnected hypertext that can be explored based on topics and interest. It’s fine to use WordPress as mere online data storage facility, but reading the material in the rendered form for the web remains terribly painful and asks for augmentation rather urgently. I hope people don’t mistake my hesitant “approval” of WordPress (in lack of something better) as an encouragement to fiddle with themes or plugins or anything else of that sort, it’s just that WordPress isn’t too bad for publishing plain XHTML while providing APIs to get data up and down again.

This text is licensed under the GNU Affero General Public License 3 + any later version and/or under the Creative Commons Attribution-ShareAlike 4.0 International.