Developer Blog

GitHub Action for Projects Using MSVC

Posted on November 12, 2026

There is a new GitHub action for setting up wxWidgets in projects built with MSVC using the officially recommended way, i.e. by importing the wxwidgets.props file.

If your project does this, its workflow on GitHub Actions simply needs to add

      - name: Set up wxWidgets
        uses: wxWidgets/setup-wxwidgets-msvc@v1
        with:
          ref: v3.3.4

to its job and then it can just use

      - name: Set up MSBuild
        uses: microsoft/setup-msbuild@v3

      - name: Build
        run: |
          msbuild -noLogo -maxCpuCount `
            -property:Configuration=Release -property:Platform=x64 `
            MyProject.sln

to build the project itself.

See the action README for more information about the other possible inputs (notably toolset which should be set if the project doesn’t use the default one for the image), but the above is enough for many cases and takes care of building wxWidgets and, importantly, caching it for the subsequent builds, so that it won’t be rebuilt every time the application is built.

Comments

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 <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!

Comments

Blog Archive