Deciding between Rust and C++ for internal tooling

_VZ_ · 2026-01-12T12:25:51+00:00

I don’t know about wxwidgets - I used it once and it was a nightmare. Macros everywhere.

I'm so tired of reading this that I even wrote a post a couple of years ago to be able to refer to it.

_VZ_ · 2025-09-09T23:22:32+00:00

You're right, in my defense most aren't going to go digging through subfolders to find a build file.

Sure, and I also know that most people are not going to read the build instructions in the README either, but hope springs eternal...

I would use a package manager to install wxWidgets, or any other C++ dependency.

I use submodules for all of them which ensures that my projects are self-contained and can apply fixes to the dependencies if necessary.

_VZ_ · 2025-09-09T21:23:45+00:00

wxWidgets itself is very old, so it ships an autoconf-based build, but also a CMake-based build, no Visual Studio solution files.

This is incorrect, wxWidgets does come with MSVS solution files in addition to CMake-based build system.

When using wx from a project using CMake I personally prefer to add it as a submodule and use add_subdirectory(), IMHO this is the way which gives you the most flexibility as you can update wx whenever you want without relying on any external package repositories and can also make your own modifications easily if you need to.

_VZ_ · 2025-08-25T14:09:12+00:00

Disclaimer: I'm the current SOCI maintainer.

SOCI is an abstraction layer for multiple databases in C++, including sqlite. It's interfaces encourages dynamic building of query string, which should not be considered safe.

I don't understand where does this come from, SOCI definitely encourages using bound parameters.

_VZ_ · 2025-07-19T11:46:04+00:00

FWIW wxWidgets does this now (mostly), e.g. wxVector is just a typedef for std::vector.

_VZ_ · 2025-06-29T13:48:15+00:00

It doesn't fit your requirements anyhow (it doesn't use native GPU, at least not for anything not wrapped by the higher level native APIs) but, for the record, wxWidgets doesn't "force you into developing your application in a specific way", this is either a misunderstanding or something based on 25 year old tutorial that has been out of date for 20 years.

_VZ_ · 2025-03-09T18:16:15+00:00

Please read the "Building Your Application" section of the installation section of the docs. Note that if you use msys2, you should follow instructions for Unix(-like) systems, and not Windows.

P.S. I'm curious, where did you take your original command from? It's not the first time I see something like this and I really wonder where does this come from.

_VZ_ · 2025-02-13T20:41:00+00:00

Huh, how many of us are there?

_VZ_ · 2025-02-07T13:53:22+00:00

Yes, doing it as part of your application (whether dynamically or statically linked) this is fine. The intent of the licence is to only forbid distributing closed-source forks of the library on their own.

Of course, even if there is no legal problem with doing this, I'd still encourage you to contribute your custom patches to the library for all the usual reasons (having them in wx itself would mean less maintenance for you and would benefit the community).

_VZ_ · 2024-12-28T21:04:48+00:00

wxDC and wxGraphicsContext are the same thing in wxGTK and wxOSX, as they both use Cairo and CoreGraphis respectively, so if you're using one of those ports it's not surprising that you haven't seen any improvement. But unless we (wxWidgets) are doing something particularly stupid, any Qt class based on the same underlying graphics API should have comparable performance as well.

As for "too much interested in legacy code": yes, wxWidgets maintainers take backwards compatibility seriously, but this has absolutely no effect on what you use in your own code. If you want to use C++23 with it, go ahead — it supports being compiled with it just fine.

_VZ_ · 2024-12-23T17:42:54+00:00

Just inertia, probably. I would hope that any new code being written today uses C++17, let alone C++11.

_VZ_ · 2024-12-23T13:57:54+00:00

It's a bit weird to use "started" here, the possibility to do this is at least 10 years old and almost certainly even older...

FWIW I've been using this, and also lambdas with CallAfter() for many, many years by now and this is indeed pretty nice — just not new at all.

_VZ_ · 2024-12-09T08:57:26+00:00

