VZ

wxRuby has been resurrected as wxRuby3, see https://mcorino.github.io/wxRuby3/

Among actively developed bindings, there is also wxRust at https://crates.io/crates/wxdragon

> wxWidgets is oldschool

It's a bit sad that a GUI library absolutely needs to be new and shining to be even considered nowadays, it looks like the whole programming world got infected by JS ecosystem anything-that-is-more-than-3-months-old-is-obsolete mindset.

The old that is strong does not wither.

You definitely should have been able to link statically, but my point was that these DLLs are already available on the wxWidgets site, you didn't need to upload them yourself...

Interesting that you've decided to provide your own wxWidgets DLLs instead of using the official ones (see https://www.wxwidgets.org/downloads/). Is there some reason for this or did you just not know about the existence of the latter?

Well, there is only so much latitude for naming the event (or message, callback, whatever) sent when a window needs to repaint itself. Qt has `paintEvent()` too and nobody calls it MFC-like AFAIK. IME people mostly think about event table macros when they say it.

This was indeed the case. In 1995. Since then just about everything has changed, but the idea that wxWidgets is MFC-like still refuses to die... Another common related opinion is that you have to use macros when using wxWidgets, which couldn't be further from truth since ~15 years (see https://wxwidgets.org/blog/2023/05/are-macros-required-to-us...) but, again, old impressions linger.

This is very similar to my memories of Sven too, except that I didn't even manage to buy him a beer remotely. Good for you to have done it!

> Still, they looked unusable.

This shouldn't be the case. If you use wx 3.0, it's too old to support the features that appeared in macOS after its release (dark mode etc), but 3.1.5 should look just as the native UIs do.

Best size is determined by each window. Min size is best size by default, but can be set to something different to override it. And the initial size is also min size by default, because this is what you'd expect: if you create a text entry wide enough for 50 characters, you don't want it to shrink to its best size which would be smaller. Generally speaking, it's best to avoid hardcoding any sizers (and definitely never use sizes in pixels).

For the relayout, the general principle is that it _always_ flows from top to bottom, i.e. changing anything for a child will _never_ affect the size of a (grand) parent. So you just need to call Layout() on the top-most window whose size you want to allow changing. Again, this might be too simple, perhaps, but at least it is simple and 100% consistent (well, wxCollapsiblePane just might be one of the very few exceptions...). I'm not sure how does Qt manage to avoid confusion if it propagates layout changes in both directions.

For markup, we do support it in wxGenericStaticText and several other controls, including buttons, checkboxes and wxDataViewCtrl which is quite enough for simple things like this. wxHtmlWindow is pretty nice for slightly more complicated stuff, even though it's just HTML 3.

Be the change you want to be! wxC did exist but grew unmaintained, split into several variants (I think at least wxHaskell and wxErlang had their own versions) and withered. It shouldn't be that difficult to revive it but, well, somebody does need to do it.

It's a bit funny that people don't realize that "they" are "you". wxWidgets is an old school open source project, people are supposed to contribute to it because they have their own itch to scratch.

FWIW wx has always been very friendly to new contributors, so I'd really encourage people who are annoyed by something in it to just propose changing them on wx-dev.

My answer at https://stackoverflow.com/a/19358996/15275 dates from 8 years ago but it's still relevant.

FWIW updating from 3.1.4 to 3.1.5 (and then to 3.2.0) should be pretty seamless.

The documentation does need work, but it's hard to find people volunteering to do it (although a few people do contribute to the docs too and this is something that is always very much appreciated). Any concrete suggestions for improvements are welcome as reports on https://trac.wxwidgets.org/newticket and, as you might have already realized by now, PRs to the docs on https://github.com/wxWidgets/wxWidgets/pulls are even more so.

Finally, asking questions (on the forum, users mailing list or SO) seems to work pretty well for most people.

Maybe this has something to do with the fact that Windows doesn't have dark mode for the desktop applications in the first place.

I can't say much for wxPython lib, but fixing high DPI support in native controls is the main focus of 3.2.0 and things look pretty good in 3.1.5 already IMHO.

I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.

Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.

Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).

