C++ the Basic Way 2025 (4) | GTK Header Bar all Code no XML ui File | Native Linux GUI

This video came out much later than I planned. Besides normal day-to-day matters such as keeping up with obligations, the core concept in this video is achievable in less than 2 days. However, it took me nearly a week. The upside is I encountered an issue that will help others who may struggle with GTK HeaderBar and GTK Menu and putting them together.

The issue is not a technical issue. My opinion is there is an issue with the documentation. While I feel the documentation is great. Again, my opinion. It does not go far enough in some cases or almost forces you do things a certain way when there are other approaches that are just as valid. I showcase an approach which is often better for performance, executable size, and reduced build complexity.

Yes, I spent 4 to 5 days on a GTK HeaderBar. Some would laugh at the unyielding focus to build the code and not give in to a short-term easy choice. I wanted that typical Gnome flip down menu.

The problem? Well, I am glad you asked. You see, the documentation on how to set them up together was not as clear. A GTK HeaderBar is the long strip at the top of a window. You can add a menu to this strip where you can program in functions common to a window. All that is easy in concept but it has to be done in a particular sequence.

The video has chapters for those that want to skip straight to the discussion which occurs starting at timestamps 10:56 and 17:11. The rest of the video helps those coming in fresh with getting caught up on the context for why and how we got here.

In this video I explore multiple avenues where I "chased down" the proper way to do this without having to resort to a GTK Builder .ui xml file. I wanted to setup the GTK HeaderBar and Menu using only C++ code and that process could not be more difficult when blindly following the documentation.

I wanted the header and menu for the software I am building to look a certain way and I persisted until I achieved the goal. I paid a price in terms of time. Despite the cost, I refused to be defeated by an industry perspective that seems increasingly designed to guide the way people write software directly by making obvious elements more obscure.

Walk with me as I decode this process with respect to GTK HeaderBar and Menu to setup functionality to present a configuration window. Yes, 4 to 5 days on a menu. I could have just placed a button on the screen just under the list of barcodes but since this is a private software program, I have the option of not compromising on my objectives.

My original plan for the week of Jan. 27, 2025 was to build out a configuration window and a file export function. It got in my head to make access to these functions work the way many Gnome apps work on Linux. People call it a 'hamburger menu'. I guess it looks like a hamburger. I don't know who came up with that term but the menu button has 3 horizontal lines. You click on it and additional functions are shown. Before I showed a configuration window, I wanted this window invoked the modern way.

Again, on Linux Gnome environments, many mainstream Gnome apps use a menu approach that is arguably more modern and streamlined. I thought I would try my hand in achieving this menu. I have done menus in other software platforms before. I always found it easy. I think the concepts in the Gnome world in as far as GTK makes sense and in many ways are simpler than what I have done on other platforms.

Keep in mind, it is not difficult to do menus in C++ and GTKMM except the information on how to do it using only C++ is not as clear versus the examples favoring embedded XML strings. I think the approach of embedding XML (or json or sql) is a fine concept and I have no problem with that with Microsoft WPF for example. However, sometimes you want to build your UI with only code and not extra tools for many reasons. Some of those reasons is to have better control over the way the UI comes together and streamline the way it compiles into an executable.

A snapshot in time version of the program source code is posted in the comments. I will continue to evolve this program and it will quickly mature into a very nice C++ program. I will have a future video that will go much more in-depth on the technology choices made in this project. I touched on that in earlier videos but a video is coming where this concept will be explained more in-depth.

00:00 Start
00:17 Linux Gnome Classic
01:16 Start simple
02:21 Test data - barcode sheet
03:12 Complete desktop GUI
04:37 C++ source code expansion
08:32 Clean technology
09:26 GUI layout on paper
10:56 GTK HeaderBar
17:11 Pure code C++ GTKMM HeaderBar
34:38 Officially the 4th Iteration
38:00 Pursuit of Perfection
38:25 Next iteration
40:20 Levels of inception
40:49 Software wisdom
44:00 Premeditated efficiency
45:00 Infinitude of consciousness
45:45 Wrap up

[michaelgautier]

Tip for watching the video. It shows real live screens that are not prepped for video. Best results if watching on the web is to watch in fullscreen mode. When watching in fullscreen, all the screens shown in the video and the code text is clear and visible.

[michaelgautier]

A C++ Journey into GTK HeaderBars, Native Menus, and Beyond

Imagine sitting at your Linux workstation, determined to craft a sleek, modern user interface for generating and managing barcodes. At first glance, it seems trivial—just place a few buttons, insert a menu, then call it a day. Yet from the accompanying video, you will see a creative odyssey unfolding. Beginning with a simplistic application and a test dataset of barcode sheets, the project quickly swells into a complete desktop GUI. Part of the C++ source code begins to expand in service of performance, modular design, while eschewing achieving a fluid interface without resorting to external `.ui` XML files. During the early minutes, “clean technology” emerges as a core principle—an embrace of minimal dependencies and direct code control but more broadly to pursue technology that is healthy.

While sketching GUI layouts on paper, the central puzzle soon comes into focus: how to integrate a GNOME-style “hamburger” menu directly into the native GTK HeaderBar. The documentation, replete with examples involving XML or the GTK Builder (app and/or builder API), left the pure C++ approach less than transparent. This is why the discussion dives into the intricacies of the HeaderBar, outlining the conceptual sequence necessary to embed menus at the window’s crown. At the crux of the quest crystallizes implementing GTKMM’s HeaderBar and Menu entirely in code. This approach, though time-intensive, is prized for streamlined executables, fewer external files, and a direct expression of the developer’s vision.

