I’m not sure where time is going… I thought it had only been a week-ish since my last update but WordPress tells me that it is over three weeks!
I have done a lot in that time though, so that’s something. Yay?
Editors Service “Stuff”
Most of the ui components for the Editors Service are now done, this includes the viewer that allows users to make comments on another person’s work. There are still a couple of major things to finish up but it’s mostly “there”.
Update to the QW website
For a while (I’m not entirely sure how long) there has been an issue with the QW website that prevented people from creating Editors Service accounts. I finally bit the bullet and fixed the issue but my god did it lead me down a rabbit hole.
One of the big problems with coding (in the 21st century) is that there is a sort of arms race that occurs in development. Most developers are constantly updating their code and putting out new versions. However this often leads to incompatibilities between different components. For example Tomcat 9 might use version 10 of component Y. Component Y might use version 5 of component X and so on. This leads to a graph of transitive dependencies that you need to assemble for everything to work correctly. This issue used to be simpler but in the past 10 years or so it has become a major problem and keeping track of all of these dependencies requires tools to make it happen. I use gradle now to resolve these dependency problems.
The underlying problem was that the QW website was using a very (very!) old version of JDOM. It was using version 1.1. This code is about 15 years old. However when I went to check out the new version the JDOM website wasn’t working. Oh dear. Thus I started looking around for a replacement for JDOM. Luckily there is one called dom4j and it looked easy enough to use so I went with that instead.
It turns out however that JDOM underpinned a lot of the libraries I wrote 15 years ago (and I’ve never updated) and nearly all of those libraries are used in QW as well, not just the website. Oh dear. Thus began a process of updating the code and dragging it into the modern era. I’ve put most of the code on github now (as private repositories) and updated the build tool to use gradle. For those of you out there who have done code development, one of my libraries was so old it still had the CVS version control directories present!
So the QW website has now been updated and I’ve also updated QW itself to use the updated libraries. All that because Tomcat didn’t have the right XML parser that JDOM needed.
One of the libraries I wrote all that time ago was a logging mechanism. It was very basic, it just wrote messages to a file. At the time I wrote it java didn’t have a good logging mechanism. A reasonable logging api (java.util.logging) was introduced in 2002 with Java 1.4 but I didn’t need to change since my own worked well enough.
But, since I’m spring cleaning the code, I’ve decided to bite the bullet and move to java.util.logging. This has had some ups and downs. The ups being that I can log to multiple places at once (although I could have done that easily enough anyway) and that I can have multiple log that are rotated. This was a feature I intended to add to my logging library but never got around to, it’s a nice to have but not a must. I’ve now set up the QW logging to have up to 10 log files. There are times when users tell me about a problem and it would be good to have previous log files. However there are downs as well, for instance it’s not possible to get access to the log files directly, i.e. to transfer them back to the QW website server, so I’ve had to write some code to do that. Also, it seems that other people’s code also uses the same loggers I’ve created so the loggers are also outputting (to the console at least) more messages than I want to see. I could add a filter for this but I’ve other things I need to do.
And, whoever decided to get rid of the frames in the JavaDocs needs to find a giant hole and throw themselves in. It is the WORST anti-end-user decision I think I’ve ever seen anyone make. One of the most important aspects of the frames was the ability to DISCOVER classes and packages. A search doesn’t cut it because you have to know what to search for, you giant muppets! And a search is slow and time consuming to perform, often when you are working with a package you are moving between a number of different classes and the last thing you want to do is keep typing in the name. Grrr…
An annoying bug… squashed
For the past few weeks I’ve had an issue with the UI where it won’t update properly and the window would sometimes look weird with text displayed in funny places.
Unfortunately I introduced this bug in the major update I did for the Editors Service code, which changed/added about 20,000 lines of code and changed 164 source files. Yesterday I finally tracked the problem down to a single line of code:
Looks pretty innocuous right? However this line was in a layoutChildren call, it was intended to fix a custom split pane issue where, sometimes, when the user drags a divider bar to resize a component the divider would disappear or not be draggable again. The line of code moves the component to the front of the stack of components and allows it to be used again.
Now the layoutChildren method is used to lay out the child components of a component. Think of it as the code that tells the pieces of a jigsaw where to be placed.
The trouble is, putting the toFront call in the layoutChildren method caused a change in how the jigsaw pieces should be laid out so it triggered another call to layoutChildren. This led to a loop but not an infinite one (and thus would not be detectable in a profiler) and worse still, no exception was thrown about the potential issue, thus my code was unaware I was messing things up.
In short, this has meant that I spent days trying to trial and error my way to find the problem. It’s a lesson learned but the knowledge was painful to acquire.
Ah cascading stylesheets… Over the years I’ve come to hate the “cascading” part. In theory it sounds fine, your component inherits the style properties of another component or style. But the on the ground reality is that you can spend a lot of time scratching your head trying to work out WHY your component has a particular style.
The developers of web browsers recognised this issue a while back and have introduced excellent web developer tools that let you see not only what styles your component has but also the full list of styles that apply to your component.
For example (taken from a random website, using the Chrome “inspect” function):
Here, all the styles that apply to the component are listed and, importantly, the stylesheet files that the styles are defined in are also provided.
As a web developer this information is wonderful and saves an enormous amount of time and effort.
However, JavaFX does not have a similar tool. The closest we have is ScenicView which hasn’t been updated in years and is frankly crap. In years gone by, I would have taken the project and revamped it but I don’t have time for that nowadays.
So, instead, I’m developing my own version of a CSS viewer within QW itself. This will hopefully save me a lot of time because I’m finding that the majority of my development time is spent tweaking styles and trying to work out why they aren’t working as I intended. This viewer will also be needed for QW “skin” developers, since, at the press of a button they will be able to see what styles and stylesheet files apply.
I’ll do another update on the css viewer once it’s more fully developed.