This is the Raspberry Pi 5 (hereafter just Pi5) that I’ve been working with since late 2024, with Ubuntu 24.04.1 LTS for the Pi5 installed. It’s been my ambition for some time to build a sophisticated robot around this type of platform (a Raspberry Pi running Linux), more so that what I’ve been tinkering with for some time. I had originally thought to use something based on the early nVidia Orin SBCs, but that fizzled in the late 2010s when I discovered the rough state of the software platform. I had begun to hear about Robot Operating System, or ROS, but did nothing substantive with it until very recently. I’ve now installed ROS 2 on my main system under Linux Mint 22.1 and on my Pi5. I wanted to be able to switch back and forth in case I ran into any issues on the Pi5, to see if the same issues were also on the Linux Mint system.

I also wanted to see if I could indeed install ROS on Linux Mint. ROS officially supports just a few Linux distributions, one of which is Ubuntu 24.04. Since Linux Mint is downstream from Ubuntu, meaning Linux Mint 22.1 is derived from Ubuntu 24.04.1, ROS theoretically should install without issue on my Linux Mint system. Sure enough, it did, and it appears to operate properly so far.

I have more tutorials to get through, and as I said above I’ve not run into any problems. Well, perhaps a little one, easily fixed. When you start rqt the first time, the services are not populated. Close rqt and then reopen it and the services will be properly populated. The tutorial instructions are more complicated than that, but I don’t think they’re necessary.

I’m hoping to reach a point where I can begin to integrate hardware into the software platform sometime in February, and later, a local LLM for autonomous control.

Links

ROS — Robot Operating System — https://www.ros.org/

It’s been several days since I stepped up to Linux Mint 22.1. No fuss, just a bit of exploring to tweak the desktop look to use the new Cinnamon styling. I was also pleased to be able to change the size of my menu and have it stick, once set. I’m still using the Papirus icon theme and Nerd Fonts for everything. Linux Mint is still based on Ubuntu 24.04, which is fine as far as I’m concerned. All the software tools I use are reasonably current but not bleeding edge; for example Python on Linux Mint 22.1 is version 3.12.3, while the absolute bleeding edge is version 3.13.1. Even Python 3.12 is at 3.12.8, which tends to irk me as to why the distribution can’t at least keep up with its latest Python baseline. I suspect it’s due to Ubuntu itself.

I do much prefer this release over anything I could get from Microsoft. Everything in my house is either macOS or Linux, split about 50/50. I spend the majority of my time on a Linux system, which explains why I won’t purchase a new Apple computer in the future. I’m going to run everything I have until it literally dies and can’t be upgraded or fixed. For example, my primary Linux system is a Minis Forum UM250 with an AMD Ryzen 5 PRO 2500U CPU. That AMD CPU was launched in 2019. I got the UM250 system in 2020 with Windows 10 Pro preinstalled. It ran for about a year with Windows 10 until I started to get indications that Microsoft wanted to upgrade to Windows 11, but wouldn’t allow the UM250 to upgrade because the little system didn’t have TPM 2.0 installed. It was at that point I purchased a new SSD for the system, swapped it in, and switched to Linux.

My transition to Linux Mint wasn’t straightforward. I tried Pop!_OS and Fedora before finally settling on Linux Mint. The biggest annoyance with both was their insistance of installing and activating brltty, a special Braille driver for the blind. I can certainly appreciate making computers available to the visually challenged, but I’m not one of those (yet), and there wasn’t any way to easily disable the feature for regular use. The brltty driver interfered with my ability to use my USB ports for embedded (IoT) development. I was able to uninstall it for Fedora, but Pop!_OS had it so deeply embedded in the OS that any attempt to remove it would cripple the desktop. In the end for Pop!_OS I had to use systemd to disable the service. Considering how much aggravation I went through for that one problem, I was quick to switch away to Linux Mint, and that’s where I’ve lived ever since.

I have a solid computer with a no-drama operating system that reliably does its job, day-in and day-out. I don’t want or need anything more than that.

I’ve spent yesterday evening and today performing a clean installation of Linux Mint 22 and then moving my content over to it. I’ve been grumbling about abandoning Mint because of its atrocious update tool. I’d spoken about moving back to either Fedora (41) or Ubuntu (24.10). So I swapped a blank SSD into my system, downloaded an ISO of each distribution and installed them one by one onto my system to give them both a quick spin. They’re both excellent, but my personal preferences are still towards Linux Mint, regardless of its flaws. In the end I installed Mint 22 and I’ve been tuning it to my liking since late this morning.

Performing a clean install of any operating system allows you to start a-fresh with just the applications and setup you want. By the time I’d reached a point of operational parity with my older Mint installation, my SSD usage with Mint 22 was 10%, compared to 30% with Mint 21.3. And that Mint 22 usage includes all the tool and development folders I copied over from the older Mint system to new system. I don’t know where all the extra cruft came from on the older Mint 21 installation, except perhaps the applications I installed over the years left behind a lot of cache and configuration data when the application was uninstalled.

The newly installed system is performing much better than before. The desktop is snappier and it appears that running tasks finish faster as well. Desktop graphics, especially text, is clearer and cleaner. This is due in no small part to being based on Ubuntu 24.04 LTS and advances in the Cinnamon desktop, although the absolute latest Cinnamon desktop won’t show up until Mint 22.1 officially arrives with Cinnamon 6.4 in tow. It will be interesting to see if the next Mint release updates without any issues on my newish Mint system.

