This post covers two things, the migration of QueryC++ from GitLab to codeberg.org, and transferring code ownership to Obsidian Wolf Labs. Below I will explain why I have made these choices and I will start with the migration.

Originally, QueryC++ was hosted on GitHub and the code from back then is still available there, if you are interested here is the link. I moved to GitLab because I add the time (and still have) had some problems with how Microsoft was changing GitHub, I disagreed with the changes on a philosophical level. This has not really changed and I am not to happy about Microsoft Copilot either (a thing I will not link). So I moved to GitLab and I have been really happy with it and I have no plan to fully abandon the platform, I have not fully abandoned GitHub either. So why am I moving QueryC++? Well quite frankly I like the philosophy of Codeberg and I think it is the right home for an open source library like QueryC++ to live and thrive. I like the ideas behind Codeberg and that it is host in Europe. The code is now available here: codeberg/queryc++.

However! For QueryC++ I will try something new. I will keep the remote host for GitLab active (if I can figure out how) and then push the code to both repositories as a backup. But all issues and stuff will be moved to Codeberg.

Next, transferring ownership to Obsidian Wolf Labs. Who are they? Well they are… me! I am the owner and sole engineer at Obsidian Wolf Labs, so why the transfer? Well it feels right to give do this and that is about it. The code will remain under BSD license and it is unlikely to ever change. I just felt like it was time to take this particular plunge.

So that is it. I hope you will keep following the development of QueryC++.

./Lars

Over the last couple of years that have been some discussion in the Gnome community, in particular on r/gnome about why Gnome is against theming. This article from OS news GNOME to prevent theming wider community not happy, explains the issue fairly well. Then there are a some blog post where it is discussing this in more detail: GNOME developers against themese?, Why and how libadwaita prevents theming?. The OS news article claims that the community in general is frustrated, which I sort of agree with based on what I have read on the subject over the past five years or so. Below is an comment take from the Why and how libadwaita prevents theming? discussion on gnomes discourse (Link to the actual comment)

I don’t dispute the problems with replacing stylesheets and I think distros should stop it, but the artificial restrictions are stupid. If I want to break my app, let me please…

In contrast Gnome has a post about Restyling apps at scale and what some of the issues are and a lot of the discussion was in particular sparked by this post Please don’t them our apps. To outline the points abstractly it boils down to:

• It is difficult/impossible to ensure 100% compatibility between an app and all themese
• Developers are being blamed when an app breaks
• The UI and experience breaks
• The consistency across the system UI may break (side note this is one of the reasons for libadwaita to be created)

And that is okay. Why is it okay? Should Linux not be a system where you can play and do what ever the hell you want? Well it still we can just use another desktop environment (DE) or windows manager. We can still play around with what we want. We just should not expect developers of our apps or DE’s to adapt to us accordingly because if they had to do that for all users, the development process would be hell. But this is actually not why I agree with Gnomes perspective. So let me go into a little more detail on why I agree with it.

If we look at macOS, there is one design, one style to follow, if you design apps in swiftUI or earlier versions of Apples development environments. This gives all apps a somewhat familiar look and often menus are similar or at least close enough that you can guess where you are going. This combined with macOS over all strides towards a stream lined UI gives an overall complete system User Interface (UI) and User Experience (UX). This, combined with their ecosystem, gives Apple a very good edge to retain users, as they get comfortable. So why is this relevant? Well for a long time on Linux, there was no one design language, no unified UI and therefore no unified UX. Although this is both good and bad it can scare some people away from Linux, something I (at least) is not interested in. However back when Gnome went from version 2 to version 3, we so the dawn of a system that could provide this. Side note… if you want to read about how angry the gnome community actually can get go back and read about the swap from Gnome 2 to 3 flame wars everywhere! Gnome got a modern look, it felt more like macOS, a thing many hated, but it was pretty and shinny. Since then Gnome has morphed, not so much in design but rather philosophy. It has become a more unified attempt at providing a good UX for Linux right out of the box. Just look at how good Fedora with vanilla (unmodified) Gnome is out of the box! As this philosophy have evolved, big ideas have emerged and one of these are libadwaita. libadwaita gives you great building blocks to create GTK apps for Gnome, that look like Gnome Core Apps (some are still being updated). This is good, it provides a similar UX to what Apple provides and as both a macOS and Fedora/Gnome user this is very much appreciated as it gives some coherence. I do not mean because the two system look similar (although they do), but more that it feels like we have a healthy competition almost. That I cannot break it with theming is nice, that I do not have to is nice, that everything looks the same is nice and that is something I really appreciated. In particular after spouts of using XFCE (although it is an awesome DE) or some window manager like FluxBox over whatever I fancied a given day.

