Tomaz Canabrava Ramblings

Harmonicon v0.0.11, or, the harmonica I made up

2026-09-08T00:00:00+00:00

I tagged v0.0.11 last night. Or this morning. I’ve stopped keeping track of which side of midnight things happen on.

Most of what’s in this tag I already went on about on Monday, in the weekly update</a>: the harp swapping, the Guitar Pro files, the pitch detectors that turn out not to hear chords. Go read that one if you want the long version, and it is a long version, I checked. This is only about the four things that landed after I wrote it.

Four things. Well. Three things, because one of them was me deleting a line out of a TODO file, and I’m not going to make you read a paragraph about that.

The harmonica I made up</h2>
So there was this line in my TODO list, and it said my chromatic harmonica was modelled as reaching less of its range than a diatonic, which is backwards. Chromatics are the ones that get all the notes. That’s the deal with a chromatic. You press the little button on the side and you get the notes in between, that is the entire pitch of the instrument, that’s why it costs four times as much as the other one.
So I went in to fix it, expecting to add a missing technique somewhere, and what I found instead was that the layout in my code was not a chromatic harmonica. It was not a harmonica at all. It was a C major scale going up one note per hole. C D E F G A B C D E F G, straight up, like somebody had typed a scale into an array and gone to lunch, which, in fairness, is exactly what happened, and the somebody was me.
A real 12-hole chromatic is solo tuned. It goes C E G C, then D F A B, and that four hole group repeats up the instrument for three octaves. That repeating is the whole point of it. That’s what makes one fingering work in every octave, that’s the thing you’re buying. Mine repeated nothing. Mine also stopped at A5 instead of C7, so fourteen of the thirty seven semitones between C4 and C7 weren’t reachable at all, on an instrument whose one job is reaching all of them.
Fourteen out of thirty seven. On the chromatic. The one that gets all the notes.
Nobody noticed, and here’s the bad part</h2>
Now you’d think somebody would have noticed, and here is why nobody did, and it’s the part that actually bothers me.
Both of the chromatic charts I ship had the made up layout copied into them. Both of them. So they agreed with the code perfectly, and the code agreed with them, and everybody in there was consistent and confident and describing an instrument nobody owns.
One of those two charts, and I want you to appreciate this with me, one of those two charts is the lesson that teaches you the chromatic slide.
So if you had gone out and bought a real chromatic harmonica, an actual physical one, made of metal, by a company, and you’d sat down to learn the slide from my game, the hole numbers would have been wrong. Every one of them. And nothing anywhere would have told you why, and you would have assumed the problem was you, because when you’re learning an instrument you always assume the problem is you, and about nine times in ten you’re right, and this was the tenth time.
Both charts are re-fingered onto the real instrument now. The music didn’t change, and it couldn’t, because every event already recorded the pitch it sounds and those pitches were fine. It was only ever the hole numbers that were imaginary. So I re-resolved each event from its note instead of its hole: thirty three of them in Für Elise, sixteen in the lesson. Not one note moved.
The slide lesson does now teach ten slides instead of fourteen, because on a real solo tuned harmonica more of those notes just sit on a plain reed and don’t need the button. Which is fine. Ten slides is plenty of slides.
And the test that would have caught this doesn’t compare the charts to themselves, because as established they were extremely happy with themselves. It compares them against a tuning this codebase can actually build.
The staff was lying too, only quietly</h2>
Two smaller ones, both in the notation strip along the top.
Accidentals were drawn per note instead of per bar. So if a tune leans on one altered note, and blues tunes do, a second position blues leans on its F# all day long, you got the same sharp redrawn in front of every single note. Which looks silly, but it’s worse than silly, because each one is about eleven pixels wide and an eighth note only has seventeen pixels to give in the first place.
They hold for the rest of the bar now, like they do on paper. And every note that cancels one gets a real natural sign, because just skipping the repeats would have left a later plain F in that bar reading as an F#, and I’d have gone from drawing something redundant to drawing something false, which is a worse trade than it sounds.
The staff itself was a fixed thirty four pixels per beat, and a notehead plus the accidental in front of it wants about twenty one, and a sixteenth note was getting eight and a half. They overlapped. Of course they overlapped. It works out the spacing from each song’s own density now, with a cap on it, because otherwise one busy bar shrinks how far ahead you can see down to about a bar and a half, and then you can’t read the thing at all.
That’s v0.0.11. Still 0.0.x, still early, still on GitHub</a>, still, as of this week, no longer shipping an instrument that does not exist.

Harmonicon Weekly Update: any harp, any file

2026-09-07T00:00:00+00:00

This is a weekly update, which means I did a week of things and now I’m going to tell you about them, and I should say up front that most of the week went on two problems that sound small when you write them down. You had to own the exact harmonica a chart was written for. And the chart had to be in my file format, the one I invented, the one nobody else has ever written anything in.

