Qt VS winsafe

Qt mono repo : .. you could check out all submodules and simply use CMake to exactly achieve this. A mono repo also means that if I only use qtbase and declarative, I would need to have all submodules in there? - No

For e.g. if you’re writing a framework, you need to interface with Cocoa on MacOS to draw windows, which only provides an Objective C or Swift interface. You can look at the Qt source code and see how they do it: https://github.com/qt/qtbase/tree/067b53864112c084587fa9a507eb4bde3d50a6e1/src/plugins/platforms/cocoa

That's because Qt 6 wholeheartedly converted to CMake for you. (At least it is better than qmake.) In order to support this Qt has this large battery of CMake files [1]. Qt is of course a clear outlier, but you can't expect the same level of support from every other library you want. My points about "anything exotic" still stand.

[1] https://github.com/qt/qtbase/tree/dev/cmake

What are you talking about? Qt has GTK theme support built-in: https://github.com/qt/qtbase/tree/dev/src/plugins/platformthemes/gtk3

This looks like the Qt bug solved by this commit: https://github.com/qt/qtbase/commit/acaabc9108dfe75530960cf8e3ec4f3602cd82e0

Yeah, I'm sure it's completely unheard of. Oh except that it took me all of a couple minutes to find an example of that exact thing in one of the largest, most commonly used C++ frameworks out there.

I don't see any connect in https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qsharedpointer_impl.h, and QPointer isn't a QObject (though I don't know if the latter is actually necessary for signal-slots). One (unreliable) way to test is to see if a QPointer fails to be nulled out when the QObject is blocked by a QSignalBlocker. Alternatively I'd set a data breakpoint on a QPointer and try it out. But I don't have the time right now.

I know all that shit because I'm the author of Rust's WinSafe library, which is a safer Rust layer over native Win32, so I had to deal with a lot of shit like this.

[dependencies] winsafe = { git = "https://github.com/rodrigocfd/winsafe", features = ["kernel"] }

Externally, you can write a lot of native Windows stuff in Rust already. Personally, I'm having a lot of fun with WinSafe.

If you had such problems (which I also had in the past), I'm really interested in you opinion about WinSafe, and if it could help you solving them.

If you're after a native Windows application, WinSafe may suit your needs.

As the author of WinSafe, I can say it's tedious sometimes, but it's often very challenging, because you have to translate crazy unsafe behaviors into Rust's ownership model. It's surely hard, but also very rewarding at the end.

As the author of the WinSafe lib, I wholeheartedly agree.

I don't know how rare this is (or how rare it should be), but this issue warned me about this potential problem, and I had to make a huge refactoring to treat the possibility. I had to rethink many aspects of all handle implementations. It was hard work, but in the end it was worth it.

WinSafe says hello.

WinSafe, for example (which attemps to be a safe layer over the Windows API), provides lots of RAII automations. A fine example is the BeginPaint function: