qtbase

If you don't keep it as a toy, it can get out of hand quickly. For example, here's the partial implementation of QWidget, almost 500k of code: https://github.com/qt/qtbase/blob/dev/src/widgets/kernel/qwi...

No, it implements its own functionality. As an example consider one of the most basic controls which is available pretty much everywhere (i.e. no need for polyfill), the push button: the source code[0] for QPushButton clearly implements the behavior itself, it does not rely on any native button. Compare with wxWidgets' equivalent to QPushButton, wxButton, where there is a backend-specific header[1] and implementation[2] where 99% of the wxButton functionality is there (there is a `btncmn.cpp` under `common` that is shared across backends but that has very little code itself). [0] https://github.com/qt/qtbase/blob/dev/src/widgets/widgets/qp... [1] https://github.com/wxWidgets/wxWidgets/blob/master/include/w... [2] https://github.com/wxWidgets/wxWidgets/blob/master/src/msw/b...

Qt also has a directfb backend (among many others: https://github.com/qt/qtbase/tree/dev/src/plugins/platforms)

QRhi + Qt3D & / QtQuick3D is pretty much the exact same goal than pygfx with a different implementation: https://github.com/qt/qtbase/tree/dev/src/gui/rhi ; https://doc.qt.io/qt-6/qt3d-index.html ; https://doc.qt.io/qt-6/qtquick3d-index.html ; QRhi itself pretty much sits at the "wgpu" abstraction layer. I've been using it for 4-ish years now in https://ossia.io (just the RHI part) Pros: - Integrates with Qt (of course). - Really really easy API compared to the average C++ API. - Works absolutely everywhere. - Many provided examples: https://github.com/qt/qtbase/tree/dev/tests/manual/rhi - Shader language is SPIRV-compatible GLSL 4.x thus it makes it fairly trivial to import existing GL shaders (one of my requirements was support for https://editor.isf.video shaders). Cons: - Was developed before Vulkan Dynamic Rendering was introduced s

Compared to any major UI library out there. Take QT for example: https://github.com/qt/qtbase/blob/5d1ded3359ee8bffa33a4b83d5... That ANT Table is not complex. QT has tons of legacy and supports way more features, yet, code is easier to grasp and maintain. Also, C# and WinForms, if you don't like C++: https://referencesource.microsoft.com/#System.Windows.Forms/...

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

This is literally false for Qt. Here's the code: https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/... Here's e.g. dolphin rendered with it here over ssh: https://imgur.com/bLnop55 > All of them except blitting pixmaps are basically not useful for a modern desktop. that's ridiculous. Most software is basically a succession of drawLines / drawRect calls with the occasional pixmap.

That looks extremely unfree, yes: https://github.com/qt/qtbase/blob/dev/LICENSE.LGPL3

Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc. Just having proper abstractions over each platform[1]'s: - windowing - KB/mouse/tablet/touch input - raster painting - 3D APIs (Vk, D3D, GL, Metal...) - text layout and rendering - support for accessibility APIs + things such as generic data models for tables and trees, etc... is already an immense amount of work, and you haven't even started drawing a single button yet. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms

> I've already said elsewhere that having read their licensing terms and limits on what parts and how it can be used I would not touch QT with the wooden pole. the OSS licensing terms are the LGPL or GPL. - https://github.com/qt/qtbase/blob/dev/LICENSE.GPL3 - https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3 - https://github.com/qt/qtdeclarative/blob/dev/LICENSE.GPL3 - https://github.com/qt/qtdeclarative/blob/dev/LICENSE.LGPLv3 they can add whatever separate licensing scheme they want in addition to that but if a repo has LICENSE.LGPLv3 in it, you can use it under LGPL like every other OSS project (and those two repos cover by far most of Qt, you can pretty much build an entire OS userspace out of them).

The only thing that matters license wise for 99% of people is https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3 which cannot be changed without renegotiating with KDE.

> Personally, I've tried a couple of times to read the license information on the Qt site and sort out how the licensing really works. You could just go to the repo and check the licenses there : https://github.com/qt/qtbase

https://github.com/qt/qtbase/blob/5.11/src/widgets/kernel/qw... is the largest no-nonsense C++ file I've ever seen https://github.com/borgbackup/borg/blob/master/src/borg/arch... ditto for Python Personally files this large become just very annoying overall. Code review tools tend to become slow on them (e.g. Gerrit is super-slow with files that are quite a bit smaller than qwidget.cpp), navigation is only possible via symbols, the import / include area becomes a huge mess (which also tends to generate constant merge conflicts, because imports are a common hot area for writes) etc.

Part of this is that UI toolkits do more and more disgusting things in order to preserve this behavior. Windows allows the foreground window to activate other windows "owned by the same app" so that existing applications don't break. The implementation, for this, of course, is a pile of heuristics [0]. Qt, steadfast in its duty to be as annoying as possible, pretends it is part of the foreground app when you call activate() by calling AttachThreadInput [1]. [0] Documented heuristics, even. https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... [1] https://github.com/qt/qtbase/blob/5.11/src/plugins/platforms...

> Is that because your code must be precompiled with moc before it's legal C++? That's... not how moc works at all. Moc parse your header files and generates additional cpp files from it which contain boilerplate for reflection and signals. So no static analyzer has any problem parsing Qt code... (I use cppcheck, coverity, clang-analyzer, clang-tidy) The "special" Qt keywords like signal, slot, etc... are just trivial macros: https://github.com/qt/qtbase/blob/5.10/src/corelib/kernel/qo... "signals" is just defined as "public", "slots" and "emit" as nothing. Your compiler compiles your source as-is. If you really don't like moc, there's a way to get its features natively with C++14 compilers (and uglier macros) : https://github.com/woboq/verdigris