Developer Blog
Planning Ahead
Posted on
It’s common to recapitulate the past year as it ends, but let’s do something different and, instead of looking back at the record 6 releases we made in 2025 (it helps to introduce some bugs in them, so as to require making bug fix releases soon after, but they still count), let’s see what is coming in 2026.
First of all, we are going to release 3.3.2 relatively soon, maybe in January but hopefully not later than February. This release will bring a few new features that are already implemented in master (and are eagerly awaiting being tested, so if you’re interested in using them, please consider checking them out even before this release):
-
There is the new wxStyledTextCtrlMiniMap class, which implements a small map, showing a scaled-down overview of the document being edited in the main
wxStyledTextCtrland automatically synchronized with it. It is very simple to use, as it’s usually enough to just create it, see the updatedstcsample for an example showing it, so there is not much to say about it, but it should be appreciated by the users. Thanks to GIANTS Software for the grant which allowed us to develop this feature! -
Another new UI feature is the support for minimizing panes in wxAUI into taskbar-like docking bars. This is, again, very simple to use from the application point of view, as it’s enough to just call MinimizeButton function of
wxAuiPaneInfoclass when creating the pane to enable it and everything else is handled automatically by wxAUI. However there are some customization options available already and we will probably add more of them before final 3.3.2 release, so please let us know what else would you like to be able to change. -
And the final relatively important recently implemented feature has nothing to do with the UI: it’s the possibility to choose between GLX and EGL-based implementations of
wxGLCanvasin wxGTK. Previously this choice had to be done at compile-time, meaning that applications were forced to use EGL, even when using X11 GTK backend, where using GLX would be possible. Now it is possible to call PreferGLX function to do it in this case. -
Of course, there were many other improvements and bug fixes since 3.3.1, in particular it is worth mentioning that all the third party libraries bundled with wxWidgets have been updated to their latest versions (thanks Maarten!), many bugs were fixed when using RTL writing direction (thanks Ali!), a few more classes were implemented in wxiOS (thanks Robert!) and
wxStaticTexthas finally learnt how to wrap its contents automatically.
After 3.3.2 we will start thinking about making 3.4.0 release, which will be the first stable release with dark mode support for Windows. Right now it looks like we may not even need a 3.3.3 before it, as no other major changes are currently planned, but this may, of course, change depending on the feedback we get after 3.3.2 release.
One thing that we unfortunately almost surely still won’t have in 3.4.0 is GTK 4 support in wxGTK. This is something that will become more and more necessary with time passing, of course, but upgrading from GTK 3 to GTK 4 is a major endeavour and we’re still looking for volunteers and/or grants to make it happen. But surely if we wait for long enough, we’ll just be able to ask an LLM to write wxGTK4 for us, right?
Let me close this forecast for 2026 on this optimistic note. Happy holidays and let’s all hope for a better next year, and not just for wxWidgets!
Linux Power
Posted on
This post is (unfortunately) not about secret Linux power features, but just
about handling wxPowerEvent with wxGTK under Linux. Until recently, such
events were only generated in wxMSW, but now that the corresponding PR
has been merged, wxEVT_POWER_SUSPENDED and wxEVT_POWER_RESUME can be
generated when using wxGTK as well – however there is a small twist. Unlike
under Microsoft Windows, they are not generated by default because trying to
do anything in wxEVT_POWER_SUSPENDED handler could fail due to a race
condition: the system might go to sleep before the handler finished its
execution. To prevent this from happening, the usual pattern is to acquire a
power lock, perform the required action when suspension notification is
received and then release the lock to let the system suspend.
So, in an attempt to be a good Linux desktop citizen, wxGTK doesn’t generate
these events until a wxPowerResourceBlocker object is created. However,
because the intention here is not to prevent the system from sleeping, but
just delay it for sufficiently long to allow the application event handler to
run, it should be created with the (new) wxPOWER_DELAY block kind instead
of the default wxPOWER_PREVENT one, e.g. like this:
wxPowerResourceBlocker delaySleep(wxPOWER_RESOURCE_SYSTEM,
_("Close open files"),
wxPOWER_DELAY)
The provided string is used to explain to the user why is sleep being delayed and appears e.g. in the output of systemd-inhibit tool.
Also, typically this variable would be a member variable of the application or main window class and not a local variable, so a program that wants to handle suspend/resume notifications should look like this:
#include <wx/wx.h>
class MyFrame : public wxFrame {
public:
MyFrame() :
wxFrame(nullptr, wxID_ANY, "My Power"),
m_delaySleep(wxPOWER_RESOURCE_SYSTEM, _("Save changes"), wxPOWER_DELAY)
{
Bind(wxEVT_POWER_SUSPENDED, [this](wxPowerEvent&) {
... save unsaved modifications to some temporary file ...
});
Bind(wxEVT_POWER_RESUME, [this](wxPowerEvent&) {
... restore modifications from the file, if it exists ...
});
...
}
private:
wxPowerResourceBlocker m_delaySleep;
};
class MyApp : public wxApp {
public:
bool OnInit() override { auto* f = new MyFrame(); f->Show(); }
};
This will also work in wxMSW, but there it would work even without
m_delaySleep while you need to create it when using wxGTK. And, of course,
this requires some minimum system support under Linux, but it should work at
least on all contemporary desktop systems using systemd.
Unfortunately power events are still not generated under macOS so, as always, further enhancements are still possible – and would be very welcome!
Hello Darkness
Posted on
wxWidgets 3.3.0 is not released yet, but there is no doubt about what will be the most important new feature in it when it does get released (hopefully some time soon): it will be support for dark mode in wxMSW, the Windows port of the library. This is “just” a cosmetic feature, but it’s also the most requested one since the entire history of wxWidgets existence, so it will be great to finally have it available, after all these years.
Of course, the delay hasn’t been just due to neglect of our users wishes. The main problem is that Microsoft still doesn’t officially support dark mode for the desktop Windows applications and so implementing it requires using undocumented API and also a huge amount of work on things not supported by those APIs, which are far from being complete.
I’m very grateful to KiCad organization for helping to solve the second part of the problem by funding my work on Windows dark mode implementation and, of course, also to all the other contributors who helped with reporting and fixing bugs. Thanks to them all, I believe that dark mode support is now in a good enough shape to be used in most applications, even though there are still some known problems, and, in fact, it’s already used in some of my own applications in production since quite some time.
However, due to the first problem, dark mode support is, and will remain, until Microsoft announces official support for it, disabled by default, and you will need to explicitly opt-in into using it. To give an example, this minimal wxWidgets application:
#include <wx/app.h>
#include <wx/artprov.h>
#include <wx/frame.h>
#include <wx/sizer.h>
#include <wx/stattext.h>
class MyApp : public wxApp {
public:
bool OnInit() override {
// ❶ SetAppearance(Appearance::System);
auto f = new wxFrame(nullptr, wxID_ANY, "wxWidgets Example");
auto s = new wxGridSizer(1);
s->Add(new wxStaticText(f, wxID_ANY, "Hello, world!"), wxSizerFlags().Center());
f->SetSizer(s);
f->SetIcon(wxArtProvider::GetIcon(wxART_WX_LOGO));
f->Show();
return true;
}
};
wxIMPLEMENT_APP(MyApp);
still has the same boring, old, tired appearance, even when the system uses
dark mode by default, shown on the left below. However by uncommenting the
line marked with ❶ in the beginning of OnInit() the appearance changes to
the modern, new, wired look on the right:
Of course, this assumes that the system uses the dark look by default. If it
doesn’t, the appearance would naturally stay the same, even with the
SetAppearance() call. As the documentation explains,
this function can also be used with Appearance::Dark argument to force the
use of dark mode or, to emphasize that dark mode is not wanted, with
Appearance::Light.
Also note that while calling SetAppearance() is required for dark mode
support under Windows, the situation under other platforms is a bit
different: because they do provide perfectly official and safe to use API for
the desktop applications, the system mode is used there by default and calling
SetAppearance(Appearance::System) doesn’t do anything there – however it
does no harm neither and using this function to force either dark or light
appearance works under the other platforms as expected too.
Finally, there is a semi-secret way of enabling dark mode support for Windows
applications even if they don’t call SetAppearance(): setting the
environment variable wx_msw_dark_mode to the value of 1 has the same effect
as opting in into using the system appearance, while setting it to 2 forces
the use of dark appearance. However, if the application does set its own
appearance, this overrides the environment variable value, so this trick is
really only supposed to be used for the older applications which haven’t been
updated to call SetAppearance() yet.
I’d like to end this post by repeating that everything described above is available in current Git master and while dark mode support will be included in wxWidgets 3.3.0 release, you are also more than welcome to try it already and report (and maybe help fix?) any problems you find!