I’ve indulged myself with a new keyboard, the Cooler Master MK770 mechanical keyboard in shades of gray and black. It seems this keyboard has attracted quite a bit of on-line positive coverage. What finally sold me to make the purchase is that it’s a Black Friday sale item for $71. I figured for that price I could give it a try, and if I didn’t like it I could return it.

I ordered on Saturday and it was delivered by Sunday. I’ve spent the last few days learning how to use it and how to ‘program’ the back light colors. I must say I greatly appreciate the feel of the mechanical keys. I also appreciate how heavy and solid the keyboard is. I haven’t felt this kind of keyboard since the late 1970s and early 1980s. That’s when I used IBM keyboards in the IBM ‘moosehead’ terminals at the First National Bank of Atlanta, and the nearly identical keyboards on the original IBM PC and IBM XT personal computers. I’d forgotten how nice such keys were for long periods of typing.

So far I’ve managed to configure the colors using keyboard chording with the function key (the key at the bottom with the Cooler Master logo on it) and other regular keys. It’s a nice light green color.

I’m still getting used to how the arrow keys are positioned on the keyboard. I keep sending the cursor off in unintended directions.

One excellent feature of this keyboard is how it helps and enhances my touch typing. I thought I’d forgotten how, but within an hour of setting up the keyboard I’ve been touch typing like a maniac.

Finally, I’m using the USB-C cable to connect to my Linux system. The cable isn’t all that intrusive.

I never thought I’d get excited over a keyboard, but I am about the MK770. Highly recommended.

I’ve reached a point where the central part of the USB Device Monitor, which contains the device table at top and the console at the bottom, has evolved into its own class. It started out as a class function of the primary class, MainWindow. But it quickly became evident I needed to better organize specific functionality into its own compilation unit. The best way to do that was with a unique class that encapsulated the data and structures unique to both the table and console. That’s the reason I like C++ and other object-oriented languages; encapsulation. Not inheritance, encapsulation.

Here is the unique header for CentralWidget:

#pragma once#include <QSplitter>#include <QWidget>#include <QString>#include <QStringList>#include <QHeaderView>#include <QTableWidget>#include <QTableWidgetItem>#include <QTextEdit>#include <QPlainTextEdit>#include <QSettings>#include <QPalette>#include <QSerialPort>#include <QByteArray>#include <QScrollBar>#include <QFont>class CentralWidget : public QSplitter {public:const QString CWIDGET_STATE{"cwidget/state"};explicit CentralWidget(QWidget *parent);void saveCWState(QSettings &settings);void restoreCWState(QSettings &settings);private:QTextEdit *console;QSerialPort *serialPort;QTableWidget *table;void readSerialData();void openUSBPort(QTableWidgetItem *);void closeUSBPort();};

And the implementation, with some beginning comments:

#include "CentralWidget.hpp"#include "devices.hpp"CentralWidget::CentralWidget(QWidget *parent) :QSplitter(parent),console(new QTextEdit),serialPort(new QSerialPort),table(new QTableWidget) {setOrientation(Qt::Vertical);// Configure the console onto which we will communicate with a given// USB device.//QPalette colors = palette();colors.setColor(QPalette::Base, Qt::black);colors.setColor(QPalette::Text, Qt::white);QFont font("Monospace", 12);font.setStyleStrategy(QFont::PreferAntialias);console->setPalette(colors);console->setFont(font);console->setCursorWidth(8);// Connect the console with the serial port so that any data that is// recieved by the serial port will be displayed on the console.//connect(serialPort, &QSerialPort::readyRead, this,&CentralWidget::readSerialData);// Find all the USB devices connected to our system. Put their data in a// spreadsheet-like table.//auto devices = getDevices();table->setRowCount(devices.size());QStringList headers = {"Device", "Adapter Name", "Hex Identification"};table->setColumnCount(headers.size());table->setHorizontalHeaderLabels(headers);table->horizontalHeader()->setStretchLastSection(true);int row{0};// Populate the table with eacj USB device, one row/devices.//for (auto [device, values] : devices) {QString dev(device.c_str());QString v1(values[0].c_str());QString v2(values[1].c_str());table->setItem(row, 0, new QTableWidgetItem(dev));table->setItem(row, 1, new QTableWidgetItem(v1));table->setItem(row, 2, new QTableWidgetItem(v2));++row;}table->resizeColumnsToContents();// Connect the table with the class function so that when a user// clicks on a port in the table, that port will be opened and// communicating with the console.//connect(table, &QTableWidget::itemClicked, this,&CentralWidget::openUSBPort);// Finish construction by putting the table at the top and the// console beneath it.//addWidget(table);addWidget(console);}void CentralWidget::readSerialData() {QByteArray data = serialPort->readAll();console->insertPlainText(data);QScrollBar *scrollBar = console->verticalScrollBar();scrollBar->setValue(scrollBar->maximum());}void CentralWidget::openUSBPort(QTableWidgetItem *cell) {if (cell->column() == 0) {closeUSBPort();QString portName = "/dev/" + cell->text();console->insertPlainText(QString("\nPort open: %1\n").arg(portName));QScrollBar *scrollBar = console->verticalScrollBar();scrollBar->setValue(scrollBar->maximum());serialPort->setPortName(portName);serialPort->setBaudRate(QSerialPort::Baud115200);serialPort->setDataBits(QSerialPort::Data8);serialPort->setParity(QSerialPort::NoParity);serialPort->open(QIODevice::ReadOnly);serialPort->clear(QSerialPort::AllDirections);}}void CentralWidget::closeUSBPort() {if (serialPort->isOpen()) {serialPort->clear();serialPort->close();}}void CentralWidget::saveCWState(QSettings &settings) {settings.setValue(CWIDGET_STATE, saveState());}void CentralWidget::restoreCWState(QSettings &settings) {if(settings.contains(CWIDGET_STATE)) {restoreState(settings.value(CWIDGET_STATE).toByteArray());}}

