It has been a busy week without much time for Doomsday. Sometimes after a break it is easier to return to the project by looking at a completely different topic than what I was working on before. This allows one to ease into the code again in a more comfortable way.
The log history widget was among the first that I wrote on the new UI framework. Since then, I’ve added a handy utility class called TextDrawable for drawing and laying out UI text. It has nice features like automatic background threading if there is a large amount of text. However, LogWidget being quite old, I had implemented a separate multithreaded text rendering mechanism there. I decided to replace this with TextDrawable so there wouldn’t be unnecessary redundancy in the code base.
This has another benefit, too. While doing a couple of improvements in the Doomsday Script command line widgets, I noticed that printing a very large entry (such as locals()) would completely hang the UI for several seconds, as the text was being prepared for drawing. This is because the old text implementation in LogWidget didn’t take into account that only a small subset of those lines would actually be visible at a time. The newer TextDrawable supports this situation, avoiding the glitch.
You might wonder why locals() would print a lot of stuff in the script command line. I’ve made it so that the native modules are automatically available in the interactive script process, meaning that for instance Config and Defs are the “locals” of the process (at the global level). Currently records are output with their full contents, even though this might be thousands of lines of text. I should make it so that some of the values are truncated if it would result in a massive log entry.