When I added support for autostarting applications to Whisker Menu, I did not feel like handling the cases where the autostarted application had been disabled or there was a system-wide autostarted application.

But…

It just kept niggling at me. I had expected it would make the code brittle and extremely complicated, so I hadn’t given it too much thought. However, it always bothers me to write incomplete code that doesn’t handle reasonable edge cases. And it turns out I was wrong! The new code is quite clean and simple, really.

Handling disabled autostart

The way I had before checked if there was an autostarted application was to simply look to see if the launcher existed in $XDG_CONFIG_HOME/autostart/. If I found it, I assumed that it was a valid launcher file, and therefore the application was autostarted.

However! You can disable autostarted applications by adding Hidden=true to the file, which means it shouldn’t show up as autostarted in Whisker Menu. How often will people do this? I don’t know, but as Xfce makes it easy to disable an autostarted application, it isn’t out of the question.

Handling global autostart

And you can have system-wide autostarted applications. It would be silly for Whisker Menu to allow you to add the same application twice, but since it only checked the user’s autostart directory, it was a valid possibility. Probably a lot smaller possibility than disabling the launcher, but in fixing one I fixed both.

To prevent conflicts with autostarted filenames before I had added an extra whiskermenu- to the start of the autostarted launcher filename. Now that it properly supports everything, it no longer does that. Which means I did break compatibility, but only for the people who have tried the git version of Whisker Menu in the past week. Sorry!

Ignoring other issues

Of course, there is one obvious situation this code doesn’t handle, and it was my issue with adding support for autostarted applications in the first place: it can’t tell if you have already added the same autostarted application before but with a different file name. Short of reading every single autostarted application launcher and checking for the same executable, there is no way to prevent that. Plus, that doesn’t even account for using symlinks as targets in launchers. So… the current code is as far as I am willing to go. 😉

But now I can finally breathe a sigh of relief and forget about the autostart code. 🙂

As has become my habit for January, I made a maintenance release of my programs. For the most part there aren’t any user-visible changes, but I did fix a bug in Simsu (the game was really wide when first launched) and I updated the translations. A few days ago I also made a Whisker Menu release, and that had some bug fixes in it. Enjoy!

I accidentally let this bugfix version of FocusWriter slip through the cracks. I did all of the work on it back in June, and then I got distracted with Tetzle and I never ended up making a release. 😲 I think at the time there were a few other bugs I thought I was going to look into, but I never made a note of which ones. 🤦 Oh, well, better late than never.

A user recently informed me of an issue with the Windows release of Tetzle: there were missing DLLs that prevented Tetzle from running! Interestingly, the builds ran on my computers without a hitch so when I had tested them before making the release I didn’t notice the issue. I have uploaded new builds of Tetzle 3.0 for Windows, so the issue has been solved.

What happened, as far as I can tell, is that the windeployqt.exe executable from the binary release of Qt 6.7.2 apparently thinks everything is compiled with MSVC instead of MinGW. 🤦 Which means that when it went looking for the compiler runtime libraries—libstdc++-6.dll, etc—it couldn’t find the correct ones.

I solved this by grabbing the windeployqt.exe executable from an earlier Qt binary release and used the qtpaths.exe executable from Qt 6.7.2 so that it would find the correct libraries and plugins, and everything was fine. I suppose I could have just copied the few missing DLLs by hand this time, but now I have everything set up so that I can avoid this issue in the future.

This shows how important it is to inform me of issues: if I don’t know about them, I can’t fix them! Don’t assume somebody has already reported it. 🙂

I am pleased to announce the release of Tetzle 3.0! 🎉

The biggest change is also one that should be completely invisible to most players: I replaced OpenGL with QPainter, which should solve some bugs that players have reported. And make packaging Tetzle easier. (And make Tetzle work with newer version of Qt 6.) It is also why I decided this release should be 3.0 instead of 2.3, to signify the large change in behavior.

I added edge scrolling to the board to make it easier to move the play area without having to drag it with the middle mouse button. There are now nice little arrows on each side to show when you can hover your mouse on a side to move the board, or you can click on the side to speed up the scrolling.

I redesigned the statusbar to make it less confusing. The progress through the game is now labeled clearly, and the zoom slider now has buttons next to it for zooming in and out and to the best fit.

I also redesigned the new game tab of the choose game dialog. It now shows labels next to the buttons to add an image, remove an image, and to set the image properties. I moved the buttons above the image selection area to make them more visible. And I made the tags into a combobox next to them, instead of a sidebar.

And finally, I made it center on the mouse cursor when zooming. That is the way the game was always supposed to work, and was the way it did before the 2.0 release a long time ago. Since it hasn’t worked that way in over a decade, I felt it was best to list that as a new feature. 😉

Along with the new features, I also spent time cleaning up the code to make it easier to maintain. None of those changes should be visible to players. If they are, I did something wrong!

Go and enjoy! And, of course, please report any bugs you find.