
I will get it right out of the way that in terms of development, I didn't really do much today. Today's development topic was more future prospective development around AI / LLM. With [Slush 2024](https://slush.org/) currently ongoing, I wanted to take the opportunity outside a long day of work to go visit the fine folks over at [Jolla](https://jolla.com/) and [Venho](https://venho.ai/). As someone that has been a fan of Jolla and Sailfish OS for a long time, originally owning the Jolla One and now the Jolla C2 (which I have talked about my plans for developing on in my [Dev Diary 13: Koto - The Resurrection](/2024/11/01/dev-diary-13-koto-the-resurrection/) and intend on switching to once 4G is sorted), I have been very interested in seeing **first hand** their line of thinking behind an AI-first, local-first, privacy-first computer.

If none of that sounds like your thing, that's perfectly fine. You can check out of this post and come back tomorrow. However for me, local-first LLM is something I have tinkered with using ollama, leveraging that in the [Zed](https://zed.dev/) editor (instead of relying on Copilot), and started looking into solutions for Local Agentic RAG like [LangGraph](https://www.langchain.com/langgraph). The AMD hardware in my MiniPC isn't quite powerful enough to do local LLM at any sort of reasonable speed, so my goal was to shift that over to using [ipex-llm](https://github.com/intel-analytics/ipex-llm) with my Intel Arc GPU connected over Oculink for GPU accelerated processing.

Well, instead of having to build all of that myself, maintain it, worry about a kernel update possibly borking my Intel GPU detection for some reason (_cough_ recent Fedora update it seems has done that _cough_) - what if I could just have a box that sits in my living room and does all the agentic things for me without a whole lot of fussing on my part? What if my data could sit on device instead of being collected and farmed by Google or Microsoft? Well that sounds pretty exciting to me.

This is what Jolla (as the hardware provider) and Venho (software) have set out to accomplish with their Jolla Mind2, which is currently up on [pre-order](https://shop.jolla.com/details/1a1f18c3-f050-4893-aa89-2493e2c742d1/). I wasn't going to just preorder a [Jolla Mind2](https://www.jollamind2.com/) without actually checking it out myself. First I wanted to hear more concrete plans / key objectives for the device / more importantly the software.

So after having left work late, I trudged through the frankly miserable weather (snow, slush, rain, wind) and suffered the drunk Finn sitting next to me on the tram to go check it out.

![](/images/todays-dev/2024/11/venho-ui.jpg)

I started out being given a guided tour of the current design for the home view (I don't know what they call it, it's just what I'm calling it) and it was followed by their Messaging center. The intent behind the home view seems to be to provide you quick access to specific contexts and collections of content. Some examples from their Messaging center and discussions I had with the team was:

- Upon connecting your email account (IMAP / SMTP, other methods later), it would be able to pull those down and process them locally. If there are emails you need to reply to, it'll provide summaries and write responses. They made it very clear that it will **not** send the email on your behalf, you still need to review it before it sends. This isn't the movie Her, we know how that one ends.
- If there are documents that need signing, their "signing agent" can do that for you. That is enticing as someone that always has to find their damn scanned image of their signature on the rare occasion something needs to be signed! I just hope they integrate Docusign somehow.
- The assistant would be capable via their Calendar agent of determining if suggested dates & times (e.g. from the Message and Email agents) would work for you, providing you suggestions for adding that into your calendar, suggest reschedules, etc.
- You could store various media on device to help in facilitating multi-modal scenarios. Right now their software is currently focused on text-driven modals (with an 8B model that I suspect is probably Llama), so time will tell how they evolve their software to support other modals like image and video.
- You could maintain separate different contexts, like having one for personal and another for work.

**Development-related**, I asked if this was something the community could build on or if it was going to be a more closed ecosystem like Apple. They mentioned that they will have an Agent SDK. I did some research in their Discord and it is stated that the API clients will be open source and you could even completely replace the frontend if you like. While it wasn't something I raised while I was there, I did take a look at their Discord server for any open source plans. At least in August, Venho stated that:

> Most of the platform will be FOSS, but we will have some closed parts (mainly related to Venho paid for services) for instance and UX.
>
> Though this is still something we're discussing internally, our FOSS strategy and timeline for that.

In principle, I like the idea of it being open source, but I can understand how some aspects like any Venho services (for example if they were to offer hosted large models) wouldn't necessarily be. I think time will tell on this one but if Jolla is any indication of the direction they might go, I think a hybrid approach is fine and seems to have served the Jolla community well in many regards -- for example a range of devices have been ported to Sailfish OS with just about as much success as you see with ports of random Android ROMs.

Regardless, a step away from everything going to the cloud and instead at least being able to write my own open source agents for my own content, for a local device that is running Sailfish OS under the hood, with much of it being open source components is absolutely a step in the right direction. Perfect is the enemy of good and I have always been pragmatic when it comes to open source. If I could integrate it into my desktop and enable near real-time agentic behavior between the two, that'd be awesome. Do the same on my Sailfish OS device? Yes please.

For now though, it's all still a lot of _intention_. Now all they have to do is execute on all of it, or make sure that what they can't immediately deliver on should have mechanisms (like a community plugin center or "marketplace" like Obsidian has) so the community **can** build out integrations. Otherwise my concern would be a box getting launched that is effectively a fancy piece of kit for downloading and reading email.

---

That's it for today folks. No grand conclusions. No statement on whether or not I'll preorder. Just some cool shit I really wanted to take a look at, share with the wider world, and some cogs in my head related to developing agentic RAGs that I wanted to start turning. I want to be clear at the end of this since I imagine some of the writing might've come off as sales pitchy that none of this is sponsored (I am **not** above sponsorships though), my tram ticket wasn't paid for, and I wasn't even directly invited (registration was open). I did leave though with a Jolla beanie and a beer though. Can't pass up swag or beer.


Today I wanted to spend some time making sure I wasn't getting too into the weeds and unintentionally overcomplicating some of my classes and inheritance from QtWayland. It was recommended that I take a look at Plasma Desktop's compositor [KWin](https://invent.kde.org/plasma/kwin), as it is written in C++ and leverages QtWayland.

Specifically in KWin I looked at their:

1. FrogColorManagement protocol implementation [header](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/frog_colormanagement_v1.h) and [client code](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/frog_colormanagement_v1.cpp)
2. Wlr Data Control protocol [header](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/datacontroldevicemanager_v1.h) and [client code](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/datacontroldevicemanager_v1.cpp)
3. KDE AppMenu Manager protocol [header](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/appmenu.h) and [client code](https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/appmenu.cpp)

A couple key learnings from it:

1. I should really be putting my definition of `QObject* parent = nullptr` at the end of my constructors, it'll make specifying the constructor args nicer since I won't always be starting with noise of `nullptr`
2. I could probably get away with specifying a static protocol version rather than using `wl_proxy_get_version`. I am sure there are arguments for both, but I don't expect to be supporting many versions of a given protocol, assuming they were to exist, in the foreseeable future. _knock on wood_

Thanks for the readable code, KWin developers! It is much appreciated 💯

I wasn't really able to draw any clear conclusions on whether or not I am particularly overcomplicating my use of QtWayland, but I did take the opportunity to review my class constructors. I was able to at least simplify by constructor for `WaylandOutputHead` and I'm hoping with some more tinkering I can do the same to my `WaylandOutputConfiguration` which inherits from `QtWayland::zwlr_output_configuration_v1`.

Afterwards, I spent some time implementing a `configure` method on my head class to construct and return a new configuration class. There isn't much involved in creating it as it is mainly around our internal reference to the `::zwlr_output_head_v1`, however in places like the DBus server I will be using it regularly. One method call instead of repeating three lines over and over again? Yes please.

Same deal in the configuration class as well, I implemented an `enable` method that creates a `QtWayland::zwlr_output_configuration_head_v1` so that way I can take advantage of simpler methods for performing actions like position setting.

Speaking of which, I took that stuff into use and started sorting out the configuration in my DBus server methods, starting with SetPosition.

I think my next step will be to implement a function on my output orchestrator or manager that will create dummy configurations for any output that doesn't match a given serial. The reason for that is it is a protocol error to only specify the configuration of one head at a time. So if I change the position of a head, I must also inform at the same time that all other heads are either enabled or disabled. 🤷 Having a function that does all of that will hopefully keep my DBus server code much more concise and not prone to so much repeat protocol noise.

Last thing I did development wise is a bit meta, which is added a Bluesky / Mastodon / Threads "call-to-action" at the bottom of all my Today's Dev posts. Figured if folks were being direct linked to the blog (maybe that is you, hi!) then they might not navigate to my homepage and see links to my socials.

And with that, I'm off!


Shorter one today, brain is a bit mush from $DAYJOB. Mondays, am I right?

Plan set out [yesterday](/todays-dev/5) for today was going through remaining instances of `WaylandOutputManager` and cleaning those up. Half expected to be hooking up slots and signals, but..

I forgot about all my code related to creating a `zwlr_output_configuration_v1` and `zwlr_output_configuration_head_v1` for configuring a head before applying it. Realized that as I was going through my DBus code where those instances are used the most (and also where I have DBus methods like setting a given mode for an output). 🤦

So messing around with the QtWayland equivalent is basically what I worked on the most for today. I think I need to take more of a look at other code leveraging QtWayland generated classes to see if I'm doing this the sane way or if my head is still stuck in C land. Might be a thing for tomorrow instead of just code monkeying.


In [yesterday's post](/todays-dev/4), I mentioned that I was going to be refactoring my classes to inherit from the generated `QtWayland::CLASS` interfaces from `QtWaylandScanner`.

Excluding one function that I still need to mull over a bit on how I want to implement (my `WaylandOutputHead::zwlr_output_head_v1_current_mode` function), I have completely refactored my chonker `WaylandOutputManager` class 🥳

Structured it in the following way:

- `WaylandOrchestrator` - This is the top level singleton class that will handle the global registry and the output manager. It will have a ref to the `WaylandOutputManager` so I can go from the singleton -> manager -> function like getting the output heads.
- `WaylandOutputManager` - This class handles the output heads. It inherits from `QtWayland::zwlr_output_manager_v1`, has a `QList` of `WaylandOutputHead` (moved it from `std::vector` since I might as well while I am moving it all over to Qt bits anyways) and our function for getting a specific output head based on its serial.
- `WaylandOutputHead` - This class handles an individual output head. It inherits from `QtWayland::zwlr_output_head_v1` and has all the properties of an output head (name, description, size, modes (which is a `QList` of `WaylandOutputMode`), position, scale, etc.).
- `WaylandOutputMode` - This class handles an individual output mode. It inherits from `QtWayland::zwlr_output_mode_v1` and has all the properties of an output mode (width, height, refresh rate, flags, etc.).

Each of these classes now has their respective function overrides for specific Wayland events. To list a few:

- `WaylandOutputManager::zwlr_output_manager_v1_head` - This is called when a new output head is added to the manager.
- `WaylandOutputHead::zwlr_output_head_v1_name` - This is called when the name of the output head changes or during the first roundtrip. It is a very simple function that just sets the internal member to the new name.
- `WaylandOutputHead::zwlr_output_head_v1_mode` - This is called when we get a new mode for the output head. It will create a new `WaylandOutputMode` object and add it to the list of modes for the head.
- `WaylandOutputMode::zwlr_output_mode_v1_size` - This is called when the size of the mode changes or during the first roundtrip.

Separating them all out feels just so much more ergonomic and easier to parse.

Plan for tomorrow is to go through the rest of my code where I was using `WaylandOutputManager` and swap them over to the orchestrator, then hook up some signals / slots that I set up today as I was working on the classes. After all, that's _the_ reason I shifted it to being a Qt application instead of a generic C++ one at all -- the Qt event loop and signals / slots make callbacks much easier!

Will be interesting to see if this thing flies when all is said and done 🙂


Short one today since it was mostly focused on one specific task that I expect to take a few days to complete, plus the usual Buddies of Budgie standup on Saturdays.

[Yesterday](/todays-dev/3), I was dealing with a bunch of linker issues since for some reason the generated client headers and public code from `ecm_add_wayland_client_protocol` weren't being discovered properly during the build phase. I still haven't figured out what the hell is doing on with that and figured "screw it", I'll continue some refactoring and have my classes inherit from generated `QtWayland::CLASS` interfaces from `QtWaylandScanner`. I wasn't originally going to, at least after feeling so defeated yesterday, but after some tinkering today I very quickly realized how much cleaner the code will be by leveraging the generated interfaces.

So previously, my `WaylandOutputManager` class only inherited from `QObject` for the use of signals and slots, and had members for `zwlr_output_manager_v1`, `wl_display`, `wl_registry`, all the output heads, etc. That was fine given the model and it had worked before all the refactoring, but I ended up with a ton of class functions for all the various Wayland listeners like those for the output head, output modes, output manager, and global registry.

With the splitting up that I am doing now, at least what I have so far is a new `WaylandOrchestrator` class that effectively _is_ what WaylandOutputManager was (the toplevel), but classes like WaylandOutputManager will now inherit not just from `QObject` but from `QtWayland::zwlr_output_manager_v1` as well.

This in practice means I just need to implement the functions like `zwlr_output_manager_v1_head(struct ::zwlr_output_head_v1 *head)` from the class and the `init` function generated by QtWaylandScanner will take care of setting up the listeners for me.

This model will feel a lot nicer in places like inheriting from `zwlr_output_head_v1` because of the sheer amount of properties of a head that I need to handle (name, description, size, mode, position, scale, etc.).

So not quite the route I was expecting to already be doing down before even making the damn thing a public repo, but I know I will be much prouder of the work once it is all said and done!


Today I worked on fixing the issues I encountered yesterday with using my singleton classes. It turns out, `auto manager = bd::WaylandOutputManager::instance()` would attempt to do a copy, simply changing `auto` to `auto&` sorted that out.

Got to the point where it would build (yay!) but failed on linking. After much struggle, I consulted my friend Neal Gompa on it. Him and I investigated the CMakeLists.txt, source, etc. but no solution on that front. However, I did learn that apparently there is a [QtWaylandScanner](https://doc.qt.io/qt-6/qtwaylandcompositor-custom-extension-example.html) and the ECM [FindQtWaylandScanner](https://api.kde.org/ecm/find-module/FindQtWaylandScanner.html) that generates the C++ interfaces on top of the C ones. I wish I knew that one before I started the whole project!

Not yet tempted to spend the time to try to port over to those C++ interfaces, since the C ones should be working fine. But the hunt on the issue causing the link error continues!


Today I spent time on my C++-based Budgie Daemon v2. For those not familiar, Budgie Daemon v2 is intended to serve as the foundation for any major daemon developments going forwards, eventually replacing functionality provided by the budgie-daemon that lives in the budgie-desktop repository for Budgie Desktop 10.x and acting as the beating heart for Budgie 11.

At the moment, the focus is on interactions with Wayland protocols for display / output configuration and providing a DBus server for clients like Budgie Control Center to leverage for its graphical display configuration. After that the focus will be on global shortcut management.

So anyways, the project started out as half an experiment and half my "hello world" for starting to learn C++. Since a lot of the references I used for Wayland-based display management were in C, the code took on a hybrid between the C and C++. It was at the state where I was able to get all my outputs and modes, read in my TOML-based configuration, and reliably apply the configuration to the outputs. I had also started on the DBus server, but decided before going too deep that I'd clean up all the code, make it more C++-like, and make it public so others (including on the team) can start dogfooding and using it.

This cleanup has involved taking a lot of globally namespaces functions and wrapping them up in various `bd` namespaces or singleton classes (my favorite). As part of the refactoring, I want to make sure these new classes are inheriting from `QObject` so that we can take advantage of Qt's signal/slot system. For example, the config system and DBus server will know when the WaylandOutputManager has finished initializing, so we know we have all available outputs and can apply our initial configuration or allow state change over DBus.

Well, [unlike my experience working on Koto](/2024/11/01/dev-diary-13-koto-the-resurrection/) and singleton instances like Cartographer, having the classes in the daemon inherit from QObject has been a bit trickier today and I have been getting the following error whenever I call `bd::WaylandOutputManager::instance()` to get the instance:

```
error: call to implicitly-deleted copy constructor of 'WaylandOutputManager'
```

My suspicion is that this is due to having defined class members that are of the struct types `zwlr_output_head_v1_listener`, `zwlr_output_mode_v1_listener`, and `zwlr_output_manager_v1_listener`. Even after fixing the creation of those listeners to take either lambas that then call a static cast of the instance and call the appropriate listener, I still get the errors. 🤷

Tomorrow I am going to try making all of those listener structs be statically defined outside the class and have the functions call the singleton instance, remove the members from the WaylandOutputManager class, and hope that I don't get that copy constructor error further. Hopefully works out. 🤞

Finishing up my move from Meson to CMake was a small victory today at least. I decided last week or so that I wanted to port it over so I could leverage KDE's "extra cmake modules" (ECM) to easily find WaylandScanner and generate client source for Wayland protocols. Splitting up the CMakeLists.txt in a similar fashion as Koto (where the root CMake sets up the project and basically just adds the subdirectory, and the CMakeList in the `src` folder handles everything else) ironed out the remaining issues I had with the port!


Today I moved my Next.js site from using [eslint](https://eslint.org/) and [prettier](https://prettier.io/) to [Biome](https://biomejs.dev/). I did this while upgrading from [Next.js 14 to 15](https://nextjs.org/blog/next-15), which moves eslint from 8.x to 9. 9.x encourages the use of its new flat configuration file and honestly I am just not a fan. Rather than kicking that can down the road with the environment variable to use the old non-flat format, I figured I would just bite the bullet and move to Biome.

With Biome I was able to sort it all out with three commands and a tweak to the `biome.json` file (since I wanted to use double quotes instead of singles). Seems to be working out so far!

Had an idea to implement a rolling list of what I develop (outside of work) for each day. Implemented all of that with some refactoring of my utilities for fetching content, rendering blog posts, etc. Hopefully this will complement my Dev Diary posts, of which I need to probably restructure slightly as they have so far been catered to Koto than anything else and I'd like to write up longer form content on other development topics.