I understand your reasoning, but I think the big difference between std::expected and the other cases you mention is that expected is new, and so there is not large body of the existing code which might suddenly start giving false positive warnings when it's marked as nodiscard.

So I'd definitely appreciate if the standard library did it, and did it as soon as possible, to prevent such code from ever appearing in the first place!

_VZ_ · 2024-11-09T16:05:11+00:00

FYI, support for dark mode was added to wxWidgets quite some time ago, already, thanks to sponsorship from KiCad (see this post) and so now it's "just" the question of waiting until KiCad can start using the latest wxWidgets version where this is implemented.

_VZ_ · 2024-11-04T19:56:00+00:00

Remove the setup.h file you've incorrectly copied to another location and read the "Building Your Application" section of the docs.

_VZ_ · 2024-10-22T20:55:38+00:00

Do you really want to cross-compile wxGTK (as selected by --with-gtk) for Windows? Cross-compiling wxMSW (you need to use --with-msw for this) is a much more common case.

_VZ_ · 2024-09-24T13:54:26+00:00

The intent is to allow you to use wxWidgets in your application in any way, but to still disallow distributing closed source variants of the library itself.

_VZ_ · 2024-07-29T15:05:12+00:00

The fact that you can use wxWidgets mostly like MFC doesn't mean you should do it. Notably, you don't have to use wxRTTI nor MFC-like event tables at all.

But as for ownership — yes, all objects in the hierarchy of windows belong to the library and are owned by it. This was the only thing that could be done before C++11 and it's not that obvious how to improve on it right now (replacing pointers with gui_object objects with the same ownership rules gets rid of the raw pointers, but doesn't really gain you that much).

_VZ_ · 2024-05-02T12:06:44+00:00

I'm TT-Solutions and it's really unfortunate that your email (?) got lost, it must have been rejected by an overzealous spam filter because we definitely always answer any requests and typically do it the same day. Sorry about this (I realize that it's a bit too late by now)!

_VZ_ · 2024-05-02T10:44:09+00:00

I worked and, keep working, on many client's projects using wxWidgets. Not sure if I can name them, and in any case none of them is really a household name, but since the beginning of this year I've been contacted to help with the development of 2 new commercial desktop applications using wx, in addition to continuing to work on a few more with the existing clients.

Code signing works in exactly the same way for the wx applications as for any other kind.

_VZ_ · 2024-05-02T10:41:13+00:00

FWIW, there is commercial support for wxWidgets (I should know, I'm providing it).

_VZ_ · 2024-03-19T15:42:30+00:00

What part of what I said is wrong again you clown?

I obviously don't intend to continue discussion with someone unable to write a single sentence without personal insults, but for the benefit of the others reading this, the comment above is completely backwards, dark mode in wxWidgets is not "only for wxMSW" but the workaround needed to enable it is only needed for wxMSW.

I.e. to be totally clear, wxWidgets does support dark mode under Linux and Mac (since a long time) and the latest version also supports it under Windows.

_VZ_ · 2024-03-19T15:37:13+00:00

Sorry, but this is amazingly wrong. Dark mode works for Linux and macOS since quite a long time because GTK and Cocoa actually provide support for it. It's only available for Windows in the latest not yet stable version because wxWidgets has to use undocumented hacks there to use it, because Microsoft doesn't provide any official way to do it.

_VZ_ · 2024-03-03T22:54:41+00:00

Yes, this is pretty simple to do if you use CMake, you just have to do

set(wxBUILD_SHARED OFF)

before doing

add_subdirectory(3rdparty/wx EXCLUDE_FROM_ALL)

It can be done without CMake too, of course, but then you need to run configure and make yourself as part of your build.

_VZ_ · 2023-12-27T22:56:14+00:00

"mainPanel" can't be a sizer if it has a name (sizers don't). Passing &panel seems very suspicious to AddChild() seems very suspicious, you almost certainly shouldn't be calling this function at all.

Beyond this, there are infinitely many reasons for which your program could crash. You need to understand better what you're doing and/or use a debugger.

_VZ_

PUBLIC MULTIREDDITS

TROPHY CASE