Flamerobin 0.9.15 is released
Flamerobin 0.9.15 is released
Because making a single release at a time is too easy, today we're making 2 (two) new releases of #wxWidgets, an open-source #CplusPlus library for creating portable GUI applications, available at once:
https://wxwidgets.org/news/2026/03/wxwidgets-3.2.10-and-3.3.2-released/
3.2.10 is a small maintenance release, but 3.3.2 has too many improvements to list them here. If you want to start using wxWidgets in your applications, please use 3.3.2.
Here's an interesting #wxWidgets quirk: under #GTK 3 under #Wayland in #KDE, if a wxPopupWindow does _not_ have a parent, it will have a frame around it. Otherwise, it won't have one.
I don't think this is a bug or anything, I think it might just be behavior under Wayland. And yes, expect a draft PR with working undockable toolbars under Wayland for #Tenacity.
Curious
The left version is running in an opensuse distrobox, handles emojis properly, runs in X and doesn't respect the system theme.
The right version is running in a ubuntu distrobox, mangles the emoji, runs in wayland and respects dark mode.
Maybe they are using different frontends? #wxWidgets seems to support GTK3 and QT.
Can I find out somehow? I know the ubuntu package uses GTK, but the OpenSuse one won't tell me.
They look very similar.
I found a new thing to test in my ui-comparison project that I hadn't thought of until now: Grapheme clusters.
I implemented the tests for #wxWidgets today and noticed that I can move the text cursor in-between the codepoints of a multi-codepoint emoji.
E.g. If I enter "👮🏽♀️", I can use the cursor keys and space to pull it apart into "👮 🏽 ♀️"
That seems to be a limitation of the Win32 edit. Sure enough, if I try it on my win32 implementation, the same happens.
QT and SwiftUI seem to work though.
@noahebalon no question about that.
As @tantacrul acknowledged, #CreativeSoftware for most of it's users is a mere tool that has to function for their needs because most creatives neither have the time, spoons, skills (and frankly shouldn't have to have these for said useage to begin with!) but just want to get things done...
But then again I do have to both admire and congratulate on that endeavour because it's not just overdue, but a huge project.
2025 wasn't a great year, all things considered, but it was excellent if you use one very specific metric: number of #wxWidgets releases made, as we've just made the 6th (and hopefully last) release this year, see https://wxwidgets.org/news/2025/12/wxwidgets-3.2.9-released/, which is definitely the best we've ever done.
v3.2.9 doesn't bring anything very exciting but does fix a couple of bugs and, being ABI-compatible, is trivial to upgrade to, so please consider doing it.
And happy wx-release-free rest of the year!
I think I may have itsy-bitsy-tiny issue with attention… so around noon I saw some comment about browsers integrating tabs in window titlebar and it's basicaly CSD (client side decoration) and I started wondering if it can be done in #KDE / #Qt natively and then I jumped into the rabbithole of #Qt bindings in #Rust (to have relatively mostly 'native' looking widgets), made a short stop at #wxWidgets and played a bit with #wxdragon (https://docs.rs/crate/wxdragon/latest) just to move to #libui and #libui-rs (https://github.com/libui-rs/libui)…
Lovely afternoon… though completely missed what I had planned for it… xDDDD
Unfortunately, Tenacity's Flatpak remains on runtime version 24.08. We're looking to update it along with PortMidi inside the Flatpak so we're all up-to-date (mostly) on updates.
The other concern is wxWidgets, but we're holding off updating that because 1.3.4 can't build against wxWidgets 3.3+. The upcoming 1.3.5 release will, and it should also allow us to improve our default Flatpak permissions because #wxWidgets 3.3 got updated to use portals automatically via GTK!