telegram-qt VS Qt

That's where we're now. Those free services are all (relatively) new and they still need to get some hang, but they have some enough that some kind and smart people were interested enough to develop a desktop client. Yes, in the ideal world (or at least my ideal world) people would just remembered about KDE-Telepathy and restart their work. I had some hope a couple years ago but definitely one man just can't keep up with the huge amount of work it needs, not just in KDE-Telepathy but in upstream Telepathy. Hell, it's a miracle that things like Telegram-Qt still move, albeit very slow.

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

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.

Interestingly Qt has QPointer which nulls itself out when the target T is deleted. It's convenient when I want weak references to GUI objects (though you have to be careful to check for its presence after every time you call code which could possibly delete it, I usually call it QPointer maybe_foo). However, from my brief look at the source (link), it's implemented in terms of qsharedpointer.h-> qsharedpointer_impl.h and QtSharedPointer (not sure how it works, but there's probably overhead going on). I wonder how it works, and compares to generational indexes or Vale's generational references (link).

The tag is right there: https://github.com/qt/qtbase/tree/v5.15.4-lts-lgpl

Today I'm looking in to how the MSVC Development builds work. Yesterday I downloaded a version labeled 20220527 and from what I can tell, after looking at the source (another 3gb of disk space gone for now) https://github.com/qt/qtbase/commit/5d8f815e101da3ae9cd6a666cc097853f52b21da is the current commit.