Developer Blog - wxWidgets

Developer Blog - wxWidgets
Skip to content
Developer Blog
Planning Ahead
Posted on
December 15, 2025
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
wxStyledTextCtrl
and automatically synchronized with it. It is very simple
to use, as it’s usually enough to just create it, see the updated
stc
sample 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
wxAuiPaneInfo
class 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
wxGLCanvas
in 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
wxStaticText
has 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!
Comments
Linux Power
Posted on
February 12, 2025
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
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
...
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
new
MyFrame
();
->
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!
Comments
Hello Darkness
Posted on
October 29, 2024
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
#include
#include
#include
#include
class
MyApp
public
wxApp
public:
bool
OnInit
()
override
// ❶ SetAppearance(Appearance::System);
auto
new
wxFrame
nullptr
wxID_ANY
"wxWidgets Example"
);
auto
new
wxGridSizer
);
->
Add
new
wxStaticText
wxID_ANY
"Hello, world!"
),
wxSizerFlags
().
Center
());
->
SetSizer
);
->
SetIcon
wxArtProvider
::
GetIcon
wxART_WX_LOGO
));
->
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!
Comments
Blog Archive
Quick Links
Hello World in wxWidgets
Online Manual
Community Wiki
Report a Bug
GitHub Repository
Development Roadmap
News RSS Feed
Developer Blog
Solutions