The one harmonica you own</h2>
Here’s the thing about harmonicas. A diatonic is built in one key. Not tuned to one key, built in it, the reeds are physically cut for it, and if the chart says C and the harp in your pocket says G then you can’t play that chart. Not badly, not with effort. You sit there and nothing you do produces the note.
And people learning have one harmonica. One. Whichever one turned up. So the situation where you open my game, pick a song, and discover it wasn’t written for the only instrument you own isn’t an edge case, it’s Tuesday.
There are two honest answers to this and they go in opposite directions. You keep the tab and let the music move: same holes, same breath, different key. Or you keep the music and let the tab move: same tune, different holes. Both are defensible, I couldn’t pick, so I built both and put them on a little screen that turns up after you choose a song.
That screen also tells you the damage. Something like “5 need a bend · 2 need an overblow · 9 can’t be played”. The nine is the number I built the screen for. If swapping your harp in quietly eats a fifth of the melody, I’d rather say it out loud and let you decide than hand you a chart with holes in it and let you assume you’re the problem.

The test that went looking for one thing</h2>
The remapping code has a property test on it. It walks twelve source keys against twelve target keys, both harmonica families, every hole, both breath directions, in both of those modes I just described, and for every single combination it checks that anything the code calls playable is a pitch that harmonica can physically produce.
That check is the entire reason the test exists. If it fails, my game is sitting there listening for a note you cannot make, and then marking you down for not making it, and you’d have no way of knowing which of you was broken.
It told me I was wrong three times, and each time the code was right, which is why I wrote a test instead of trusting myself. A G harp is pitched below C, not above, so G4 sits on hole 4 and not hole 1. A#4 isn’t on an F harp at all, and I had to go find a Bb before I could test the case I actually wanted. And transposing a chart onto its own harmonica isn’t the no-op I’d assumed, because hole 3 blow and hole 2 draw are both G4 on a C harp, so resolving by pitch alone was quietly rewriting one into the other and telling me it had done nothing.
But that’s not the interesting part.
The interesting part is that the same test, which I wrote to check transposition, sat down and told me about a bug that has nothing to do with transposition at all. The set of notes my scorer will accept from your microphone was built out of blow reeds, draw reeds and bends. Not overblows. Not overdraws. On a C harp, seven of the eight over-pitches simply were not in that set, which means any chart asking for an overblow could never be scored. Ever. Not once. And nothing on screen would have told you why.
Nobody hit it because none of the charts I ship use one. It was going to sit there until somebody wrote something advanced, and then it was going to look like a microphone problem, and they’d have spent an evening buying a better microphone.
Later in the week I found the same kind of thing pointing the other way. My table of how far each hole bends had every hole capped at a semitone and a half, which is just wrong. A bend pulls a reed toward the other reed in the same hole, so how far you can go is however much room is between them. Three full semitones on hole 3, which is the note you buy a harmonica in order to play. Nothing at all on holes 5 and 7. The table says that now, and there’s a test comparing it against the physical layout, because two descriptions of one physical fact will come apart eventually and I’d rather find out from CI.
Somebody else’s files</h2>
Harmonicon reads Guitar Pro now, gp3 through gp7, and MuseScore, and MusicXML, and MIDI. Drop one in a song folder and it gets found and converted and played.
Parsing them was the easy half. The hard half is that a tab file is a whole band. Bass, comp, melody, usually drums, and I have to work out which of those you meant. So every track gets converted on its own and fitted to its own harmonica, because the right harp for a melody is almost never the right harp for a bass line, and then you get a list telling you what you’d actually be able to play. “Track 1: 6 notes, 0% playable. Track 2: 100%.”
If a track is called Harmonica it wins automatically, and I learned two exceptions to that by breaking things. A bass line called Harmonica handed me a chart with no playable notes in it at all, so being named right no longer beats being playable. And drum tracks now report zero notes on purpose, because their frets are drum kit indices, and if you read those as pitches you get a part that looks entirely reasonable, wins the picker, and then plays nothing whatsoever resembling the song.
The word “harp” on its own is deliberately not in my list of names to look for. It matches an orchestral harp. A harp part converted to harmonica is precisely the unplayable soup the list exists to prevent, and the arithmetic isn’t close: missing a track called Harp costs you one click, matching a real one costs you a chart nobody alive can play.
All seven of them sit behind one trait in a new crate, so the next format is a module and a match arm. It cost more than I wanted. That crate went from 5 dependencies to 94, almost all of it zip and everything zip drags along behind it. I wrote the tradeoff down and slept on it before deciding, which I mention because I nearly didn’t, and the thing that decided it was that zip is what MuseScore and the newer Guitar Pro containers genuinely need, so it buys three formats rather than propping up one.
Which of my detectors can hear a chord</h2>
Chord scoring has been in there for ages. It wants every pitch of the chord present at the same time, which is a reasonable thing to want. What I had never once checked is whether the pitch detectors can actually deliver it.
So I measured, on a real chord out of a real chart. FFT, which is the default, hears both notes. NMF hears both notes. YIN, pYIN and MPM hear neither.
And the three that fail don’t fail quietly. pYIN and MPM both report an F4, confidently, a note which is not in the signal, which simply happens to sit between the two notes that are. So it isn’t a chord going unscored. It’s a wrong note strolling into the scorer with its hands in its pockets.
None of which was visible from inside the game. Choosing pYIN in the options made every chord in every chart unhittable and told you nothing. The picker says “pYIN, single notes only” now, and if the song you loaded has chords your detector can’t hear, a banner says so.
While I was in there: unplugging your microphone in the middle of a song used to leave the game convinced it was still connected. Your notes just stopped scoring, forever, silently. Which is the exact failure I’d built a warning overlay for the week before, reachable by the more likely route the entire time, and I’d like it on the record that I found this myself before anybody else did.
Three hundred gigabytes</h2>
Now this next part isn’t about the game at all and you can skip it, except that it ate two days, so.
My build directory had reached 300 gigabytes.
Two separate reasons, both boring, both mine. A debug binary was 2.41 GB, of which about ninety percent was debug information for dependencies I have never once stepped into. And cargo doesn’t delete the old ones. So there were ninety-nine files of over a gigabyte each, sitting there, going back to August, every one of them a complete binary from some build I’d long since stopped caring about.
A few profile settings and a sweep later a debug binary is 287 MB, and a clean build plus the entire test suite leaves the whole tree at 7.1 GB.
While I was in the mood I also found the version number written in four different places that disagreed with each other, which meant the version the game showed you in Help / About was one that no release has ever actually carried. One script bumps all four now, and CI fails in about three seconds if the tag and the manifest disagree, rather than after four platform builds have finished uploading.
So: you can play a chart on the harmonica you own, or on the one it was written for, and either way it’ll tell you what that’s going to cost you before you start. And you can hand it a Guitar Pro file, and it’ll work out which part of the band you meant.
1306 tests passing. Still 0.0.x, still early, still on GitHub</a>.