The key features of the new class are:

• The table is built based on the number of entries found by getDevices(), and the data now fits into the table accordingly. The code was reorganized so that the devices are found before the table is filled with the resultant data.
• The table cell click event is now connected to openUSBPort(), so that clicking on a cell that contains a port will close any port that may be open, then open the new port clicked on.
• The class handles saving and restoring its own internal state, instead of having MainWindow do it, via saveCWState() and restoreCWState().

Now when you start the application, it just sits there not displaying any information. When you click on a port, such as ttyACM0, then that port is opened and any data being sent from the device connected to that port is displayed on the console. The screen capture leading this post shows how this works now. The ttyACM0 was clicked, and then the port was opened.

The biggest problem right now is that if an text is displayed on the console that contains ANSI escape sequences, they are not interpreted and instead are just printed as raw data. I’m going to have to either find a Qt class that can interpret those sequences and display the text accordingly (usually colors), or else write my own. What I may wind up doing is stripping that ANSI data before writing to a log file.

Another chunk of future work is to put functional controls on the dock panel. I have some ideas what I want.

Once I get those tasks out of the way, I will probably release this as an open tool for others to use. As I’ve written before, more to come…

Links

building a qt 6.2 application — beginning usb comms

My Qt 6 application isn’t simple any more. It’s grown more complicated as I continue to add features and evolve it towards what I finally want. In this post I’m adding very basic serial communications via USB to my attached development boards. For this post I’m only communicating with the Raspberry Pi Pico W. I’ll be using QSerialPort to develop that functionality. I’ll show what additional source and libraries I had to install, the core modified code, and the application I had running on the Pico W to produce test output.

First things first. I had to install the headers and library files to support developing with Qt’s QSerialPort. Those extra packages are libqt6serialport6 and libqt6serialport6-dev. This will put the necessary header files down /usr/include/x86_64-linux-gnu/qt6/QtSerialPort/. You’ll also need to link against Qt6SerialPort.

Here’s the modified code module. I’ll highlight the pertinent sections after the code block.

#include <QStringList>#include <QHeaderView>#include <QTableWidgetItem>#include <QSplitter>#include <QPalette>#include <QSerialPort>#include <QByteArray>#include <QScrollBar>#include <QFont>#include "MainWindow.hpp"#include "devices.hpp"void MainWindow::addCentralWidget() {console = new QPlainTextEdit(this);QPalette colors = palette();colors.setColor(QPalette::Base, Qt::black);colors.setColor(QPalette::Text, Qt::white);QFont font("Monospace", 12);font.setStyleStrategy(QFont::PreferAntialias);console->setPalette(colors);console->setFont(font);serialPort = new QSerialPort(this);connect(serialPort, &QSerialPort::readyRead, this, &MainWindow::readSerialData);serialPort->setPortName("/dev/ttyACM0");serialPort->setBaudRate(QSerialPort::Baud115200);serialPort->setDataBits(QSerialPort::Data8);serialPort->setParity(QSerialPort::NoParity);serialPort->open(QIODevice::ReadOnly);table = new QTableWidget(this);table->setColumnCount(3);table->setRowCount(6);QStringList headers = {"Device", "Adapter Name", "Hex Identification"};table->setHorizontalHeaderLabels(headers);table->horizontalHeader()->setStretchLastSection(true);int row{0};for (auto [device, values] : getDevices()) {QString dev(device.c_str());QString v1(values[0].c_str());QString v2(values[1].c_str());table->setItem(row, 0, new QTableWidgetItem(dev));table->setItem(row, 1, new QTableWidgetItem(v1));table->setItem(row, 2, new QTableWidgetItem(v2));++row;}table->resizeColumnsToContents();QSplitter *splitter = new QSplitter(Qt::Vertical, this);splitter->addWidget(table);splitter->addWidget(console);setCentralWidget(splitter);}void MainWindow::readSerialData() {QByteArray data = serialPort->readAll();console->insertPlainText(data);QScrollBar *scrollBar = console->verticalScrollBar();scrollBar->setValue(scrollBar->maximum());}

The text box is being used again as a console. Starting at line 15, we set up the foreground and background colors and the font we want to see any text in. This gives us a console with white text on a black background, with a 12pt Monospaced font using anti-aliasing. The default font is horrible.

