Just over two weeks ago, I made an article here on DEV about how I made an action video game with the Godot game engine during a global digital couple-month-long hackathon for teenagers named Stardance. An important part of the article was the prizes involved in participating in the hackathon, and how I earned a Bambu Lab A1 Mini 3D Printer because of my work. I also mentioned that I made some smaller projects before that one. The article is here: How I Built an Action Game with Godot During a Global Teen Hackathon with Prizes. Well, I guess I didn't mention my plans for what I would do after! This article is all about that!
I just very recently made MDEZ++ (mdez), a lightweight Markdown editor. It is built with C++20 and the Qt Framework for the need for speed. Instead of a WYSIWYG (What You See Is What You Get) editor, or the polar opposite, a raw Markdown editor with a separate option to render it, it renders the raw Markdown as you type it on the right side of the screen. There’s essentially no knowledge required to use MDEZ++, not even knowledge of Markdown syntax. This is because of the Format menu, which allows you to apply Markdown syntax by clicking on unambiguous buttons. It can even render HTML files too, with almost the same workflow as Markdown files. It can also edit any other plaintext file format, making it highly versatile.
While this project only took me 40 hours (10 less than the last project), these hours were definitely harder than my last project. I had to find unique solutions to some problems that traditionally can never be solved without embedding a resource-expensive, bulky Chromium instance into the rendering side, which would completely defeat the purpose of the project. Those types of issues all stem from Qt’s Markdown rendering. It applies some really weird rendering to Markdown. Two of these issues were blockquotes not having ANY special coloring, and the same with code blocks (not even a grey background). I solved those issues with unique, complex regexes. While brittle, they still seem to work.
I even had to work with permission issues for a while, especially while getting it ready for Flathub. And when I implemented the feature of clicking a link in the document to automatically open up a new tab with that content, I had to do so many conditionals to make sure the end user doesn’t see something ridiculously ambiguous as an error sent right to their screen, even for a C++ coder. Fun fact: it took over 100 lines of code to implement something as simple as that. And I then had to go back and make even more changes to make it work in unique environments, and when users enter a fake link.
I am so proud of myself for getting my project on Flathub. I had considered getting my last project (a video game in Godot) onto Flathub in the past, but I thought it would be a bit too hard for me. I was thinking, “Oh, imagine how many files I’ll need! A manifest, a metadata information file, CI/CD, human review, manual SHA256 sum changes in the manifest! There’s no way I’ll ever be able to do it!” But I definitely did it with this project! And it looks pretty good on there too!
When I look through the features section of my README (which I just recently updated), I don’t think of MDEZ++ as a small project made by an indie developer (I don’t like the word Indie for some reason; it just seems too culturally appealing in the sense of turning coding into some sort of a social media lifestyle), but rather, just as a professional-grade project. I can’t even imagine how I made something as complex as this. The features section has 12 points, which still skips over the non-cumbersome or medium-to-easy-difficulty features.
Even the Downloads & Installation section of the README has complexity greater than anything I have endeavored to do before. It has an introduction, two ways to run the Linux Setup Script I made (which has four options inside it), a download table containing an AppImage file, the Flathub webpage, a Windows executable, a WebAssembly download, and a webpage, then a note for Linux users, and a note for Windows users.
Even the Keyboard Shortcuts section and the Menu Tree section of the README were orchestrated with a degree of precision beyond what I thought I was capable of. They read more like documentation for Google Docs or Microsoft Word, rather than a one-man 40-hour C++20 Qt Markdown Editor.
And, I do admit, I had a lot of trouble with the GitHub Actions CI/CD Workflow. It’s 164 lines long. But the line count shouldn’t matter. It’s that I was dealing with one of the hardest things in all of computer science: compiling C++ using Qt in a CI/CD (sorry if that was anticlimactic, since you probably guessed it already).
But a harder trouble than the GitHub Actions CI/CD Workflow was that I was essentially a beginner to C++ before I started this project! I had briefly touched some C++ maybe a year or so ago, but in my mind, I was a complete beginner when I started MDEZ++. That was evident in my unfamiliarity with absolutely every single thing I had to do, and especially with those compiler errors (and segmentation faults, especially when implementing the ability to use a tabbed interface) I had never experienced before. But I powered through with those Qt Docs, and I did beautifully! But I still don’t think I know C++. I have only been working within the Qt ecosystem, which does a lot of stuff for you. It even has its own class for strings! Strings, of all things! The simplest things ever! All a string is is just characters stored in adjacent memory addresses with a character pointer to the first one, terminated with a null terminator character! (I know, I was describing a C-style string. That’s because my reliance on QStrings has made me not know the full definition of an std::string. I read up on that from a random coding slideshow presentation from some university that was probably used in one class like 20 years ago.)
With my unfamiliarity with the C++ coding language, I was debugging randomly for many hours on end. And I was even personally targeted by segmentation faults! Yes, personally! I didn’t even know about gdb (GNU Project Debugger) until a few days ago when I saw a random Reddit post. I was essentially thinking, “Which one of these lines looks most suspicious?” for most of my debugging of this project, which isn’t even the correct way to find a segmentation fault! (It’s usually the communication of multiple different things. But philosophically, that statement is always right, just not elaborated upon properly).
Sorry if this is reading like a whitepaper so far! When I started writing this, I had just gotten back from an intense bike ride. I had just essentially gone forward until I couldn’t go any further. That doesn't even include the ride back. So, my tone switches from fast and engaging to stone-cold, academic, very quickly. Or I could just be imagining that, especially considering my vocabulary is completely standard and non-domain-specific (I literally had to Google what an adjacent memory address was when I read it in that random coding slideshow for a college course from like 20 years ago, despite the fact I’m in Geometry! I was thinking something about opposite sides, not right next to each other!)
How to Use MDEZ++
When you open MDEZ++, you will see two panes: one on the left and one on the right. As you type Markdown on the left, it automatically renders on the right. The black bar separating them can be dragged with your cursor to resize the two panes.
Near the top of the window, there is a bar that contains all of the document tabs in the application. To create a new tab, click the + button on the far right side of the bar. The first tab will be automatically titled "Tab 1," and all subsequently created tabs will be titled accordingly. To delete a tab, click the red X next to the tab name. All other tab names will be automatically updated based on their new index caused by the deletion.
Arguably, the most important menu is the File menu. It consists of Open File, Save As, Save, Save All Files, Print, and Export as HTML buttons. The Save As, Save, Print, and Export buttons apply only to the selected tab. The Open File button will create a new tab to open the file in automatically, and that tab will be instantaneously selected for the user. The Save All Files button saves all of the documents from every single tab. If a tab has not already been saved, you will not be asked to set a save path when clicking the Save All Files button. Instead, only files that have already been saved, therefore giving them a save path, will be saved.
Another important menu is the Format menu, which contains many buttons that allow you to apply Markdown syntax without knowing Markdown. If text is selected, the syntax will be automatically applied to it. Whereas, selecting a syntax button with no text selected will apply the syntax with no text inside of it and automatically move your cursor to the appropriate location for you to continue typing. All of these buttons also have keyboard shortcuts that can be invoked from anywhere throughout the application. Below is a table that contains all of the syntax shortcuts in the Format menu.
| Format | Keyboard Shortcut | Description |
|---|---|---|
| Bold | Ctrl+B |
Insert bold text |
| Italic | Ctrl+I |
Insert italicized text |
| Heading 1 | Ctrl+Alt+1 |
Insert a level one heading |
| Heading 2 | Ctrl+Alt+2 |
Insert a level two heading |
| Heading 3 | Ctrl+Alt+3 |
Insert a level three heading |
| Horizontal Divider | Ctrl+D |
Insert horizontal divider |
| Block Quote | Ctrl+] |
Insert a block quote |
| Strikethrough | Alt+Shift+5 |
Insert strikethrough text |
| Link | Ctrl+K |
Insert a link |
| Image | Ctrl+Shift+I |
Insert an image |
| Code | Ctrl+\ |
Insert a code block |
| Inline Code | Ctrl+E |
Insert inline code |
MDEZ++ also contains a Settings Menu, which saves across application instances and is automatically applied to each and every tab. The first setting is the Autosave setting, which can be enabled or disabled and have its interval altered through a number input in seconds. Its default is to be disabled. There are also separate options for the font point size of the editor and the font point size for the rendering pane. For the font point size setting of the rendering pane, other elements will be scaled accordingly relative to the font point size provided. Another setting is the end-of-line character option, which lets you choose between UNIX / macOS (LF) and Windows (CRLF) line endings. The final two settings are toggles for line wrapping in the editor and showing fun facts after application initialization.
The End
Stardance was the first ever hackathon I ever participated in. And it is ending tomorrow, on Halloween, October 31, 2026. In the previous article, I was so happy about how I got a certificate that showed I did 70 hours of work with Stardance. Now that I am at 110 hours and it's officially wrapping up, I can really take a step back and think about how I grew as a result of my spontaneous joining of Hack Club and its associated hackathon. I have done so many things I never thought I would be able to do before because of the wide community, incentives, and support that Hack Club has to offer. And Stardance isn't just a one-off thing. They run many events like it. They are called YSWS (You Ship We Ship) and are always completely free to enter. They just about always have intriguing and, more importantly, useful prizes that will last you a lifetime.
Also, I mentioned how I got a Bambu Lab A1 Mini 3D Printer from my last project. Well, that's technically leaving out some stuff, at least now. I just recently got an RTL-SDR Blog v3 and an ESP32 Kit from the Stardance store with the rest of the Stardust after the project before this! They haven't arrived yet, but I'm anticipating! And, I still have a bunch of Stardust I am going to get when I ship this project, which will probably get me a lot of stuff from the store.
If you haven't already downloaded or even checked out MDEZ++ yet, feel free to. The GitHub Repository for MDEZ++ is here. Its Flathub page (for Linux users) is here. The Downloads & Installation section of the README can be found here. And, if you don't want to download or install it, you can always check out the WebAssembly version here on GitHub Pages. It is almost as good as the actual downloaded thing.
Top comments (1)
Forty hours for a Markdown editor that edits its own README is a neat loop. The Flathub permission work sounds like the least fun part.