Another thing I would like to mention is that KDE with Plasma and in particular KDE Neon seems to be going in a similar direction. I am guessing this is in particular down to how QT are handling things at the moment or maybe I am just projecting. I do not see this as a bad thing for mainstream distros like Fedora, Ubuntu, and Mint to seem less daunting to newcomers, a thing I think we need. Finally, I hope COSMIC by system76 will provide something similar in terms of coherent UX as I expect they soon with Pop!_OS will have a mainstream distro.

./Lars

When you go online and look for reviews of peripherals for Macs you will most likely never see the Apples keyboard and Magic Mouse recommended, and maybe just maybe you will see the magic track pad be recommend. Why is this? Well, most reviewers say that the keyboard and mouse profiles are too low and therefore, it will hurt your wrists. Which is fair they are extremely low. And what about the Magic Track pad? Well I actually think most people like this one, but as most reviews are focused on mice it gets ignored. However, I actually do not think the keyboard and mouse is getting enough credit and in this post I will talk about why. I will also cover some improvements that I think all three products need.

Let us start with the improvements. One of the things I hear a lot as a negative comment about all three products is that they still require a lightning cable rather than a USB type C. I 100% agree with this, it is so stupid that Apple has not updated them to type C yet, when the iPad, macs and so on all use type-C. Therefore upgrading to this will be a big plus. However, I actually believe that for the magic mouse I have a better idea. Give it QI wireless charging capabilities. So why do I think this? Well a lot of people (myself included) thinks that the fact that apple put the charging port on the bottom of the mouse is idiotic, as you cannot charge it while using the mouse. My solution has always been to charge it over night or lunch when I saw the mouse was reaching very low energy levels. Yet I have missed the warning from time to time. Therefore, I would like the option to simply put the mouse on a QI charging pad while not using the mouse. For me this makes a lot of sense as I have some sessions where I barely touch the mouse for hours. Although I do understand why some people may still find that annoying as hell. And that was basically all the ideas I had for improvement…

Let us now move on to why I like them. First of Apple Macs track pads are legendary, there is nothing on the market NOTHING that compares in the Windows/Linux device world. NOTHING! and that is a hill I am willing to die on. I actually extend this to the external Magic Track pad. I have tried quite a few external track pads as using them over longer time helps me with RSI pains compared to using a (moving) mouse. Apples is by miles the best and I talk about both the old one with replaceable AA batteries and the new one with rechargeable batteries. I have also found that the reason I find it much more comfortable compared to other move mice is that well I get the same benefit as the trackball in a sense… No moving the damn mouse.

Next, and this is a two in one, the keyboard and magic mouse. I have used Apples peripherals for quite some time, I had the magic mouse, the mighty mouse, and the Apple Pro mouse that came before, and to be honest I have loved all of them. So why do I love them when others seem to hate them? Well, honestly I think it is because I am weird. What do I mean weird? What I mean is that I started noticing a pattern. When I look at colleagues, I seem them use the mouse and keyboard relatively (for me) close to the edge of table. When I say close I mean 10CM or so from the bottom end of the keyboard to the edge of table nearest the user. On the other hand I prefer to have the keyboard and mouse at a depth of 15 to 20CM, and then I have then I have the mouse matching this. The lower the profile of the keyboard the further in on the table I place it Funny enough this depth makes the Apple keyboard and mouse really comfortable for me. Also I actually noticed advertisement material where the keyboard and mouse is roughly in the position where I like it. I do not know if I just accidentally put them where Apple expects them to be placed.

But yeah so I like them!

./Lars

In the beginning there where three build systems we where trying to support for QueryC++. These where bare bones Make, waf.io with a custom extension written by Steinwurf ApS, and finally CMake.