Harmonicon: a rhythm game you play on a real harmonica

2026-08-31T00:00:00+00:00

For once, something on this blog that isn’t C++.
Harmonicon is a rhythm game for blues harmonica. Notes scroll toward a hit line and you play on an actual harmonica, into your microphone, and the game listens.
The idea</h2>
The harmonica is cheap, fits in a pocket, and it hides everything: the reeds are inside, your tongue and throat do most of the work, and nothing about the instrument tells you whether the note that just came out is the note you meant. You can practise a bend wrong for a month quite happily.
Let the instrument be the input. Harmonicon captures the microphone, runs pitch detection on it in real time, and scores what you actually played against the chart. Every note you score is a note you genuinely hit.
Playing a song</h2>

The default view is one lane per hole: ten for a diatonic, twelve for a chromatic, taken from whatever the chart was written for. Blue notes are blows, orange are draws, and the number on each is the hole you need. Above the lanes there’s the phrase in standard notation and as harmonica tab, because those are the two ways harmonica players actually read music, and the panel on the right tells you which harp to pick up and which position you’re playing in.
There’s also a 3D view, which is the same game rendered around a harmonica model that moves with the beat.
 
Getting away from charts</h2>
Charts are good for learning a song and bad for learning to play. The Jam Session mode drops the scoring entirely and gives you a rolling 12-bar blues to improvise over.

The useful part is the hole map on the right. As the backing moves through the bars, each hole recolours: gold if it’s a chord tone of the bar sounding right now, green if it’s elsewhere in the blues scale, dim if it’s going to sound wrong. You follow the colour instead of trying to recall theory at tempo, and the theory arrives later, on its own.
Lessons</h2>