Lines 24 through 27 are critical to this working. While Qt calls the ability to handle callbacks as signals (the call) and slots (the callback), this is their nomenclature for a feature as old as C, which is the ability to call pointers to functions. This was a feature in the Unix widget toolkit, Motif, in which controls had the ability to be programatically configured with pointers to functions that were called when a given control was activated. Line 26 sets up the callback (MainWindow::readSerialData) to be called by the serialPort when any data is present. The callback reads that data and places it to be displayed on the console. This is all done asynchronously such that the GUI event queue isn’t blocked. This is very similar to what Java tries to do with its GUI toolkits. The callback is in lines 61-66. When the application is running, it will open the port to the Pico W and then begin to read the data that the Pico W sends out.

These are early days for this. I only wrote enough to get the callback going and to read from the port. You’ll note that the port is hard coded for the Pico W. In the future I’ll be able to pick any port just by clicking on the entry in the upper table and the console will be fully bi-directional. I’m also going to add the ability to log everything in the console. As a stretch goal I’d like to be able to edit Micropython source in the attached microcontroller as well. But that’s a stretch goal which is going to require almost as much work as all the work leading up to finishing the first three goals.

Now for the interesting part. The Pico W is running Circuit Python 8 beta 6.

# SPDX-FileCopyrightText: 2022 Liz Clark for Adafruit Industries## SPDX-License-Identifier: MITimport osimport timeimport sslimport wifiimport socketpoolimport microcontrollerimport adafruit_requestsimport jsonimport gc# Adafruit quotes URL#quotes_url = "https://www.adafruit.com/api/quotes.php"# Connect to your local hostspot.# WIFI_SSID and WIFI_PASSWORD should be defined in your settings.toml# file.#wifi.radio.connect(os.getenv('WIFI_SSID'), os.getenv('WIFI_PASSWORD'))pool = socketpool.SocketPool(wifi.radio)session = adafruit_requests.Session(pool, ssl.create_default_context())print("Fetching quotes from ", quotes_url)print()while True:try:time.sleep(5)gc.collect()# Get a quote.#response = session.get(quotes_url)dic = dict(json.loads(response.text)[0])qstr = dic['text'] + "."print("   " + qstr)print(".. " + dic['author'])print("")response.close()gc.collect()# pylint: disable=broad-exceptexcept ValueError as e:print("Error: bad JSON")response.close()except Exception as e:print("Error:\n", str(e))print("Resetting microcontroller in 10 seconds")time.sleep(10)microcontroller.reset()

The original code came from Adafruit. I cleaned up the while loop to make the output more readable. The original code just spat out the JSON strings that came back from the URL. I’ve done some formatting and cleanup instead.

That’s it for the time being. I’ll continue to clean up the C++ code. Hopefully I’ll have more progress to post by the weekend.

My Qt 6.2 application continues to evolve. I’ve now named it USB Device Monitor, or udm. It has a dock that can be switched to either left or right side and a table in the center with specific Linux information replacing the text editing widget I had before. All of this is building on from the basic plumbing entry and my earlier utility to read Linux USB devices (see links below).

Comments will be shorter than usual, with code more than commentary.

cmake_minimum_required (VERSION 3.25.0)## Build requirements#include_directories( /usr/include/x86_64-linux-gnu/qt6/ /usr/include/x86_64-linux-gnu/qt6/QtCore/ /usr/include/x86_64-linux-gnu/qt6/QtGui/ /usr/include/x86_64-linux-gnu/qt6/QtWidgets/ )link_libraries( Qt6Core Qt6Widgets Qt6Gui )add_compile_options( -fPIC -std=c++20 )## Project specific#project (usb-device-monitor)add_executable (udmmain.cppMainWindow.cppAddCentralWidget.cppAddWindowFileMenu.cppAddDockingPanel.cppdevices.cpp)

The last third of the CMake file shows that MainWindow is a rename of AppWindow, and three new files have been added, AddCentralWidget, AddDockingPanel and devices.

#pragma once#include <QApplication>#include <QMainWindow>#include <QMenuBar>#include <QPlainTextEdit>#include <QSettings>#include <QString>#include <QDockWidget>#include <QCheckBox>#include <QComboBox>#include <QTableWidget>class AppWindow : public QMainWindow {public:const QString SCOPE_NAME{"Qt6BasedSoftware"};const QString APP_NAME{"USBDeviceMonitor"};const QString APP_GEOMETRY{"app/geometry"};const QString APP_STATE{"app/state"};const int INITIAL_WIDTH{900};const int INITIAL_HEIGHT{600};AppWindow();private:QTableWidget *table;QPlainTextEdit *textEdit;void addCentralWidget();void createFileMenu();QMenu *fileMenu;QAction *newAction;QAction *openAction;QAction *saveAction;QAction *saveAsAction;QAction *aboutAction;QAction *exitAction;void addDockingPanel();QDockWidget *dock;QCheckBox*cb1,*cb1x,*cb2,*cb2x,*cb3,*cb3x,*cb4,*cb4x;QComboBox *comboBox;void closeEvent(QCloseEvent*);};

