change_instructions_navigator

After several months, I finally reached the chapter in “Introducing JavaFX 8 Programming” by Herbert Schildt that addresses the <code>TextArea</code> of the JavaFX GUI library, keyboard and mouse input events already having been covered. With this, on a productive weekend, I guess I can come up with another prototype of the <a href="https://skreutzer.de/2018/07/19/change-tracking-text-editor">Change Tracking Text Editor</a>, making it the third attempt. In parallel, I realized that it would be helpful for the previous other two failed attempts to make a graphical “Change Instructions Navigator”, so it becomes a whole lot easier to reconstruct the individual versions and hunt down the spots where the recording actually goes wrong. I doubt that this will be key to finding the solution, for example by revealing a programming error occurring in a rare constellation, if the problem is related to timing, but it might help to arrive a clearer understanding what the issue is, and the tool will be useful in general as the change instructions recordings need to be replayed and navigated in a granular, selective way, not only reconstructing the last version as the <a href="https://gitlab.com/publishing-systems/digital_publishing_workflow_tools/tree/master/htx/change_instructions_executor/change_instructions_executor_1/"><code>change_instructions_executor_1</code></a> does. It’s clear that the capability to reconstruct every single version (not only on instruction sequence level, but additionally for every individual character event) should be made available to headless workflows in terminal mode, be made programmable for automatization, but the navigator as a GUI component has the objective to hold state for the session and ensure that the version navigation is performed fast, so it might be too expensive to call a stateless workflow that has to reconstruct all versions from the beginning up to the desired one, so the navigator belongs already more along the lines of an integrated change tracking text editor environment. During the last few updates of <a href="https://trisquel.info">Trisquel 8.0</a>, one of the <a href="https://www.gnu.org/distros/free-distros.en.html">100% libre-free GNU/Linux distros</a> and therefore my reference system, I must have obtained an update to the <a href="https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)">Nashorn engine</a> (available via the <code>jjs</code> command if you have Java installed), which is pretty late in comparison to the rest of the world, but that’s the time it takes to legally clear and package it for the distro. Java and it’s GUI components contain browser controls of course, and such need to come equipped with JavaScript nowadays, so it makes sense to implement the JavaScript interpreter as a generic component to be shared and maintained only once instead of multiple times, and this interpreter eventually can be made available to all of Java without the need of having a browser control around. I had an earlier version present already, but with the update, ECMAScript 6 became available now where previously the attempt to use it resulted in an exception, so only ECMAScript 5 was available. Why I need ES6? Because it introduces the <code>let</code> keyword that allows me to evade the treacherous variable hoisting of JavaScript, which had cost me quite some debugging time while implementing the <a href="https://www.bitchute.com/video/Nu2Cv9fc8cvT">HyperGlossary prototype</a>, so I never want to work with any JavaScript below ES6 again. Now, with the call <code>jjs --language=es6</code>, you’re set to go. What this promises: a world in which JavaScript components can be written once and then be executed traditionally in the browser, on the server with node.js and on the client as a native app (not dependent on a server, not limited by the CORS nonsense etc.). To make this a reality, environment-specific calls need to be abstracted away behind a platform-independent interface standard, because JJS does not have the DOM or <code>window</code> object, node.js doesn’t have <code>alert()</code> and so on, and especially where the DOM is (ab)used to build a user interface, Java GUI libraries should be called analogously in JJS. For every execution target, the right implementation would be packaged, but the target-independent JavaScript components could run on all of them without change, so they only need to be maintained once, allowing for code reuse because the wheel doesn’t need to be reinvented for the three target execution environments. As one can assume that people will have Java installed on their computers (for LibreOffice), the need to install a separate bridge from JavaScript to the local operating system wouldn’t be needed any more, as it traditionally was the case all the years before. The downsides of this concept are that the interface standard doesn’t exist yet, we would have to design it, which is less a problem for headless workflows in terminal mode, but could reveal unresolvable conflicts when it comes to GUI applications. Furthermore, it was announced that Nashorn will be replaced by something else, which shouldn’t matter that much as the interfaces should stay the same. More worrying is the indication that the OpenJDK team finds it hard to maintain Nashorn as JavaScript continues to change all the time (it’s a hell of a language), and <a href="http://openjdk.java.net/jeps/335">asked the project to abandon it</a> again. GraalVM might come to the rescue, but it can take ages until such developments become available on my end as reliable infrastructure that doesn’t go away soon and therefore can be built upon. The risk of discontinuation means that investing into JavaScript components might turn out to be a dead end, repeating the fate of the <a href="https://hyperscope.org">HyperScope</a> project, just as browser people like to screw everybody else up and not do the right thing. For this reason, only small scale experimentation around this is on my agenda, not doing anything serious with the web/browser stack in the forseeable future, despite I really would like to. So I’ll have to stay with native development, not benefitting from the decent rendering capabilities of the browser, but what else are you gonna do, there aren’t other options really. As I completed reading Matthew Kirschenbaum’s “<a href="https://skreutzer.de/2018/06/23/track-changes-book-by-matthew-kirschenbaum">Track Changes</a>”, I need to add the key findings to the blog article as soon as time permits. I also wonder if I should try to translate as much English articles into German as possible, so they can serve as an invitation to the topic of hypertext to a German speaking audience. Sure, we’re the land of printing, but I don’t see why this should limit the interest in hypertext, to the contrary. Writing reports like this slows down technical work quite significantly, but I hope it helps to get discussions on the various topics going while offering a chance to align my activities with what’s generally needed (in terms of priorities and avoiding duplicate work), eventually piling up to a body of material on which the new capabilities and methodologies can be used on. Some countries have restrictions on what one can call an institute. In Germany, there are no general limitations, but as institutes may be departments of a university or as independent entities join cooperations with universities, courts have ruled several times that other organizations that wanted to create the impression that they’re somehow associated with an university in order to appear scientific and neutral are not allowed to call themselves an institute. Does the FTI need to be “scientific” at all, be it to be allowed to keep “Institute” in the name or because of the kind of work it is planned to be engaged in? If the name needs to change later just to avoid legal trouble, I guess I would have to change my use of it in this articles. For some time however, we might need to follow the convention that published material can never change, so if we end up in this dilemma, we might be forced to do some heavy lifting to introduce upgradability. This text is licensed under the <a href="https://www.gnu.org/licenses/agpl-3.0.html">GNU Affero General Public License 3 + any later version</a> and/or under the <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 International</a>.