There’s a curriculum underneath all of this, grouped into units and gated by prerequisites, from getting one clean single note out of the thing, through bends and articulation, up to improvising over a blues. Some lessons are scored drills. A few aren’t scoreable at all: tongue blocking sounds identical to puckering from the microphone’s point of view, so that one is instruction you mark as done and the game trusts you.
Under the hood</h2>
Rust, with Bevy</a> for the engine and cpal</code> for audio capture. The interesting problem is the pitch detection, which is why there are five algorithms to chose from: FFT, YIN, pYIN, MPM and NMF.
Status</h2> There’s a lot in it: a bending trainer, an in-game song editor with MIDI import, adaptive difficulty, A–B looping, latency calibration, a spectrogram, but “early/experimental” is an honest label rather than modesty.It’s MIT licensed and the code is at github.com/tcanabrava/harmonicon</a>. If you own a harmonica and a microphone, that’s the entire hardware requirement.
FOSSASIA 2026: Bangkok, Booths, and the Hallway Track 2026-03-13T00:00:00+00:00 I went to FOSSASIA Summit 2026 in Bangkok, and I took the time to write this report because of how much things happened in three days, also because I am not much of a blogger. FOSSASIA is Asia’s big open source event and this year it took place at True Digital Park West - a rather exageratted shopping mall and convention center, which was great because whenever I was hungry I could just quickly go eat some lovely thai dishes, and back. KDE had a community booth, and I spent a fair amount of time there alongside Pongsakorn, who held things down while I was off getting pulled into hallway conversations. We had a few devices on display running Plasma and I got to show off some recent Konsole work to anyone who wandered over. Some people requested me to show what mattered more to me in KDE, why I was a KDE developer, or why don’t I use $software from a different provider. I explained that KDE is not just about the software, but about the community and the people who contribute to it, but also about the software. There is no other terminal that can do what konsole does (well, now it’s my second favorite terminal, my favorite one is https://ratty-term.org/). The hallway track was, as usual, where a lot of the real conversations happened. One of the more interesting ones was with some developers from OpenKylin. They’re building a Linux distribution and they are using KDE Technology behind it. During our conversation we talked about how to better integrate the OpenKylin distribution with KDE Technology, and I ended up with an invitation to their HQ in shanghai - there will be another blogpost about this. Bangkok itself was great, but also strangely familiar - all the streets, buildings, and the way people behave fit exactly in the city that I grew up in, Salvador, in Brazil. It was strange to see a country in asia to be so similar to my hometown. Coming back from a conference like this always leaves me with a mixed feeling: energized by all the conversations and connections, and slightly overwhelmed by the list of things I now want to go and implement or investigate. The OpenKylin conversation got me thinking more about how distributions handle the upstream relationship. And seeing what different communities are building with AI at the OS level was genuinely interesting, even if I’m skeptical of some of the grander claims in the space. FOSSASIA remains one of the better events to go to if you want a view of what open source looks like outside the European and North American bubble, and we need to connect with other communities to learn from and collaborate with. The State of KDE Apps and Plasma in Archlinux 2024-05-09T00:00:00+00:00 KDE has a symbiotic relationship with many linux distros, since while we develop our software we also use particular versions of linux, I personally use archlinux as my distro of choice for many years being the only distro that I manage to bare for more than six months ( and I believe I am using it for more than 15 years already so that counts). The “recipe” for packaging KDE software for arch is big, because we are big, and packaging large amounts of software is no easy feat, so me and Antonio Rojas started to update the build scripts to be less manual and less error prone. All the versions of Plasma 6 that have been packaged for arch are using this scripts in one way or another (or manually when we broke everything :) This work is being done in a separate branch to not break the current workflow, but things are looking good and we hope to merge this in master soon, so that deploying newer versions of KDE software for arch will be a single command, meaning more time for the developers and less time creating packages. Porting Codevis to KDE 2023-10-12T00:00:00+00:00 The Problem with C++ Tooling</h1> An ISO accepted C++ tooling is inexistent, so each project will choose their own toolings based on personal preference, and sometimes, based on Corporations preferences, and unfortunately there’s no common ground on what should be used. There are some programs that got the Standard by consensus</code>, like CMake</code>. But even tough, projects will choose handmade makefiles</code>, KConfig</code>, meson</code>, autotools</code>, and many others exist. The same thing happens for Package Managers, each Linux distributtion has a variant of packages, and on top of that there’s vcpkg</code>, conan</code> - each one with pros and cons. The lack of a node</code> or a cargo</code> or a pip</code> that’s the entry point for the language makes it complex for developers to know where to start, and the most common idea is to build what doesn’t exist, or manually install (via git submodules/git subtrees</code>) things that are not disponible in your distribution or operating system. How Codevis Started (Tools and Libraries)</h1> Codevis started as an experiment to see if it would be possible to apply the ideas in the Large Scale C++</code> book by John Lakos</code>. A small proof of concept was created three years ago, and we adopted a lot of libraries to be able to work fast keeping the quality high: Qt (5 and 6)</li> soci (database layer used at CERN)</li> QuaZip (easy access to compressed files)</li> LLVM and CLang (parsing of C++ files)</li> Sqlite3 (our actual database)</li> Doxygen (Documentation)</li> Python (Plugins)</li> Catch2 (Tests)</li> </ul> And this is already a fair number of libraries, specially considering that those libraries also depend on others, keeping the Dependency graph quite large. One problem that we had was to create a CI for all systems we targeted with all those libraries. both of the most common C++ package managers failed us: conan</code> did not had LLVM (and we indeed created patches for it, adding missing libraries)</li> vcpkg</code> did not had some libraries that we needed, too.</li> </ul> Because of this we had to manually create base CI scripts that would download, compile, install the libraries that were not found on the package managers but this is frail, as any handwritten script is. We started to look for a new home, and KDE was nice enough to host us. This gave us their amazing CI and buildsystems, that already had all the libraries we used, plus a few more. So we were able to drop the handwritten scripts for, mostly, llvm. Why did the change from Pure Qt to KDE Frameworks?</h1> When you are inside of a system that works, and that offers powerful and battle tested libraries, it’s worth to try to use them. There are many libraries in the KDE Frameworks that I wanted to use before but it was too hard to bring to windows if I’m not using craft</code>, resembles to conan</code> and knows how to build libraries and applications within the KDE universe. Adding the necessary information to build Codevis</code> in craft was much simpler than expected.: clone craft-blueprints-kde</code></li> copy a program template and chagne it’s name</li> point to the kde repository with a list of libraries it should use</li> </ul> The full codevis</code> recipe for windows, mac and linux using craft</code> is the following: Note that every line on runtimeDependencies and buildDependencies are a craft</code> recipe inside of the same repository, so just by searching the folders it’s easy to know what to add for your program. import info from Packager.CollectionPackagerBase import PackagerLists class subinfo(info.infoclass): def setTargets(self): self.versionInfo.setDefaultValues() self.description = "Codevis is a software to visualize large software architectures." self.displayName = "Codevis" self.webpage = "http://invent.kde.org/sdk/codevis" self.svnTargets["master"] = "http://invent.kde.org/sdk/codevis.git" def setDependencies(self): self.buildDependencies["kde/frameworks/extra-cmake-modules"] = None self.runtimeDependencies["libs/llvm"] = None self.runtimeDependencies["libs/zlib"] = None self.runtimeDependencies["libs/catch2"] = None self.runtimeDependencies["qt-libs/quazip"] = None self.runtimeDependencies["libs/runtime"] = None self.runtimeDependencies["libs/qt5/qtbase"] = None from Package.CMakePackageBase import * class Package(CMakePackageBase): def __init__(self): CMakePackageBase.__init__(self) self.subinfo.options.configure.args += ["-DUSE_QT_WEBENGINE=OFF ", "-DCOMPILE_TESTS=OFF "] def createPackage(self): self.defines["executable"] = "bin\\codevis_desktop.exe" return TypePackager.createPackage(self)</code></pre>How easy is to bring a 50 - 100K lines of code to KDE?</h1> We adopted KConfig</code></li> </ul> With The build part fixed, it was time to adopt some libraries to remove some handwritten logic we had. I wrote a configuration to c++ parser to easily access configuration keys from .ini format, but this was the only project using it, so why not change to KConfig, that uses a XML</code> based description for settings, and it’s used by almost all programs within the KDE Infrastructure (and it certainly has way more unittests preventing breackages than what I have on my try) We adopted KXmlGUI</code></li> </ul> KXMLGui is one of the killer features of the KDE Frameworks</code>. It allow you to split the logic of your interface with a description of Menus</code> and Toolbars</code> in XML</code>, and in runtime it provides some nice features like allowing the user to change the toolbars with any action registered within the system, and a searchable command pallete</code>, that’s something I use in all KDE</code> applications on my machine, and I sure was missing this on Codevis. We adopted KDocTools</code></li> </ul> Documentation is complex, but having an integrated documentation viewer and semantics ready, that could compile into hmtl with integrated search is impressive. Now we just need the time to actually write that documentation… We adopted KNewStuff</code></li> </ul> KNewStuff is a technology that integrates with pling.com</code> and allows to distribute certain types of downloadable goodies, like wallpapers - or in our case, plugins</code> to improve the system with things that the main developers didn’t had the time to do yet. We adopted KNotification</code></li> </ul> Since the application takes a while to parse C++ code, or to run some plugins, KNotification</code> is used to send a desktop notification to the user when an action ends. A small feature, but good for UX. We adopted KTextEditor</code></li> </ul> We need to have a place for users to develop plugins for Codevis, so KTextEditor was not a hard choice, it’s the editor that powers up Kate, one of the flagship applications from KDE. Using it has been extremely easy and fast, supporting syntax-highlihting</code> for multiple formats. An Honest, and unbiased, view</h1> The work to port Codevis to use KDE libraries took around 2 weeks, and things were good. No major breakage and just some changes in behavior (mostly for the better). We also helped the KF6 libraries with ideas while discussing on their public channel in Matrix, and patches for some other programs while developing (such as Konsole</code>, Kate</code>, Konversation</code>). Nothing is perfect, but the outcome was a better, more stable, Codevis and the community was great while helping us understand how to use / handle specifics of a library - like KNotification</code> using raw news</code> without a corresponding call to a deleter. This was fixed by a comment on the Documentation stating that it auto-deletes itself. Should Corporations Adopt KDE Libraries?</h1> For sure. The libraries are really high quality, and there are more than 90 of them. Not using</code> something that’s already working and with tests, is a waste of money on the corporation side. Are the devs Happy?</h1> Yes, and I would use KDE Frameworks again. The work for Codevis</code> is sponsored by Bloomberg</code>, and done by Codethink</code> in the open, inside of the KDE Repositories. Codevis Weekly Update 2023-10-06T00:00:00+00:00 Welcome to the first “Codevis Weekly Update” What is Codevis?</h1> Codevis</a> is a tool to help developers manage large codebases, sponsored by Bloomberg, developed by Codethink and hosted on the KDE Infrastructure, with all that, completely opensource with a permissive license. Codevis uses a mix of technologies to do what it does, mainly LLVM and Clang</code> to do the heavy lifting of understanding C++ Codebases, Qt</code> for Callback management (in the form of Signal/Slots), KDE Frameworks</code> libraries for the desktop application, and pure Qt</code> for the CLI application. The database layer is written with Soci</code> , the same database layer used in CERN, targeting sqlite3. But How does it work?</h1> Codevis analyzes all the visible source code from your project and creates a graph database (using a relational database) in a way that the analyst can load and interpret information from the codebase without loading the codebase. The graph-database is comprehensive</code>, and has all the information we think it’s important, and also a lot of information that’s good to have</code>, with a bunch of information because why not</code>. Since something that’s not important for me could be really important for a company with billions of lines of code. It just generates visualization?</h1> No. Codevis also allows you to draw your software architecture and generate ready-to-compile c++ code from it. Think of this as a possibility to have C++ templates for complex projects tha are also visually documented. You can create libraries, classes, structures, connect them quickly on a dirty mockup during a meeting, and the output could be 60 c++ files on disk</code> with all the classes, folder-hierarchy and CMake</code> ready to compile. This will not add any method or implement anything, but just the creation of the C++ files and CMake scripts from a small architecture meeting is pretty interesting in my point of view. Yeah, but isn’t UML alreday that?</h1> No. UML is quite more complex and harder to use for large scale visualization, and the UML code generation doesn’t really takes buildability</code> in mind. You can’t generate an entire project from a UML definition. You say that it’s a large scale, but my proejct is small. it will also help me?</h1> Codevis will analyze everything, every single include that you use (even if it’s not from your project), helping you decide the best usage for libraries and visualizing the graph with different graph algorithms - making sure that the physical software layout</code> is organized (not just the logical architecture</code>). Improve it with Plugins</h1> We support C++</code> and Python</code> plugins so you can implement things that might be important for your corporation (and by corporation I mean Gnome, KDE, RedHat, Collabora</code>, etc) and integrate the software in ways that the developers didn’t think of. CI integration?</h1> Imagine that you need to make sure the architecture of the software is stable. Architecture is not something that is easy to do unittests</code> for. it can also be a complex architecture so it’s hard to see if all my new header and source</code> files are implementing (or correctly integrating) into new architecture. with Codevis you can use the cli</code> tools and extract the code information on a CI step, load the database and run a plugin that checks if the whole architecture of the system is correct, based on heuristics. Is everything you said here production ready?</h1> No. This is also an appeal for help. we are developing and we have almost everything here running correcty, some parts are missing, specially, people using and testing is missing. We appreciate if people download, compile, try. Is this still on? 2023-10-04T00:00:00+00:00 It’s been a Long long time without posting anything. Not that i’m lazy (well, a bit). But I have been working on a lot of things related to KDE this past few years, and I was finally able to release and opensource Codevis. I know this post is as small as a tweet, just checking if the integration is stil working Konsole in 2021 2021-12-27T00:00:00+00:00 This year konsole kept the momentum it gained in 2020, and implemented quite a lot of userful new features. We Finally implemented Reflow, thanks to the combined effort of me and Carlos Alves - that was one of the most requested features of konsole for the entire history of the project. Ahmad Samir fixed tons of issues in konsole, all around the codebase, he’s the person with most commits on konsole this year, praise to him. Waqar has been on a spree speeding konsole by a factor of too much - he’s single handly managed to make scrolling in konsole twice as fast, and we are now almost as fast as the fastest terminals, and the fastest terminals don’t offer what konsole offers. FreeBSD got a bit of love under konsole, too. By the skillfull hands of Adriaan de Groot, our bsd wizzard. We also implemented a plugin system for konsole, and the first plugin implemented is a putty like interface to manage SSH sessions All in all, we had around 200 commits for konsole this year, and that’s a pretty good shape - one of the most active projects for terminals all around. KConfigXT Alternative Generator 2021-09-20T00:00:00+00:00 I’m using for my own personal projects a generator for c++ preferences for quite a while, I’ll not say that it’s heavily tested as KConfigXT is, but it is also much more simple than it. While talking about it to a fellow developer he asked me how hard it would be to port the thing to KConfig (as the main backend I used was QSettings) - and the result is quite nice, the port toook less than a day, and now my generator generates configurations for both KConfig and QSettings. Example configuration:</li> </ul> preferences.conf #include <QString> #include <QStandardPaths> Preferences { General { int beatsPerMinute = 60 } Some { Inner { Group { int value = 10 } } } Harmonica { QString partitureFolder = QStandardPaths::writableLocation(QStandardPaths::DocumentsLocation) } } </code></pre> For those that worked with KConfigXT, it’s easy to see how much this is different from the xml that the tool uses. And differently from KConfigXT, the code is smaller, easier to read, and does not rely on magic enums, nor it has a lot of different possibilities to fine tune the settings - if you want to choose between runtime or compile time file, shared vs non shared config, etc.: KConfigXT is for you, mine is supposed to be simple and up to the point. That Preferences will generate all the corresponding C++ classes with the needed boilerplate for a Qt application to handle settings, in a safe way - no more strings for keys on code. Preferences::self()->some()->inner()->group()->setValue(15); Preferences::self()->general()->setBeatsPerMinute(10);</code></pre> All of the preferences are exported as Q_PROPERTIES using snake_case</code> so you use it directly on Qml. SomeQmlElement { width: preferences.window.width }</code></pre> If you want to set specific rules to the Preferences values, this is done in c++, using the setRule</code> variants of the settings: int main(int argc, char *argv[]) { QApplication app(argc, argv); Preferences::self()->some()->inner()->group()->setValueRule([](int value) { return value < 90; }); }</code></pre> The defaut values can be queried with Default</code> variants: Preferences::self()->some()->inner()->group->valueDefault();</code></pre> There’s no code to automatically handle ui files, like KConfigXT, nor there will be. create your connects by hand using this. The source is at https://github.com/tcanabrava/configuration-parser Currently the build produces two binaries: one for qsettings, one for kconfig. (if anyone is better at cmake than myself, I’d appreicate some help on ConfigurationCompiler.cmake, as it’s not correctly generating the targets on a 3rd party project) Konsole in 2020 2020-06-16T00:00:00+00:00 Konsole is having a resurge in the moment, it’s the terminal emulator of choice for the power user that wants to break the 4th wall in *nix systems. Right now it can do almost all the things I want it to do, and a few more. Since last year you can use splits in Konsole, with full drag & drop support between tabs and windows. </iframe> </div> You can also use Konsole to quickly check for thumbnails of anything that dolphin can show you, just by hovering with the mouse (and depending of your configuration) pressing shift/control/alt. To my knowledge Konsole is the only terminal emulator that supports this. </iframe> </div> Probably you already used ls</code> to list a file that you need to get the full url, to open in an unrelated program that does not accept the common way to open files via the shell, and you need to paste into a dialog, or you just need to send the full path of a file for a project colleague. I had problems with this untill I snapped and implemented a way for konsole to Copy Location</code>, it copies the full file path of the selected file, and adds this data to your clipboard. </iframe> </div> Konsole supported for quite a while a way for you to click in a file and open it in a the default editor (you need to have this configured in the profile) - but sometimes we don’t want to open it in the default file, we wan’t to visualize a image in gwenview or edit it in gimp, so now konsole supports a Open With</code> menu quite helpful when you don’t remember the name of the app you want to use but remember the icon. :) </iframe> </div> Now a few features I’m working that I expect that will be ready for the next version of konsole, those are still in review and I don’t know when they will be ready, it’s just a sneak peek: Configurable dimm stength for inactive terminals - when you are working with split views and many terminals, there’s a option in the profile that makes the terminals without focus darker, so it’s easier to know which terminal you are, but it was not possible to configure the amount of darkening - and different people have different needs, so now you can do this: (not merged yet) </iframe> </div> Improved broadcast support - Konsole already supported this, but it did not play well with splits, and it was not really easy to integrate multiple windows. How you can now select what kind of broadcast group a terminal belongs to, any terminal that belongs to the same group will send data to it, there’s also a None group - for terminals that should not send data anywhere, and a Broadcast to All</code> groups, that will push data everywhere - despite being in the group or not. (not merged yet) </iframe> </div> Support for URL Escape Codes. There’s a spec that specifies how a terminal application can embbed a URL inside of a block of text, by using the special notation: \e]8;;http://www.kde.org\e\\click here\e]8;;\e\\\n</code> this is equivalent to the html code <a href="http://www.kde.org> click here </a></code> and there’s a work in progress implementation for that in the works (featuring a VIP list of accepted schemas, currently only file, http and https are allowed, but the user can overrite) </iframe> </div> Those are all of the features that I worked (minus tons of bugfixes, security improvements and general rewrites that are unrelated to new features). I hope you all enjoy the new konsole, that is still one of the fastest terminal emulators around, even tough it’s packed with features for the experienced and novice user. Konsole and Splits 2019-06-27T00:00:00+00:00 Some terminals like Tilix and Terminator offers the possibility to split the screen recursively, and I started to add the same thing to konsole. Konsole is usually said to be the swiss army knife of the terminal emulators, and if you didn’t try it yet, please do. We offer quite a lot of things that no other terminal emulator offer. Rigth now this code is in review but it currently supports quite a few things: Allow to Drag & drop the tab to create a new window of konsole</li> Allow to Drag & drop the tab back into another window</li> Allow to Drag & drop a split to reposition it in the current tab</li> Allow to Drag & drop a split to another tab</li> Allow to Drag & drop a split to another window (if in the same process)</li> </ul> </iframe> </div> Expect this to be in the next version of konsole if all goes well. Help to test, help to find bugs, Help to test, help to find bugs. Konsole and Wayland 2019-06-18T00:00:00+00:00 Wayland needs a different mindset when you are programming, you cannot just assume things works the same way as in as X11. One of my first patches to konsole was the rewrite of the Tab Bar, and a different way to deal with Drag & Drop of the tabs. In my mind - and how wrong I was - I could assume that I was dragging to a konsole main window by querying the widget below the mouse. Nope, this will not work. As Wayland has security by default, it will not give you anything global. What if I was a spy app trying to record another one to send to NSA? Security in Wayland is much stricter, and because of that I had to redo my drag & drop patch. Konsole should work now with drag & drop of tabs in Wayland, as soon as the patch hits master. I also have other patches waiting that will make the wayland transition smoother, I’ll write about them in due time. The state of Terminal Emulators in Linux 2019-06-15T00:00:00+00:00 We are seeing a strange trend nowadays: The terminal is being more widely used in windows, after they fixed the broken cmd.exe and MS is actually actively promoting their terminal applications like Visual Studio Code and the new Windows Terminal, but on the other hand the Unix world was always terminal based, even if you tend to use the Desktop Environment for your daily needs you probably also had a Terminal open somewhere. And because we had always been terminal users, there are a lot of terminals for Linux, But it’s not easy to keep a terminal up to date, it’s usually fragile code and hard to maintain, that means that a lot of projects, good projects, are abandoned. Good terminals that unfortunately didn’t make it</h2> Tilix: Is one of the best terminal emulators out there, it’s a shell written in D, on top of VTE, the author lacks the time to continue working on it.</li> Terminator: I don’t know if this one is abandoned as there’s no news on the web about it, the news that I know is that version 2 is scheduled for release in 2017, never happened though.</li> </ul> If you are sad that your favorite terminal is without a maintainer, try to maintain it, free software depends on developers. The state of Konsole:</h2> Konsole is receiving more reviews, more code and more contributors in the last year than it got in the past 10 years.</li> In the past, the project is kept alive by Kurt, and he did an awesome job. But a project as big as konsole needs more people.</li> Three new developers joined konsole and are activelly fixing things over the past year, no plans to stop.</li> Terminator / Tilix split mode is working</li> A few features to be completely equal to minix / terminator is missing, but not hard to implement</li> </ul> Now it has more developers and more code flowing, fixing bugs, improving the interface, increasing the number of lines of code flowing thru the codebase. We don’t plan to stop supporting konsole, and it will not depend on a single developer anymore. We want konsole to be the swiss army knife of terminal emulators, you can already do with konsole a lot of things that are impossible in other terminals, but we want more. And we need more developers for that. Konsole is, together with VTE, the most used terminal out there in numbers of applications that integrate the technology: Dolphin, Kate, KDevelop, Yakuake, and many other applications also use konsole, so fixing a bug in one place we are helping a lot of other applications too. Consider joining a project, Consider sending code. Hello new Konsole 2019-06-05T00:00:00+00:00 Konsole has been ready for many many years, and got almost 10 years without anything really exciting being added, mostly because the software is ready, why should we modify something that works to add experimental features? But then the reality kicked in, konsole missed some features that are quite nice and existed in Terminator, Tilix and other new terminals, but Tilix now lacks a developer, and Terminator is also not being actively developed (with the last release being it in 26 of February of 2017) Konsole is tougth as a powerhouse of the terminal emulators, having too many things that are quite specific for some use cases, and it’s really tricky to remove a feture (even when it’s half-broken) because some people do rely in that behavior, so my first idea is to modernize the codebase so I can actually start to code. It’s been around one year that I send patches regularly to Konsole now, and I don’t plan to stop.

Under the hood</h2>
Rust, with Bevy</a> for the engine and `cpal</code> for audio capture. The interesting problem is the pitch detection, which is why there are five algorithms to chose from: FFT, YIN, pYIN, MPM and NMF.</p>`

`Is everything you said here production ready?</h1> No. This is also an appeal for help. we are developing and we have almost</em> everything here running correcty, some parts are missing, specially, people using and testing is missing. We appreciate if people download, compile, try.</p>`

Tomaz Canabrava Ramblings

Harmonicon v0.0.11, or, the harmonica I made up

Harmonicon Weekly Update: any harp, any file

Harmonicon: a rhythm game you play on a real harmonica

FOSSASIA 2026: Bangkok, Booths, and the Hallway Track

The State of KDE Apps and Plasma in Archlinux

Porting Codevis to KDE

`Are the devs Happy?</h1> Yes, and I would use KDE Frameworks again.</p> The work for Codevis</code> is sponsored by Bloomberg</code>, and done by Codethink</code> in the open, inside of the KDE Repositories.</p>`

Codevis Weekly Update

Is this still on?

Konsole in 2021

KConfigXT Alternative Generator

Konsole in 2020

Konsole and Splits

Konsole and Wayland

The state of Terminal Emulators in Linux

Hello new Konsole

Tomaz Canabrava Ramblings

Harmonicon v0.0.11, or, the harmonica I made up

Harmonicon Weekly Update: any harp, any file

Harmonicon: a rhythm game you play on a real harmonica

Under the hood</h2> Rust, with Bevy</a> for the engine and cpal</code> for audio capture. The interesting problem is the pitch detection, which is why there are five algorithms to chose from: FFT, YIN, pYIN, MPM and NMF.</p>

FOSSASIA 2026: Bangkok, Booths, and the Hallway Track

The State of KDE Apps and Plasma in Archlinux

Porting Codevis to KDE

Are the devs Happy?</h1> Yes, and I would use KDE Frameworks again.</p> The work for Codevis</code> is sponsored by Bloomberg</code>, and done by Codethink</code> in the open, inside of the KDE Repositories.</p>

Codevis Weekly Update

Is everything you said here production ready?</h1> No. This is also an appeal for help. we are developing and we have almost</em> everything here running correcty, some parts are missing, specially, people using and testing is missing. We appreciate if people download, compile, try.</p>

Is this still on?

Konsole in 2021

KConfigXT Alternative Generator

Konsole in 2020

Konsole and Splits

Konsole and Wayland

The state of Terminal Emulators in Linux

Hello new Konsole

Under the hood</h2>
Rust, with Bevy</a> for the engine and `cpal</code> for audio capture. The interesting problem is the pitch detection, which is why there are five algorithms to chose from: FFT, YIN, pYIN, MPM and NMF.</p>`

`Are the devs Happy?</h1> Yes, and I would use KDE Frameworks again.</p> The work for Codevis</code> is sponsored by Bloomberg</code>, and done by Codethink</code> in the open, inside of the KDE Repositories.</p>`

`Is everything you said here production ready?</h1> No. This is also an appeal for help. we are developing and we have almost</em> everything here running correcty, some parts are missing, specially, people using and testing is missing. We appreciate if people download, compile, try.</p>`