#include <QScreen>#include <QSize>#include <QStatusBar>#include "MainWindow.hpp"AppWindow::AppWindow() {QCoreApplication::setOrganizationName(SCOPE_NAME);QCoreApplication::setApplicationName(APP_NAME);setWindowTitle(APP_NAME);addCentralWidget();createFileMenu();addDockingPanel();statusBar()->showMessage(tr("Statusbar Placeholder"));QSettings settings(QCoreApplication::organizationName(),QCoreApplication::applicationName());if (settings.contains(APP_GEOMETRY) and settings.contains(APP_STATE)) {restoreGeometry(settings.value(APP_GEOMETRY).toByteArray());restoreState(settings.value(APP_STATE).toByteArray());cb1->setChecked(settings.value("dock/cb1").toBool());cb2->setChecked(settings.value("dock/cb2").toBool());cb3->setChecked(settings.value("dock/cb3").toBool());cb4->setChecked(settings.value("dock/cb4").toBool());comboBox->setCurrentIndex(settings.value("dock/combo1").toInt());return;}QScreen *primaryScreen = QGuiApplication::primaryScreen();QSize screenSize = primaryScreen->availableSize();auto screenWidth  = screenSize.width();auto screenHeight = screenSize.height();auto upperLeftX  = (screenWidth - INITIAL_WIDTH)/2;auto upperLeftY = (screenHeight - INITIAL_HEIGHT)/2;setGeometry(upperLeftX, upperLeftY, INITIAL_WIDTH, INITIAL_HEIGHT);}void AppWindow::closeEvent(QCloseEvent *event) {QSettings settings(QCoreApplication::organizationName(),QCoreApplication::applicationName());settings.setValue(APP_GEOMETRY, saveGeometry());settings.setValue(APP_STATE, saveState());settings.setValue("dock/cb1",cb1->isChecked());settings.setValue("dock/cb2",cb2->isChecked());settings.setValue("dock/cb3",cb3->isChecked());settings.setValue("dock/cb4",cb4->isChecked());settings.setValue("dock/combo1", comboBox->currentIndex());QMainWindow::closeEvent(event);}

The biggest changes in MainWindow besides the renaming is in the constructor and closeEvent. The constructor now calls external class functions to build the subsystems used in the application, and then recalls saved state in order to put the application back the way it was when it was closed the time before. I made a change to the conditional if block by removing the else and adding a return at the end of the if block. I’ve developed an aversion to cascading conditional statements and the “pyramid of doom” that they can create. I now organize my tests such that if I need to check for the health of the application then I’ll check that first and bail if there’s a problem, or as in this case, put the most common action that should occur nearly all the time, perform that task and then leave. The use of if/else blocks might look proper to purists, but I’m no longer a purist.

The closeEvent now does a bit of state saving. I didn’t mention it in the last post, but for Linux the save file is located in $HOME/.config/Qt6BasedSoftware/ USBDeviceMonitor.conf. That folder and file are defined in SCOPE_NAME and APP_NAME, respectively, in MainWindow.hpp, lines 16 and 17.

#include <QStringList>#include <QHeaderView>#include <QTableWidgetItem>#include "MainWindow.hpp"#include "devices.hpp"void AppWindow::addCentralWidget() {table = new QTableWidget(this);table->setColumnCount(3);table->setRowCount(6);QStringList headers = {"Device", "Adapter Name", "Hex Identification"};table->setHorizontalHeaderLabels(headers);table->horizontalHeader()->setStretchLastSection(true);int row{0};for (auto [device, values] : getDevices()) {QString dev(device.c_str());QString v1(values[0].c_str());QString v2(values[1].c_str());table->setItem(row, 0, new QTableWidgetItem(dev));table->setItem(row, 1, new QTableWidgetItem(v1));table->setItem(row, 2, new QTableWidgetItem(v2));++row;}table->resizeColumnsToContents();setCentralWidget(table);}

The class function addCentralWidget creates a three column by six row table, looking pretty much like a spreadsheet, to contain the data that the class function getDevices finds in the Linux operating system. The first half of this function sets up the table while the second half formats the data returned by the call to getDevices. This is the minimum code necessary to just display the data. No other functionality is enabled.

#pragma once#include <array>#include <map>#include <string>#include <iostream>typedef std::map<std::string, std::array<std::string,2>> device_collection;device_collection getDevices();

#include <algorithm>#include <filesystem>#include <regex>#include "devices.hpp"using std::array;using std::string;using std::pair;using std::regex;using std::regex_search;using std::replace;using std::smatch;using std::filesystem::directory_iterator;using std::filesystem::path;using std::filesystem::read_symlink;void split(const string &subj, const regex &rgx, array<string, 2> &vars) {smatch match;regex_search(subj, match, rgx);vars[0] = subj.substr(0, match.position(0));replace(vars[0].begin(), vars[0].end(), '_', ' ');vars[1] = match.str(0).erase(0,1);vars[1].erase(vars[1].end()-1);}device_collection getDevices() {const string DEVICE_PATH{"/dev/serial/by-id/"};const regex hregex{"_[0-9A-Fa-f]+-"};device_collection devices;for (const auto &entry : directory_iterator(DEVICE_PATH)) {if (entry.is_symlink()) {string slink = read_symlink(entry).stem().generic_string();string sname = entry.path().stem().generic_string().erase(0,4);array<string, 2> results;split(sname, hregex, results);devices[slink] = results;}}return devices;}

This is the utility I wrote about a week back where I was trying to write the same utility in Python, C++, and Rust. The original C++ utility was stand-alone. I removed the main and the printout, and just converted it into a function that returned a collection of the processed data to be displayed in the QTableWidget.

