Nonpareil status

[brouhaha]

I'm not sure whether I'll build a new release of the current Nonpareil code base. I've been very frustrated with the bitmap (PNG) graphics, which don't scale up well other than by integer multiples. I've long wanted to use SVG (Scalable Vector Graphics) files instead. I also wanted to switch to using the Qt6 toolkit (which has some SVG support), instead of GTK+ 2. Updating to GTK+ 4 is harder than I expected, and I don't want to put time into that. Of course, using Qt6 generally requires programming in C++ or Python, so in order to make this all happen, I embarked on a major rewrite in C++, which will eventually be Nonpareil 2.0.

I've worked on two separate parts, the simulation core and the user interface, but so far I don't have them actually tied together, as I've been debugging them independently. At first I reimplemented the bitmap graphics user interface, and had that working with Qt6, but since I'm not satisfied with bitmaps, I started working on redoing it using SVG. Eventually I'll have to write the glue layer that interfaces between the simulation core and the user interface.

The most difficult part of the user interface so far has been that, while an SVG file is XML, and while the QSvgRenderer loads the XML into memory in something basically like a DOM, Qt6 doesn't provide any interface whatsoever for the client to modify, or even examine, the DOM.. I expected to do automatic color value adjustments to lighten keys for mouse hover, and darken them for mouse click, like in my GTK+ and now Qt6 bitmap interfaces, but I thought I'd just be able to tweak an attribute in the already-resident DOM and call update(), and that's not possible. (Short of hacking Qt6 itself, which is a recipe for disaster.)

I wasted some time trying to use a QGraphicsEffect, which can apply effects to painting, which is the low-level operation that all Qt rendering, including QSvgRenderer, goes through. There's an underlying QPixmapFilter class to do transformation like convolutions on the pixel data. Unfortunately the QPixmapFilter class was public in Qt 4.8, but is private in Qt 5 and later. Also QGraphicsEffect doesn't publicly expose the ability to install a QPixMap filter. This seems awful. Nevertheless, I wrote my own subclass of QGraphicsEffect, and had it almost working.

If I use one of the standard effects Qt6 provides, like QGraphicsBlurEffect, it seems to work correctly even with the QSvgGraphicsItem. but if I use my own custom QGraphicsEffect, the rendering of the "source" pixmap for the filter (from the SVG) is at lower resolution than the display. There are choices for device coordinates or source coordinates, but neither seem to do the right thing.

Anyhow, I've set that aside and taken another approach. Previously I had the QSvgRenderer load the SVG file for the whole calculator, and then I use that same QSvgRenderer for all QGraphicsSvgItems. You can tell a QGraphicsSvgItem to render only a particular subtree of the SVG file, so I have subtrees for the base, overlay, all the keys, and various display elements, and all were using the same QSvgRenderer from the same XML file.

I've changed it so that I read the SVG file into a buffer, then load it into an XML file, and update the button style attributes for the different colors, and write SVG back to two more buffers, which then get loaded into two new QSvgRenderers, one for hovered-upon buttons and one for clicked buttons.

Now the code that changes the button state just changes the button's QSvgRenderer and calls update().

Geez, this has been a huge amount of work, but I've finally getting somewhere.

I still have more work on the display in SVG, and in making a halfway-decent looking SVG file. Last year I paid an artist to produce a good 12C SVG file for me, but we got into a dispute over the contract terms regarding the license of the work, so now I can't use it and am just out the money, which fortunately wasn't a huge amount. So now I'm trying to put together my own, which won't be quite as pretty, but should be at least as good as the old Nonpareil bitmaps.

Oh, and I still have some work to do to get it to render text in the font I want. I can't depend on particular fonts being present on the user's computer, and I don't want to install fonts, so I want them embedded in the SVG. But QSvgRenderer does not support embedded fonts, so I have to do another bit of manipulation on the SVG loaded into memory, extract the font, and hand it off to the QFontDatabase.

I hope to have in a few weeks a UI prototype ready to offer to folks that might want to try it. The simulation won't be hooked up.

Once I have working SVG files for all of the supported calculators, I plan to remove the bitmap (PNG) support entirely.