More could be said about the other subjects, but these ones just seem like very obvious misconceptions, so I'd like to at least leave a record here to prevent the parent post from leaving a wrong impression.

It's neither a strength (there are definitely tons of things to do) but nor is it much of a weakness because the development is quite active pretty much all the time (just look at the commit history, PR merge rate or whatever).

The main problem with 3.2.0 is that, due to our commitment to ABI compatibility for even-numbered releases, we really want to cram as many new APIs into it as possible and this keeps pushing it further and further away. If nothing catastrophic happens, it should finally be released this autumn, whether we manage to finish all the planned features (see https://trac.wxwidgets.org/wiki/Roadmap) or not, but in the meanwhile you really shouldn't hesitate to use 3.1.x, the only unstable part of it is the ABI (_not_ API).

Nice chess GUI, BTW! (although I admit that I spend what little time I have for chess exclusively on Lichess nowadays).

I'd be interested to know what do you find rough about XRC (as wx XML layout system is known)?

> Well, let's verify that… https://i.imgur.com/uHfjoUs.png No, they're not.

Sorry, I don't know what is this supposed to prove, but I can definitely assure you that all the mentioned controls, and many others, are exactly native controls under the 3 first tier platforms (MSW, GTK and macOS).

> Do you have any proof?

Proof of absence of something is hard to make, all I can say is that you can go through MSDN, GTK and Cocoa documentation to convince yourself.

ECMerge seems to use standard wxToolBar which is definitely a native control, so I don't know why it has the same background on all the screenshots. Perhaps they've explicitly changed it to make them more similar, I really can't say. But if you create a toolbar out of the box, it will look exactly the same as in any other native application. As for the icons, wx does provide a limited set of stock icons, but this will almost never be enough, so you need to either get high quality icons in the style of each platform you support, which is obviously difficult for an open source/free program, or use the same, typically Linux-style, icons everywhere just because this is what is there, for free.

The rest of the controls (ribbon, tabs) are indeed non-native and there are no native equivalents for them, so there is not much to say here.

Generally speaking, there shouldn't be any problem with the colours unless you change them explicitly, which is a bad idea for the native controls. Not sure what is wrong with the padding and borders.

Sorry, but it was really surprising to see such an account of events. Just in case it's not obvious, and I realize that not everybody had a chance to be confronted by a giant corporation legal department in their lives, this was a rather traumatic experience and the original comment looked like revisionist history to me.

But yes, sure, I should have just let it pass instead of getting riled by someone being wrong on the Internet...

I've completely forgotten about this page of the site, but it's nothing but polite fiction. We didn't really have any choice in the matter, it was that or be dragged in court by Microsoft lawyers and after spending some of my own money (and I was a student back then, so it wasn't a small amount for me) on a consultation, I was told in no uncertain terms that this wouldn't result in a good outcome irrespectively of whether we could use "wxWindows" as the name or not.

As for "modest financial compensation", it was really modest and was meant to compensate for registrar fees/changing hosting/stuff like that. It was a couple of thousands at most, I think, nowhere near enough to sustain anything for any period of time.

There are many screenshots here, I'm not sure which one do you mean. But do keep in mind that some of these screenshots (maybe even most of them) are 10, or 20, years old, so what seems non-native to you today might be just the way things used to look.

Wow, you have some interesting sources (care to share them?). Microsoft _forced_ us to change the name, threatening unspecified but dire legal consequences if we didn't. They have never sustained anything at all.

> I submit that Wx implements its own non-native widgets.

It does for the widgets that have no native equivalent, such as draggable/dockable tabs/panels that you show. You can't say they differ from native ones because there is just no native version, on any platform.

OTOH all the standard UI elements (buttons, checkboxes, text controls, date pickers, ...) are native and not only they look natively, but also behave natively, which is pretty important and different from Qt.

Both Codelite and Code::Blocks are written using wxWidgets.

The really interesting thing would be to have a wx port using the native API for it, but unfortunately the last time I heard about wxBe was in the last century...

wxWidgets provides "wxColor" typedef too however and many functions exist in both "colour" and "color" versions. There would be just too many bug reports about misspellings in the API otherwise.