In this update. I mentioned that we we are reducing the build systems to only CMake and to my surprise (lol not!) some people wrote me that the choice was stupid. Some argued the case for Make, waf, and xmake, the latter being a system I briefly had considered. Others argued the case for Bazel Most arguments were very valid and most where things I had considered, but CMake still won. A thing I will say here is that there where some very compelling arguments for Bazel I had not considered. Although these did not make me switch QueryC++ to Bazel, they have made it so it is a build system I will explore more (spoiler it has something to do with Go).

Now why did CMake win? Basically it boils down to widespread usage and ease of use. CMake is, if you dedicate like 24 hours to it, easy to use, both for defining and setting up you own project and also configuring external dependencies. FetchContent plays a big part here. Both in terms of handling external dependencies, but also the ease with which we can make QueryC++ available to others. Additionally the fact that CMake is available for (almost) all platforms means that we easy can provide it to a large audience. A very huge plus.

Another positive of CMake is that I have seen examples of projects depending on both waf and Bazel adopt an approach that could make CMake based dependencies available in these projects, with relatively low effort. Again speaking to the benefit of CMake and its wide spread usage.

So basically this is why it won. Now we may switch in the future who knows. Maybe Bazel proves a better build system. But for now we stick with it.

Support for using QueryC++ via FetchContent

AND WE OFF!!! I finally had time to spend some time understanding FetchContent and how to make a package available. So now QueryC++ can be used via FetchContent. We are really excited about this as previously people have been copying the files by hand. But that ends with QueryC++ 4.0!

For a small teaser you can test it with the small example below. First a very simple C++ program, note that the valid function will not be available in the final release of QueryC++ 4.0

#include <querycpp/querycpp.hpp>

#include <iostream>

int main(void) {

    std::cout << querycpp::valid() << "\n";
}

Followed by the CMakeLists.txt file.

cmake_minimum_required(VERSION 3.18)

project(test_querycpp VERSION 4.0.0 DESCRIPTION "Test QueryC++" LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_FLAGS "-Wall -Wextra -O3")

include(FetchContent)

FetchContent_Declare(
    querycpp
    GIT_REPOSITORY https://gitlab.com/looopTools/querycpp.git
    GIT_TAG querycpp_four
)

FetchContent_MakeAvailable(querycpp)

add_executable(t main.cpp)

target_include_directories(t PRIVATE querycpp fmt::fmt)
target_link_libraries(t querycpp fmt::fmt)

This can be compiled by the following series of command on Linux and macOS where CMake and clang++ or GCC++ is installed.

mkdir build
cd build 
cmake ..
make 

These steps will automatically download QueryC++ and make them available for your code using FetchContent.

If you are wondering why we reference fmtlib, it is because it is a dependency of QueryC++. At least it is until compilers start supporting format truly.

I CANNOT STRESS ENOUGH: QueryC++ 4 is not ready for production use and this only servers as an example.

./Lars

January is closing and I have some happy updates on QueryC++ 4.0, that I want to share.

In my last post I talked about how I wanted to be able to work on QueryC++ at least once a week. I have actually almost been able to keep on top of this. With one exception, which was rectified by working two days in a row the week after. The progress I make even during short sessions are good and I think it was the “spring cleaning” the project needed. I am getting this changes reviewed by a third-party and they seem to approve.

The only thing we are currently in disagreement about is my usage of && and || for and and or operations specifically. We are currently arguing what the best solution is for this. I will open up a discussion issue some time during February to get a broad perspective on this.

You will also find that the tests and build CI pipelines are now running as indented, which I am very pleased about. This now means that as long as I write tests, I will catch if I break something. A thing I am really happy about.

Next, concepts are a feature of C++20 I have eyed with some desire for quite a while and finally found a great application for it. You can find this in the column.hpp header. I am really exited about how well this integrates with the code and makes my life a lot easier. I implemented and tested it today and I am very happy with result.

Finally, documentation using mdbook. Although I have not had time to write so much documentation yet, it will be a priority during February, I have setup the mdbook part of the repo. I hope this will provide a super easy to use documentation for QueryC++ and I hope we can find a great way to keep it up to date.

I you want to follow along with the development you can check the QueryC++ 4.0 branch here.

./Lars