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.
Yes, the wx core handles this really well. If the correct APIs are used, no or few changes to application code are necessary to handle HiDPI properly - definitely a very good aspect of wx.
> 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.
For me it remains unclear how the various sizes (MinSize, Size, BestSize and the size passed to the constructor/Create) interact with the sizer's decisions. From what I've seen a BestSize seems to more or less be treated like a MinSize, where the sizer will not continue to shrink a control if Size == BestSize.
How to correctly implement a re-flowing (where e.g. the width depends on the height, or vice versa) control is also unclear to me. wxTextCtrl does it, somehow, in a somewhat buggy way. I managed to do it but I doubt it's correct.
What I personally find weird is how sizers don't really compose - you can put sizers in sizers, but that's not what I mean: If the layout changes in a sub-sub-sub-panel, then just calling Layout() there won't usually be sufficient, you have to walk up the tree. In Qt for example I've never spend a single thought about what would change the layout and how or what needs to receive Layout calls, it's just 100 % automatic.
A combination of both of these is that I found wxScrolledWindow to be very tricky to get to work properly, even after spending a lot of time on it, I still end up with a dialog that takes a few frames to stop redrawing/changing its layout.
Another weird corner is wxCollapsiblePane.
I concede that a lot of this could be because I don't know enough about wx or because I'm too dense to understand it properly.
> Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
Thanks, that set me on the right track to work it out. Previously I only found extremely weird/convoluted solutions and older posts suggesting that wx doesn't do it for you (google: "wx clipboard html"). But wxDataObjectComposite with a wxHTMLDataObject and wxTextDataObject indeed "just works". Perhaps something for the docs as an example?
> 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.
Well yeah, but a WebView is a pretty heavy-handed approach if you just want to make a few words bold or insert a link or something like that. Also, Qt's approach works more universally (e.g. it also applies to the labels of check/radio boxes, buttons etc., and it also lets you do things like highlight a field in red when it contains an invalid input, like people are used to nowadays).
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.
Use wxFormBuilder if you find laying stuff out difficult.
I find the layout manager easier than Borland or MFC codebases I have had to use, that's for sure!
This is kind of a strawman, especially with wxPython. The basic widgets are native (like e.g. a button, text input, checkbox, combobox), yes, but most of the "advanced" widgets aren't (e.g. AUI, list and tree controls, which are not native on Gtk, dataview, propgrid, ...), and everything in wx.lib isn't (avoid wx.lib.agw btw.). Most of the latter category has no or limited support for Hi-DPI. Most of the latter neither feels nor looks native, to varying degrees.
Personally I find my opinion of wx has sort of evolved like an inverted parabola. It started off kinda low, because a lot of stuff has confusing names, things are done in mildly weird ways and stuff like the layout system works in mysterious ways. It reached a high point at "this is pretty ok". Kinda went downhill from there: the layout system is just a massive pita, basic things seem to be missing because they're basically not doable with that layout system (e.g. notice how there really isn't anything in wx which provides an automatically line-wrapping text/label widget), support for rich-text/HTML/markup is abysmal, the event system is a PITA, most of the advanced widgets have are barely usable from both a programmer's and a a user's point of view (wxPropertyGrid...), there is a distinct lack of APIs for system integration (try putting or getting HTML from/to the clipboard, which is a one-liner with Qt), somehow not-flicker-free drawing is still a thing in wx, and it is not taken to be granted, the menu system is the thinnest of wrappers around the lowest of common denominators; QAction/QMenu is a far superior system of interactions. There is a pattern to this; wx generally chooses to make something a "thin wrapper over lcd". Qt generally chooses to rather make a stable abstraction (works on OS 1, probably works on OS 2), and, well, abstract. Qt has Model/View, which can be a little intimidating if you use it for the first time, but it actually works really well. wx has wxListCtrl::OnGetItemText (it also has dataview since a few versions, which is in the odd place of "way more complicated than a callback, not nearly as good as Qt MV"). Qt has QAction, wx has... wxMenu::Append. wx's way of doing things definitely has advantages (for one thing, wx is far, far less code than Qt Widgets, and if the controls you are using are native, everything truly is native, though this arguably doesn't matter any more).
FWIW I probably struggled more with layouts in a single wx project in a few months than I've done in all Qt and web experience prior to that. There are just so many weird happenings which just... don't exist outside wx.