Published:

Jarle Aase

Monthly update, May 2024

bookmark 2 min read

Misc

Github Actions

I have started to use Github Actions for some of my projects in order to validate that they compiles and the unit tests pass on the major platforms.

I currently have 43 repositories on Github. Almost all of them are original projects started by me. Most of then are ready and in maintenance mode, which means that I don't make changes unless something breaks. It also means that some times my projects break when libraries or compilers are updated. To catch such breaks, I configure Github Actions to automatically rebuild the projects I build there every month. May 1st, all the projects failed their monthly update. All of them for the MacOS build. Some of them even at the prepare stage where the compiler and tools are installed! What a nice spring surprise from Github to its users. From the errors, it looks like they have changed their runners from Intel to Arm hardware.

The primary problem turned out to be an action I use to install the compiler and build tools: aminya/setup-cpp@v1. I wrote a brief blog post about how I solved it.

Projects

Next-app

Next-app is a GTD application for desktop and mobile.

Most of the time this month was spent on the calendar and "Time Boxing". The most interesting challenge was to make and implement an algorithm to handle overlapping appointments on in the visual calendar for a day.

Crowded day

The screenshot is an example of a day with some conflicting calendar events. As you may notice, the algorithm tries to utilize the space on screen in an optimal way. The current implementation is just partially complete, with a focus on moving and changing the appointments, not presenting them in a appealing or useful way.

The UI application use QT and QML. To visualize a day on the Calendar, I started with a Rectangle and added a Canvas component to draw the lines for hours and 15 minute intervals in javascript. Then I call into a C++ method from javascript. From C++ I construct and put the QML components for individual calendar events at the correct coordinates on the screen. The components are re-used if the day is rendered again, for example if an appointment is moved or changed or deleted. Unused components are kept in a pool, so they are available when events are added. I expected this to be hard. In the QT/QML code and examples I have seen, almost all of them use a Repeater or ListView to render their own components, if their numbers or properties vary. The Repeater cannot be used because it don't handle changes in the model (although Github Copilot insisted that it was perfect for the job). ListView is not suitable for a calendar with a variable number of logical columns (depending on the number of conflicting events). However, it turned out to be quite easy to roll my own low level QML component manager in C++.

The calendar is implemented as a MVC component, where the controller run on the back-end server. That means that if I have multiple instances of the app running, showing a calendar with the same week or day, all the calendars are updated simultaneously. I use a persistent gRPC streaming call to inform all the clients about any changes in the data.

I also spent some time "styling" the QML UI-application. I found QT's documentation about styling a bit confusing. My first take was not brilliant, but it gave me the insight about how to do it right next time I iterate over it. Also, I have "dark mode" now, and that seems to be everything that matters in contemporary UI work ;)

Books completed

The last book in the list was surprisingly good! Absolutely recommended for C++ developers who want to take their code to the next level.