#include <QGroupBox>#include <QVBoxLayout>#include <QDockWidget>#include <QGridLayout>#include "MainWindow.hpp"void AppWindow::addDockingPanel() {dock = new QDockWidget(tr("Docking Panel"), this, Qt::Widget);dock->setObjectName(tr("Docking_Panel"));dock->setFeatures(QDockWidget::DockWidgetMovable);dock->setAllowedAreas(Qt::LeftDockWidgetArea | Qt::RightDockWidgetArea);addDockWidget(Qt::LeftDockWidgetArea, dock);QWidget *mainWidget = new QWidget;QGridLayout *grid = new QGridLayout;mainWidget->setLayout(grid);QGroupBox *checkboxSelection = new QGroupBox(tr("Non-exclusive Checkboxes"));QVBoxLayout *cslayout = new QVBoxLayout;cb1 = new QCheckBox(tr("One"), this);cslayout->addWidget(cb1, 0, Qt::AlignLeft);cb2 = new QCheckBox(tr("Two"), this);cslayout->addWidget(cb2, 1, Qt::AlignLeft);cb3 = new QCheckBox(tr("Three"), this);cslayout->addWidget(cb3, 2, Qt::AlignLeft);cb4 = new QCheckBox(tr("Four"), this);cslayout->addWidget(cb4, 3, Qt::AlignLeft);checkboxSelection->setLayout(cslayout);grid->addWidget(checkboxSelection, 0, 0);QGroupBox *groupBox = new QGroupBox(tr("Dropdown"), dock);QVBoxLayout *layout = new QVBoxLayout();comboBox = new QComboBox();comboBox->addItem(tr("One"));comboBox->addItem(tr("Two"));comboBox->addItem(tr("Three"));comboBox->addItem(tr("Four"));layout->addWidget(comboBox);groupBox->setLayout(layout);grid->addWidget(groupBox, 1, 0);QWidget *filler = new QWidget;QVBoxLayout *flayout = new QVBoxLayout;flayout->addSpacerItem(new QSpacerItem(20, 800, QSizePolicy::Minimum,QSizePolicy::Expanding));filler->setLayout(flayout);grid->addWidget(filler);dock->setWidget(mainWidget);}

This creates a dockable panel that can be moved either to the right or the left of the main application. It does nothing but display a few controls. QDockWidget has changed a bit since Qt 4. In particular, I had to create a single widget to set within the QDockWidget instance; that’s what mainWidget is for. I also had to create a special widget to encapsulate the QSpacerItem in order for all the other widgets to line up properly and not waste space on the dock.

The class function createFileMenu hasn’t changed.

Not much to say at this point except that now I need to decide what real functionality I want to enable in this monitor, and then add controls that actually do something. A bit more state is going to have to be preserved. The utility is going to have to monitor the USB devices to indicate when devices are added or removed. And I’m going to want to add a column to each row to hold additional user added information (text). So a bit more work to do.

Links

building a simple qt 6 application — basic plumbing

python vs c++ vs rust — a personal adventure

The first change has been to the CMake file, CMakeLists.txt.

cmake_minimum_required (VERSION 3.25.0)## Build requirements#include_directories( /usr/include/x86_64-linux-gnu/qt6/ /usr/include/x86_64-linux-gnu/qt6/QtCore/ /usr/include/x86_64-linux-gnu/qt6/QtGui/ /usr/include/x86_64-linux-gnu/qt6/QtWidgets/ )link_libraries( Qt6Core Qt6Widgets Qt6Gui )add_compile_options( -fPIC -std=c++20 )## Project specific#project (control-app)add_executable (control-appmain.cppAppWindow.cppAppWindowFileMenu.cpp)

The first change is the addition of two more include directories on lines 6 and 7. The add_executable CMake call now has three source files instead of the original one.

The next big change was to break up the original single source file into three. The original source file was renamed main.cpp, and the source that defined the AppWindow functionality was put into two files, one for the main part of AppWindow and the other for just creating the File menu structure. Let’s go in the file order of CMakeLists.txt.

The first file is main.cpp.

#include "AppWindow.hpp"int main(int argc, char **argv) {QApplication app (argc, argv);AppWindow window;window.show();return app.exec();}

This file is what is left of the original simple-app.cpp, stripped of everything not needed and renamed. The only functionality required of main is to instantiate AppWindow and then kick everything off with window.show().

#pragma once#include <QApplication>#include <QMainWindow>#include <QMenuBar>#include <QPlainTextEdit>#include <QSettings>#include <QString>class AppWindow : public QMainWindow {public:const QString SCOPE_NAME{"Qt6BasedSoftware"};const QString APP_NAME{"ControlApp"};const QString APPWIN_GEOMETRY{"AppWindow/geometry"};const QString APPWIN_STATE{"AppWindow/state"};const int INITIAL_WIDTH{800};const int INITIAL_HEIGHT{600};AppWindow();private:QSettings *settings;QPlainTextEdit *textEdit;void createFileMenu();QMenu *fileMenu;QAction *newAction;QAction *openAction;QAction *saveAction;QAction *saveAsAction;QAction *aboutAction;QAction *exitAction;void closeEvent(QCloseEvent*);};

If you compare this header file with the AppWindow class definition in simple-app.cpp, you’ll notice that the header file alone is longer than the original simple-app.cpp. At this point there aren’t all that many class functions; there’s the public constructor and then the private function createFileMenu which can only be called internally to the class, specifically from the constructor. The majority of the header file so far is primarily data structures, although I expect that will change as this application continues to evolve.