Admittedly, this does reek a bit of technical obsession. It took four or five days to refine a workable, purely C++ solution—an endeavor some might dismiss as quixotic. Why not simply surrender to the canonical XML-based route? The answer is philosophical as much as it is technical. I mention in the segment, Pursuit of Perfection, I hold that a guiding conviction is that software should not only function but should also be built upon a foundation of clarity, precision, and the developer’s deliberate control over every line of code. This stance champions deeper mastery over a framework that often nudges programmers toward rapid, ready-made solutions.

Software, as any seasoned engineer will attest, is an iterative art. As I conclude the conversation in the segment, the “Next iteration, ” I refer to incremental improvements and the ephemeral joy of refining an interface.

In reflective moments, I shift between raw technicalities toward broader insights. “Software wisdom” emerges as the capacity to balance short-term expedience with a bold, uncompromising vision. A more philosophical dimension unfolds: the notion that an intentional design—rooted in code-level control—can resonate with greater meaning. Just as mathematicians relish elegant proofs, or scientists prize reproducible experiments, software developers can take pleasure in a robust, minimalistic codebase that stands free from labyrinthine dependencies.

Ultimately, the menu “problem” was not rooted in code alone. Instead, it sprang from a broader tension between documentation biases and the developer’s preference for deeper technical autonomy. The goal? A GNOME-like, drop-down “hamburger” menu that seamlessly calls a configuration window—just as many flagship GNOME applications do—without the overhead of separate UI files or specialized markup. The final result: a singularly coded interface that respects Linux GNOME conventions while retaining full creative control.

Skeptics might question the wisdom of dedicating four to five days to a header and menu system. Yet, as the video illustrates, the pursuit of a modern, elegant solution can have wide-reaching implications. For instance, in exploring these functionalities, the developer encountered uncharted corners of GTK, gleaned insights that others may find life-saving in their own undertakings, and reaffirmed a timeless principle: clarity of architecture can outlast short-lived convenience.

Planned future content aims to delve deeper into the rationale behind these technology choices—expanding on broader C++ design decisions, exploring performance ramifications, and demonstrating how a thoroughly-coded UI fosters maintainable and scalable applications. A snapshot of the project’s source code discussed in this video is available in the video’s comments, and further iterations are imminent.

Those who traverse this nuanced path—wrestling directly with a framework’s bedrock—will find themselves in a position akin to mathematical explorers: discovering new ways to elegantly fit lines of logic, verifying each function’s behavior, and ultimately crafting a solution both practical and sophisticated. Despite the time cost, the developer’s unwavering insistence on “doing it the modern GNOME way” in pure C++ code stands as a testament to the virtue of methodical, system-level mastery—a virtue increasingly obscured in an age of drag-and-drop shortcuts.

If you, too, value complete authorship of your software’s interface, this tutorial-like narrative will guide you toward a deeper relationship with GTK, reminding you that mastery sometimes requires revisiting fundamentals. Yes, a menu might look deceptively simple at first glance, but every element in software can become an entry point to greater innovation—so long as you dare to ask the right questions and refuse easy shortcuts.

[michaelgautier]

When Even LLMs Falter: A Quest Beyond AI

As the situation became more disheartening, I took a moment to consult AI to see if it could address the problem on day 3. What I found is that not even AI could solve this particular problem. I ran into many barriers and nearly gave up. This is not the most difficult technical challenge I ever faced but it was the most confusing.

In an era where generative models promise to tackle nearly any coding conundrum, I found myself in a paradoxical situation: neither the leading large language models, “o1” nor “DeepSeek, ” nor even ChatGPT could produce a reliable C++ solution for pairing a GTK HeaderBar and Menu on the first attempt. Given my two years’ familiarity with LLMs, I understood that refining prompts would likely lead to further tangents rather than a definitive fix, especially since code examples illustrating this approach seem nonexistent in their training sets. If their knowledge base draws on the same official documentation that had already led me astray, how could they surmount its inherent gaps?

Confronting these limitations, I reverted to more direct, manual strategies. I combed through the source code for GTKMM, Gedit, and DevHelp, but each proved only marginally illuminating for the specific sequence I needed. Even the gtkmm demos, praised in the community for their clarity, could not supply the elusive, purely C++ sample that ensured the HeaderBar and Menu would integrate seamlessly without XML. Thus began a determined investigative effort—one that emphasized reading between the lines of official documentation, dissecting real-world projects, and continually experimenting with incremental code changes until I uncovered the correct approach.

Ironically, this outcome underscores a valuable lesson about AI-based tooling: while these models can be astonishingly adept at furnishing initial scaffolds or suggesting fresh angles on well-documented problems, they may remain stymied by niche technical tasks that hinge on subtle, under-specified sequences. My story, therefore, stands as a testament to the role human insight still plays in bridging documentation gaps, engineering inventive solutions, and—when all else fails—consulting the source itself.


Therefore, if Salesforce or any company says they don't need programmers because of AI. Well, I don't see it. Either they have locked down their development process such that it can be addressed by AI which subsequently limits innovation. Or, they are largely in maintenance mode in their platforms which, again, derives inhibited innovation. I have seen first hand that the marketing around AI does not meet the full requirements of reality. Experts and those growing into experts are still needed.

[michaelgautier]

Snapshot of the code described in this video.

[michaelgautier]

I produced an extensive article that describes these elements in detail.