A new LED display editor
14 April 2024One of my on-going projects is dot-matrix LED displays based around my LED tiles and with this in mind I wrote wxLED which is a program for generation of display data. However for some reason wxPython has become a pain to use so I abandoned it in favour of GTK via the PyGObject bindings and have used the latter toolkit for a complete rewrite. This rewrite had been on a hiatus for nine months but it only took a couple of days to get it into a state good enough for actual use, so felt it could finally be publicly released. I expect there are bugs but the majority of the planned functionality is already implemented.
With the change of toolkit the name wxLED seemed inappropriate for something that no longer used wxWidgets and I also noticed there is other software that uses the same name. Therefore the rewrite has the new name Taispeaint which translates as display and happenes to sounds nice; it is available from taispeaint.eu which at time of writing forwards to the Bitbucket repository but in the future may be turned into a complete website.
User interface
The overall user interface architecture of a main window and two editing sub-windows was carried over from wxLED since that approach is fundamentally sound, and although there were tweaks to the appearance most noticably with more horizontal scrollbars, the underlying user interface workflow is unchanged. The use of right-click content menus was dropped in favour of buttons since it was more obvious but the big improvement is the addition of drag-and-drop for reordering of LED sequences — this was enabled by the whole right-hand list being rendered manually rather than trying to construct it with GUI components. For something like this doing everything yourself rather than coaxing the toolkit into making widgets play nice throws up fewer complications.While custom animations are possible the real emphasis with the editor model is to make the basic use-case of simple scrolling text easy — have an alphabet with fully-customised glyphs as the font, and then simply type out the text. There are hard limitations most notably the LED matrix height being a fixed seven dots rather than being user-configurable, but this was chosen because it was the vertical resolution of the only hardware available that the application targets. There are places for a little extra polish such as drag-setting of multiple glyph pixels but for the time being the priority is shaking out the corner cases.
Decline of wxWidgets
I remember first hearing of wxWindows back in 2000 before it was renamed wxWidgets, and it has been my favoured GUI toolkit since at least 2011, but since then have lost favour with it. A lot of effort was expended on my part trying to appease certain maintainers in coming up with a sane interface that also exposed underlying functionality ofTreeView that I needed from wxDataView, but in the end gave in and just used GTK directly.
Had my patches made it in it would probably be quite some time before they filtered through to the wxPython project which was a reason why I converted wxCatalogue from wxPython to wxWidgets, and one motive for ditching the latter was being able to ditch C++ as well.
On top of this for some reason wxPython is now a pain to get working and I was better off ditching it entirely — having already gone through the effort of rewriting wxCatalogue as Leictreonach it made sense to rewrite wxLED as well and forget about wxPython. GTK has its own set of problems the main one being documentation being a massive pain compared to wxWidgets, but since I only use Linux these days it is advantage in almost all other respects. The modern trend is if a user interface really needs to be cross-platform it often makes sense to implement it as a web-based application rather than a workstation program, especially if it is something that need network connectivity in any case.