#include <QScreen>#include <QSize>#include <QStatusBar>#include <iostream>#include "AppWindow.hpp"AppWindow::AppWindow() {QCoreApplication::setOrganizationName(SCOPE_NAME);QCoreApplication::setApplicationName(APP_NAME);settings = new QSettings(SCOPE_NAME, APP_NAME);textEdit = new QPlainTextEdit;setCentralWidget(textEdit);createFileMenu();setWindowTitle(APP_NAME);statusBar()->showMessage(tr("Statusbar Placeholder"));if (settings->contains(APPWIN_GEOMETRY) and settings->contains(APPWIN_STATE)) {std::cout << APP_NAME.toStdString() << ": found full state\n";restoreGeometry(settings->value(APPWIN_GEOMETRY).toByteArray());restoreState(settings->value(APPWIN_STATE).toByteArray());}else {std::cout << APP_NAME.toStdString() << ": did not find full state\n";QScreen *primaryScreen = QGuiApplication::primaryScreen();QSize screenSize = primaryScreen->availableSize();auto screenWidth  = screenSize.width();auto screenHeight = screenSize.height();auto upperLeftX  = (screenWidth - INITIAL_WIDTH)/2;auto upperLeftY = (screenHeight - INITIAL_HEIGHT)/2;setGeometry(upperLeftX, upperLeftY, INITIAL_WIDTH, INITIAL_HEIGHT);}}void AppWindow::closeEvent(QCloseEvent *event) {std::cout << APP_NAME.toStdString() << ": close event\n";settings->setValue(APPWIN_GEOMETRY, saveGeometry());settings->setValue(APPWIN_STATE, saveState());QMainWindow::closeEvent(event);}

This is the meat of the application so far. There are two key sections, the constructor and the definition of function closeEvent.

The constructor sets up the overall environment for QSettings so that the application can save, and then recall, its state when it starts up and shuts down respectively. I followed the directions on the QSettings documentation page ( https://doc.qt.io/qt-6.2/qsettings.html ). Inside the constructor, starting on line 19, I check to see if the application geometry and state are available from a prior run. If they are not, then I default to a width and a height and a location that places the application squarely in the middle of the screen. If the geometry and state are loaded, however, the application goes back to the state that was last saved. Note that, on 13, that a QPlainTextEdit widget is set as the center widget for AppWindow. This is because Qt states that simply showing an empty QMainWindow isn’t supported (well, they won’t guarantee it works), so I added this widget just to fill the slot. In fact lines 13 through 16 are basically enabling the application (center widget, menu, window title and status line).

In order to make sure that the geometry and state or saved, I’ve redefined QMainWindow::closeEvent() such that everything is saved. After saving the call to QMainWindow::closeEvent() is chained to make sure that the Qt application closes properly.

#include "AppWindow.hpp"void AppWindow::createFileMenu() {fileMenu = menuBar()->addMenu(tr("&File"));newAction = new QAction(tr("&New"), this);fileMenu->addAction(newAction);openAction = new QAction(tr("&Open"), this);fileMenu->addAction(openAction);saveAction = new QAction(tr("&Save"), this);fileMenu->addAction(saveAction);saveAsAction = new QAction(tr("Save as"), this);fileMenu->addAction(saveAsAction);fileMenu->addSeparator();aboutAction = new QAction(tr("&About Qt"), this);connect(aboutAction, &QAction::triggered, qApp, &QApplication::aboutQt);fileMenu->addAction(aboutAction);fileMenu->addSeparator();exitAction = new QAction(tr("E&xit"), this);exitAction->setShortcuts(QKeySequence::Quit);connect(exitAction, &QAction::triggered, this, &QWidget::close);fileMenu->addAction(exitAction);}

The class function that builds the File menu is in its own compilation unit. I did this to keep any one source file from growing too large. I believe in fine granularity. As more menus are needed, and defined, they’ll go into their own files. Additional functionality will also go into their own unique files.

More to come…

Links

building a simple qt 6 application with cmake and make

As I wrote earlier I’ve switched back to Visual Studio Code on my Linux Mint 21.1 system for C++ development. In order to support Qt 6 C++ development, I needed to modify the C++ plugin’s include path to point to specific Qt 6 include files. The easiest way to do this is (and this assumes you have the Microsoft C/C++ extension installed to begin with):

1. Select Extensions in Visual Studio Code on the far left.
2. On the C/C++ Extension left-click the gear.
3. On the menu that appears, select Extension Settings.
4. In the Settings screen that opens, scroll down to C_Cpp > Default: Include Path.
5. Click the blue Add Item button.
6. In the input text box that appears, type in the full path to the Qt include files. Note in my example I have two paths to the Qt 6 include files.

Once you’ve updated the include paths just close the Settings tab. If you don’t have those additional paths in the Microsoft C/C++ plugin, then any and all Qt include files will have the dreaded Red Squiggly Lines underlining all those include files it can’t find.

I’ve been working on C++ applications, especially those that use C++17 and C++20 standards features. My approach is to start small and simple and then build up from there. For this example I decided to bring my ancient Qt skills up to date with Qt 6. The last time I wrote any serious Qt applications in native C++ was back around 2006/2007, and that was using Qt 4.

I also wanted to incorporate other tools I’ve been learning how to use, specifically CMake. CMake ( https://cmake.org ) is a powerful build tool that can help create a cross-platform configuration and build tool. I’ve been using with it with Espressif’s ESP-IDF framework. Because of this, CMake’s use has started to “leak” over into other C++ applications I’ve been working on. Then very recently I decided to pick up developing Qt applications for Linux, and I decided to use CMake to help build them from the get-go.

This application, which I’ve called simple-app, is a bare-bones skeleton that will create a bare window on the desktop and a single drop-down menu with just two entries. You can see a screen capture of it leading this post.

In order to develop with Qt 6, I installed Linux Mint’s Qt 6 package with sudo apt install qt6-base-dev. This installs Qt 6.2.4, the long-term support or LTS version that the KDE desktop uses. I could have gone with a more recent release, such as 6.4, but that would have caused too much friction trying to distribute it to others to use. Going with the version in the repos makes building and distributing it so much easier. And I don’t have to go hunt down all the odd build dependencies that Qt needs to build.

Once you install Qt, you need to install cmake if you don’t have it on your system already. You can either install it via apt, or you can do like I did and download the latest pre-built binary from the CMake website and use it locally in your home directory.

With cmake installed, it’s time to create a build folder and put the necessary files into it. The first file we’ll look at is CMakeLists.txt.

cmake_minimum_required (VERSION 3.25.0)## Build requirements#include_directories( /usr/include/x86_64-linux-gnu/qt6/ /usr/include/x86_64-linux-gnu/qt6/QtWidgets/ )link_libraries( Qt6Core Qt6Widgets Qt6Gui )add_compile_options( -fPIC -std=c++20 )## Project specific#project (simple-app)add_executable (simple-app simple-app.cpp)

These are the bare CMake essentials necessary to create a make file that will build the application.

• Line 1 is the cmake minimum version this will work with. If you have an older version of cmake then change this to match it. It should work with older versions, but I can’t guarantee that.
• Lines 5 and 6 set up the include paths necessary to find the Qt C++ include files. These are the paths created from the installation of qt6-base-dev.
• Line 7 lists the specific link libraries necessary for the application.
• Line 8 are specific C++ compiler flags. The -fPIC flag is required by the Qt libraries. The -std=c++20 is required to make sure the code is being compiled to the C++20 standard.
• Line 12 is the project name. It is actually compiled into the title of the window, which is rather nice.
• Line 13 associates the application with the source file.

Again, these are the absolute minimum CMake statements.

Here’s the C++ source file.

#include <QApplication>#include <QMainWindow>#include <QMenuBar>class AppWindow : public QMainWindow {public:AppWindow() {createFileMenu();resize(800, 600);}private:QMenu *fileMenu;QAction *aboutAction;QAction *exitAction;void createFileMenu() {fileMenu = menuBar()->addMenu(tr("&File"));aboutAction = new QAction(tr("&About"), this);connect(aboutAction, &QAction::triggered, qApp, &QApplication::aboutQt);fileMenu->addAction(aboutAction);fileMenu->addSeparator();exitAction = new QAction(tr("E&xit"), this);exitAction->setShortcuts(QKeySequence::Quit);connect(exitAction, &QAction::triggered, this, &QWidget::close);fileMenu->addAction(exitAction);}};int main(int argc, char **argv) {QApplication app (argc, argv);AppWindow window;window.show();return app.exec();}

This application is about as minimal as possible, at least for me. I wanted a bare window and a single simple drop-down menu, and this produces that. Here’s a basic source breakdown.

• main() has as little as possible. It instantiates QApplication and AppWindow. It then shows the window (AppWindow), meaning the window created through QMainWindow, and then it starts the entire application execution. That’s it, and frankly, that’s really all that should be there.
• The public AppWindow is derived from QMainWindow. This appears to be the recommended way to get a window up on a screen. All the other window features are created and then added to QMainWindow.
• The public constructor, AppWindow::AppWindow, does very little itself. It calls a private function to create the file menu, and then sets the size in pixels (width = 800, height = 600).
• The other function of note is of course createFileMenu. It shows, in order, how all the elements in the File menu are created. In the past I would create private functions for each menu on the menu bar. It makes it a lot easier to add, modify, or disable menus.

Here are the instructions to build the application. I’m assuming at this point you’ve got Qt 6 installed along with cmake.

1. Create a folder somewhere in your home directory. For the purposes of this post I’ll give it the same name as the application, or simple-app.
2. Step into the folder and copy CMakeLists.txt and simple-app.cpp into it.
3. Run cmake: cmake -B build. This will create a folder beneath your current location, into which the makefile and all other support files are created.
4. Run make: make -C build. This will build the application, leaving the executable binary in the build folder.
5. Run the application: ./build/simple-app

You don’t have to create the build subdirectory, but if you don’t then cmake and make litter the work area with a lot of individual build byproduct files. I use the build subdirectory method so that if I check this into Git then my .gitignore file is very simple; all I have to do to have git ignore the build subdirectories is put in an entry for build.

Right now the only “real” working function is the About menu selection. It produces the following dialog when selected:

I want to see Qt’s About because it also includes the licensing terms, which I always check.

I wanted to share this because while it’s minimal, it’s still a useful starting point. I hope you find it useful as well.