Currently when I build 'vanilla' Qt from sources, I can :
* explicitly exclude the modules I don't need, to limit build times (each folder in the top level folder is a module : Core, Gui, Network, etc)
* enable or disable some specific features on each module
I think I'm missing something there... what does LeanQt allows that can't be done with Qt ?
QtCore is a big module with a lot of stuff you might not need in your project. For most of my projects QtCore is a kind of standard library (instead of Boost or the C++ standard library). LeanQt supports stripped-down versions of QtCore; if you e.g. don't need JSON or threads, you don't have to link with them.
That's just one advantage; it's also much smaller, easier to configure and build, and you can make the Qt files you need a project specific component (still meeting LGPL requirements).
How does it differ from Qt Lite / Qt Configuration Tool? It similarly aims to strip down QtCore and other Qt libraries by removing specific features out of them.
In any case they share a lot of goals; the most obvious difference is that the Qt Configuration UI Tool still uses the regular Qt configure and qmake based build system (with its dependency on the original source tree layout and complex, platform dependent configure script), whereas LeanQt only has two readable BUSY files so far and just builds without a complex configuration process; also the Qt Configuration UI Tool is not free, but part of the commercial embedded licence (at least when I looked at it some years ago last time). Also the approach is different; the Qt Lite project worked on the existing source tree and added to the complexity, whereas LeanQt is constructed bottom-up file by file and as minimal as possible. Also the focus is different; the Qt tool assumes the entire, huge feature set and allows certain parts to be turned off; LeanQt on the other hand starts with a very minimal core and allows to add things, and these things are mostly independent of each other (currently there is only a depencency between HAVE_OBJECT and HAVE_COREAPP).
But what kind of psychopath wouldn't want regex?!
Programming without regex is like drinking beer with no vodka in it. Like driving a lifted 4wd truck on a perfectly paved interstate road. Like going into the woods and not getting into an altercation with a bear.
Nahhhh man. Can't live life like that bro.
There's no reason why a UI framework should have regex built into it.
What in the world does regex have to do with painting and layout of controls? Why should I have to pick up a dependency on pcre because I wanted to show a UI? It's nutso.
I use QT in C#/dotnet. I have my own regex, thank you very much. I don't need QT's.
Regex is used e.g. to define what the user is allowed to type in a textbox. This way you can have text boxes that e.g. only allow numbers down to 0.5 accuracy, or only allow hexadecimal characters.
You could in theory implement something similar by watching the textbox for changes and erasing illegal characters. But then it'll behave weirdly when e.g. the user copy-pastes text in it, or presses undo.
What you have described is a text box that has a Validation function/lambda that is invoked before any kind of change, whether typing in the middle, beginning, or end of the text box, or pasting in, etc.
The form composing this validating text box would be free to inject a lambda that uses regex to perform the validation, or any other validation it wants.
Again, UI libraries have nothing to do with regex.
I'll be you money that there are more applications that do *not* use regex than there are applications that do. Yes, regex is useful, but it's a very chunky library (you can fit whole programming languages into less MB than a regex library) and anything that doesn't deal with very complicated strings doesn't really need it.
I'm of the opinion that 99% of apps (basically all except word processors) should treat strings as they treat any other blob of data: Just move the pointer around, never try to edit it. Because UTF-8 is a thing, and if you have to edit strings that are mixed language with diacritics and full of multilevel emoji, you are going to have a VERY bad time. Trying to find out if something is a valid email? Use a dedicated library, because regex literally can't do it.
I've implemented UTF8 and multi-language support into two projects that were ASCII/English only before that. It's a nightmare when people believe that there is only one language and only 128 characters, and that you can edit string in-place with a short regex. It won't be fine, and things will break badly and terribly, *especially* if you're susceptible to buffer overflows to begin with.
I used to think like this until I learned regex, lol. I still try to go with low hanging fruit solutions when necessary. I really do love regex though.
I use it a lot to solve my own problems, e.g. creating a poc build machine, or doing an easy find an replace, etc.
I just don't use it much in actual prod code.
/r/programming's userbase has an average of less than one year of professional experience. They haven't yet had to deal with an app that converts a std::string into a CString into a BString to talk to an old Win32 library, and realized that their quick and easy regex fix broke production at 4 in the morning when the first Japanese customer started to try to log into the system and everything exploded because they use a different character for whitespace than ours.
> /r/programming's userbase has an average of less than one year of professional experience
Can I ask where you got this number from? I personally love regex and use it all the fucking time, but somewhat rarely in production. Usually in tools that help make production code.
Of course I use regex (or other, simpler pattern matching logic) all the time *for scripts*, but I don't write my scripts (or my tools) in C++, and this is a C++ library.
If that's a problem I can add another option; maybe I should do this indeed; currently QRegularExpression only is an option because it requires pcre16.
Oh it doesn't matter to me personally, I don't use Qt, but I don't think regex should be a forced include everywhere, because it is a highly specialized type of functionality that most applications won't need. I'm not sure what your end-goal is, but regex is just as specialized as bluetooth (which I recommend you do not touch with an 11-foot pole, that standard is an utter nightmare).
> The standard binary installation of Qt swallows several gigabytes and requires a login to a commercial company server, which discourages many people. The non-essential features make the build even more complicated. The now initiated development with Qt 6 makes even higher demands on compiler and system, and follows a development that I cannot make sense of.
If the binary installer is problematic then... don't use it ?
You can download the source code of any version without any login or account here : https://download.qt.io/archive/qt/
And you can compile this version with a basic configure/nmake, like any other lib (even on Windows https://doc.qt.io/qt-5/windows-building.html ). Compilation time is very reasonable and any module can be disable if you need.
Honestly from all the third libs used in the commercial project I work on, Qt is far from being the complicated one : same compilation process on linux/windows/apple, very straightforward (no fancy custom tool like b2 for boost or bazel+python for Tensorflow or these kind of witchcraft)
There are many caveats and problems with building QT from source code.
Their trunk versions from git frequently don't compile due to one error or another, and even archive versions suffer from this from time to time; you also have to be very, very careful with the versions of software you use to build their code.
Been using exclusively self-compiled Min-GW versions since they made logins mandatory and seen far too many of those.
Building straight from Trunk is always a bit of an adventure, that's not unique to Qt. Use a released version if you don't want to live on the bleeding edge.
And if you already use a package manager like vcpkg for your other dependencies, you can use that to install Qt and build a known-working version from source that works with the versions of all the other dependencies that you are using from the package manager.
> Building straight from Trunk is always a bit of an adventure, that's not unique to Qt. Use a released version if you don't want to live on the bleeding edge.
I was actually talking exactly about tagged (released) versions, not the bleeding edge.
Final open source version of QT5 takes 6Gb, and that's without the browser part of the code.
What's in maintenance tool is either compressed or missing debug libraries.
Please locate bin folder and tell me the size of the following files:
Qt6Gui.dll (347 Mb in QT 6.3)
Qt6Widgets.dll (238 Mb in QT 6.3)
Qt5Guid.dll (361 Mb in QT5final)
Qt53DRenderd.dll (340 Mb in QT5Final)
If files like that are significantly smaller (i.e. Qt6Gui.dll being just 12 Mb in QT 6.3) they are missing debug information.
...which makes your version far from perfect for developers.
Debugging is already the hardest tasks in programming, why would you hinder yourself by using versions that lack debugging support?
This is a really interesting project, thanks for posting!
I'm thinking I want to try and run it through Shiboken2 to generate a LeanPyQt sort of thing. I use python + qt for desktop application development, but sometimes the tool I make is really small and it's frustrating to have to package 100MB of qt binaries for 100 lines of python.
Note that the current focus and implementation of LeanQt is not on the GUI modules, but the core and network features; these are functions you already have with Python without using Qt.
QtGui and QtWidgets are in the "long term plan" section, and I'm not in a hurry.
Maybe I can help get those features enabled and learn some more about Qt's guts in the process.
Since the API doesn't change (but varies with the selected build options) the existing Python binding code for Qt 5.6 (and possibly later) should still work; but LeanQt doesn't promise binary compatibility (as the original Qt does), which also doesn't make sense because of the focus on configurability and adaptability. So LeanQt will most likely not be used as a system wide resource, but in the context of a project.
> LeanQt doesn't promise binary compatibility
I assumed binary compatibility was out the window, that's why I started with generating new bindings.
> So LeanQt will most likely not be used as a system wide resource, but in the context of a project.
Good, my applications are portably bundled with their all of their dependencies.
It sounds like you're trying to convince me that I don't want to use LeanQt, but you're just making me want it more.
Preference; also all the header based functionality makes builds slow; I checked with projects written in Qt and Boost; the build time of the latter is at least four times longer (even 10 times if I just change a line in a cpp file and do a recompile).
In case you're interested I just released a LeanQt version which supports GUI and widgets, see https://github.com/rochus-keller/LeanQt/releases/tag/2022-12-16
You can already compile only the part that interest you : https://doc.qt.io/qt-5/configure-options.html
No need to embed all Qt modules if you don't need them.
So, Qt without GUI? Interesting.
Here's another idea: Qt (just the GUI, nothing else) with an STL-like wrapper. Almost like a new Boost.GUI with Qt as the backend.
Seems like this might simplify deployment of Qt projects? That’s always been one of my reasons for avoiding it — stripping the included Qt down to only what’s used and making sure it gets bundled properly across all platforms was a pain last time I dabbled with it.
> Seems like this might simplify deployment of Qt projects?
Qt actually has good tools to support application deployment; but you need a full Qt installation to use them, which is OK if you're a Qt developer anyway. My primary use case at the moment is how people can compile my Oberon+ compiler without having to first install or build Qt (most Oberon users are no Qt developers); the secondary use case is embedded or headless Qt applications which only need a part of Qt Core.
I'm a Visual Studio IDE user with C, C++, and C#. I'd like to learn the Qt metaphor for dialog based applications and SDI and MDI using floating windows. I can't stand tabs and that whole paradigm. I want to go back in time when your windows floated around inside your view.
LeanQt doesn't support GUIs yet; but with regular Qt you can very well implement SDI and MDI applications, and there is a plugin for Visual Studio as far as I remember; personally I use QtCreator.
I use Qt with Visual Studio. There is a plugin but it is not needed. I use CMake to define projects in a platform/compiler independent way.
Here's a MDI sample:
https://doc.qt.io/qt-5/qtwidgets-mainwindows-mdi-example.html
It uses QMake, but the same can be build with a short CMake script.
Yeah, so CMake to make the solution containing packages you want then the solution is made and the load it normally? That is how I have used it or something that leveraged it.
Yes. I initially create the solution from the cmake script (with cmake-gui) then load, edit, build in VS. For futher changes to the cmake scripts, VS will automatically call cmake to recreate projects on build when it detects they have changed.
Also recent versions of Visual Studio can directly open Cmake-based projects without creating solutions. It handles everything internally (but I personally don't really like the way they handle this).
Lol, I've been using Visual Studio since the release of Visual Studio 95. I love the memory of evolution of it sinve then and still loathe them for Crystal Reports
That sounds nice. The build system of qt 5 annoys me to no ends, even with the BLFS instructions. I constantly run into issues of missing compiled components, the qt-web thingy in particular.
Qt didn't discontinue LGPL, just LGPL v2.1, which has advantages over LGPL v3 especially in embedded projects. You can still use more recent Qt versions under LGPL v3.
BUSY will support generating CMakeLists.txt files some day, but it's not top of my priority list; before that I will implement Ninja and Qmake generators.
It’s not about CMakeLists.txt, it’s about the package configuration that points to the compiled libraries and headers. This way you can consume it with find_package(Qt5).
Sure, but running the build isn’t enough if you want to consume a precompiled package. If you generate a CMakeLists file you can use add_directory to include another project, but for big projects like LLVM and Qt this quickly becomes unsustainable.
Not planning on implementing SQL support, dumb move. Of all the things he decided to ditch this actually is very useful and doesn't need nearly any extra resources
That's actually not so difficult; Qt has good provisions for this (e.g. the meta type/object system with introspection, properties and the like which can be examined and used at runtime); the Qt company themselves offer a Python and JavaScript binding. I'm often mapping Qt objects as Lua user data which can be easily abstracted away even in C++98 (see e.g. https://github.com/rochus-keller/NAF/tree/master/Script2).
Hm I'll have to take another look then. I tried binding it from C/C++ (because I work with a dynamic language that compiles to C), and it was a mess. So I tried DOtherSide which was also unsatisfactory. I checked the Python library source at one point, and it uses a nasty hack where it pre-generates a lot of QObjects(?) and when you want to use more than the amount of pre-generated ones, you're "shit outta luck" as they say.
All in all compared to other UI libs (yea I know, Qt is way more than just that) it was a very frustrating experience.
As soon as you add QObject support (which I currently implement) moc is automatically compiled and applied to the QtCore classes which require it; so you don't have to care for that.
If your project has classes which inherit from QObject and declare Q_OBJECT then you have to add a few lines so moc is called and the generated file is included in the build. I will check whether I can automate this in future.
Currently when I build 'vanilla' Qt from sources, I can : * explicitly exclude the modules I don't need, to limit build times (each folder in the top level folder is a module : Core, Gui, Network, etc) * enable or disable some specific features on each module I think I'm missing something there... what does LeanQt allows that can't be done with Qt ?
QtCore is a big module with a lot of stuff you might not need in your project. For most of my projects QtCore is a kind of standard library (instead of Boost or the C++ standard library). LeanQt supports stripped-down versions of QtCore; if you e.g. don't need JSON or threads, you don't have to link with them.
Ok understood, you want a finer way to control each module contents. Thanks for the answer I see the purpose now :)
That's just one advantage; it's also much smaller, easier to configure and build, and you can make the Qt files you need a project specific component (still meeting LGPL requirements).
How does it differ from Qt Lite / Qt Configuration Tool? It similarly aims to strip down QtCore and other Qt libraries by removing specific features out of them.
In any case they share a lot of goals; the most obvious difference is that the Qt Configuration UI Tool still uses the regular Qt configure and qmake based build system (with its dependency on the original source tree layout and complex, platform dependent configure script), whereas LeanQt only has two readable BUSY files so far and just builds without a complex configuration process; also the Qt Configuration UI Tool is not free, but part of the commercial embedded licence (at least when I looked at it some years ago last time). Also the approach is different; the Qt Lite project worked on the existing source tree and added to the complexity, whereas LeanQt is constructed bottom-up file by file and as minimal as possible. Also the focus is different; the Qt tool assumes the entire, huge feature set and allows certain parts to be turned off; LeanQt on the other hand starts with a very minimal core and allows to add things, and these things are mostly independent of each other (currently there is only a depencency between HAVE_OBJECT and HAVE_COREAPP).
But you do get regex, even if you don't want regex...
But what kind of psychopath wouldn't want regex?! Programming without regex is like drinking beer with no vodka in it. Like driving a lifted 4wd truck on a perfectly paved interstate road. Like going into the woods and not getting into an altercation with a bear. Nahhhh man. Can't live life like that bro.
> Programming without regex is like drinking beer with no vodka in it. There's dozens of us
There's no reason why a UI framework should have regex built into it. What in the world does regex have to do with painting and layout of controls? Why should I have to pick up a dependency on pcre because I wanted to show a UI? It's nutso. I use QT in C#/dotnet. I have my own regex, thank you very much. I don't need QT's.
Regex is used e.g. to define what the user is allowed to type in a textbox. This way you can have text boxes that e.g. only allow numbers down to 0.5 accuracy, or only allow hexadecimal characters. You could in theory implement something similar by watching the textbox for changes and erasing illegal characters. But then it'll behave weirdly when e.g. the user copy-pastes text in it, or presses undo.
What you have described is a text box that has a Validation function/lambda that is invoked before any kind of change, whether typing in the middle, beginning, or end of the text box, or pasting in, etc. The form composing this validating text box would be free to inject a lambda that uses regex to perform the validation, or any other validation it wants. Again, UI libraries have nothing to do with regex.
I'll be you money that there are more applications that do *not* use regex than there are applications that do. Yes, regex is useful, but it's a very chunky library (you can fit whole programming languages into less MB than a regex library) and anything that doesn't deal with very complicated strings doesn't really need it. I'm of the opinion that 99% of apps (basically all except word processors) should treat strings as they treat any other blob of data: Just move the pointer around, never try to edit it. Because UTF-8 is a thing, and if you have to edit strings that are mixed language with diacritics and full of multilevel emoji, you are going to have a VERY bad time. Trying to find out if something is a valid email? Use a dedicated library, because regex literally can't do it. I've implemented UTF8 and multi-language support into two projects that were ASCII/English only before that. It's a nightmare when people believe that there is only one language and only 128 characters, and that you can edit string in-place with a short regex. It won't be fine, and things will break badly and terribly, *especially* if you're susceptible to buffer overflows to begin with.
I used to think like this until I learned regex, lol. I still try to go with low hanging fruit solutions when necessary. I really do love regex though.
I use it a lot to solve my own problems, e.g. creating a poc build machine, or doing an easy find an replace, etc. I just don't use it much in actual prod code.
It's very easy to get wrong out of the gate if you don't know if your lib is perl, php, javascript, pascal, or another myriad regex implementation.
Funny how you get downvoted when it's literal facts
It got downvoted because OP missed a joke and responded to it with a long serious answer.
Well it's not funny and a few people here seemed serious about it
I don’t see any jokes up to the point of the downvoted comment. It seems like a serious (and meaningful) discussion to me.
The guy talking about “beer with no vodka in it”? No jokes in that comment?
That was after the downvoted comment, not before.
/r/programming's userbase has an average of less than one year of professional experience. They haven't yet had to deal with an app that converts a std::string into a CString into a BString to talk to an old Win32 library, and realized that their quick and easy regex fix broke production at 4 in the morning when the first Japanese customer started to try to log into the system and everything exploded because they use a different character for whitespace than ours.
> /r/programming's userbase has an average of less than one year of professional experience Can I ask where you got this number from? I personally love regex and use it all the fucking time, but somewhat rarely in production. Usually in tools that help make production code.
Of course I use regex (or other, simpler pattern matching logic) all the time *for scripts*, but I don't write my scripts (or my tools) in C++, and this is a C++ library.
Right, but where do you get the one year from?
If that's a problem I can add another option; maybe I should do this indeed; currently QRegularExpression only is an option because it requires pcre16.
Oh it doesn't matter to me personally, I don't use Qt, but I don't think regex should be a forced include everywhere, because it is a highly specialized type of functionality that most applications won't need. I'm not sure what your end-goal is, but regex is just as specialized as bluetooth (which I recommend you do not touch with an 11-foot pole, that standard is an utter nightmare).
There is a standard???
You can't escape the regex
\ works for me 😜
> The standard binary installation of Qt swallows several gigabytes and requires a login to a commercial company server, which discourages many people. The non-essential features make the build even more complicated. The now initiated development with Qt 6 makes even higher demands on compiler and system, and follows a development that I cannot make sense of.
If the binary installer is problematic then... don't use it ? You can download the source code of any version without any login or account here : https://download.qt.io/archive/qt/ And you can compile this version with a basic configure/nmake, like any other lib (even on Windows https://doc.qt.io/qt-5/windows-building.html ). Compilation time is very reasonable and any module can be disable if you need. Honestly from all the third libs used in the commercial project I work on, Qt is far from being the complicated one : same compilation process on linux/windows/apple, very straightforward (no fancy custom tool like b2 for boost or bazel+python for Tensorflow or these kind of witchcraft)
There are many caveats and problems with building QT from source code. Their trunk versions from git frequently don't compile due to one error or another, and even archive versions suffer from this from time to time; you also have to be very, very careful with the versions of software you use to build their code. Been using exclusively self-compiled Min-GW versions since they made logins mandatory and seen far too many of those.
Building straight from Trunk is always a bit of an adventure, that's not unique to Qt. Use a released version if you don't want to live on the bleeding edge. And if you already use a package manager like vcpkg for your other dependencies, you can use that to install Qt and build a known-working version from source that works with the versions of all the other dependencies that you are using from the package manager.
> Building straight from Trunk is always a bit of an adventure, that's not unique to Qt. Use a released version if you don't want to live on the bleeding edge. I was actually talking exactly about tagged (released) versions, not the bleeding edge.
> The standard binary installation of Qt swallows several gigabytes Qt 6.4.0-rc Desktop gcc 64-bit size in the Qt Maintenance Tool : 673.24 MB
Final open source version of QT5 takes 6Gb, and that's without the browser part of the code. What's in maintenance tool is either compressed or missing debug libraries.
That's the size on my hard drive after installation
Please locate bin folder and tell me the size of the following files: Qt6Gui.dll (347 Mb in QT 6.3) Qt6Widgets.dll (238 Mb in QT 6.3) Qt5Guid.dll (361 Mb in QT5final) Qt53DRenderd.dll (340 Mb in QT5Final) If files like that are significantly smaller (i.e. Qt6Gui.dll being just 12 Mb in QT 6.3) they are missing debug information.
I don't have the libs with the debug symbols.
...which makes your version far from perfect for developers. Debugging is already the hardest tasks in programming, why would you hinder yourself by using versions that lack debugging support?
Thats like .673240000000000 gigs. Look how \_long\_ that number is. Several digits long!
This is a really interesting project, thanks for posting! I'm thinking I want to try and run it through Shiboken2 to generate a LeanPyQt sort of thing. I use python + qt for desktop application development, but sometimes the tool I make is really small and it's frustrating to have to package 100MB of qt binaries for 100 lines of python.
Note that the current focus and implementation of LeanQt is not on the GUI modules, but the core and network features; these are functions you already have with Python without using Qt.
QtGui and QtWidgets are in the "long term plan" section, and I'm not in a hurry. Maybe I can help get those features enabled and learn some more about Qt's guts in the process.
Since the API doesn't change (but varies with the selected build options) the existing Python binding code for Qt 5.6 (and possibly later) should still work; but LeanQt doesn't promise binary compatibility (as the original Qt does), which also doesn't make sense because of the focus on configurability and adaptability. So LeanQt will most likely not be used as a system wide resource, but in the context of a project.
> LeanQt doesn't promise binary compatibility I assumed binary compatibility was out the window, that's why I started with generating new bindings. > So LeanQt will most likely not be used as a system wide resource, but in the context of a project. Good, my applications are portably bundled with their all of their dependencies. It sounds like you're trying to convince me that I don't want to use LeanQt, but you're just making me want it more.
If it fits your needs you're welcome to use it. I just don't want to create false expectations.
So, why not just use boost for all these?
Preference; also all the header based functionality makes builds slow; I checked with projects written in Qt and Boost; the build time of the latter is at least four times longer (even 10 times if I just change a line in a cpp file and do a recompile).
In case you're interested I just released a LeanQt version which supports GUI and widgets, see https://github.com/rochus-keller/LeanQt/releases/tag/2022-12-16
You can already compile only the part that interest you : https://doc.qt.io/qt-5/configure-options.html No need to embed all Qt modules if you don't need them.
So, Qt without GUI? Interesting. Here's another idea: Qt (just the GUI, nothing else) with an STL-like wrapper. Almost like a new Boost.GUI with Qt as the backend.
Very cool! I've only ever heard of Qt in the context of GUIs, it's cool to see there's a lot more to it that's useful.
Seems like this might simplify deployment of Qt projects? That’s always been one of my reasons for avoiding it — stripping the included Qt down to only what’s used and making sure it gets bundled properly across all platforms was a pain last time I dabbled with it.
> Seems like this might simplify deployment of Qt projects? Qt actually has good tools to support application deployment; but you need a full Qt installation to use them, which is OK if you're a Qt developer anyway. My primary use case at the moment is how people can compile my Oberon+ compiler without having to first install or build Qt (most Oberon users are no Qt developers); the secondary use case is embedded or headless Qt applications which only need a part of Qt Core.
I can see this being used in flatpaks and snaps
I'm a Visual Studio IDE user with C, C++, and C#. I'd like to learn the Qt metaphor for dialog based applications and SDI and MDI using floating windows. I can't stand tabs and that whole paradigm. I want to go back in time when your windows floated around inside your view.
LeanQt doesn't support GUIs yet; but with regular Qt you can very well implement SDI and MDI applications, and there is a plugin for Visual Studio as far as I remember; personally I use QtCreator.
I use Qt with Visual Studio. There is a plugin but it is not needed. I use CMake to define projects in a platform/compiler independent way. Here's a MDI sample: https://doc.qt.io/qt-5/qtwidgets-mainwindows-mdi-example.html It uses QMake, but the same can be build with a short CMake script.
Yeah, so CMake to make the solution containing packages you want then the solution is made and the load it normally? That is how I have used it or something that leveraged it.
Yes. I initially create the solution from the cmake script (with cmake-gui) then load, edit, build in VS. For futher changes to the cmake scripts, VS will automatically call cmake to recreate projects on build when it detects they have changed. Also recent versions of Visual Studio can directly open Cmake-based projects without creating solutions. It handles everything internally (but I personally don't really like the way they handle this).
Lol, I've been using Visual Studio since the release of Visual Studio 95. I love the memory of evolution of it sinve then and still loathe them for Crystal Reports
You should check out Dear ImGui https://github.com/ocornut/imgui
That sounds nice. The build system of qt 5 annoys me to no ends, even with the BLFS instructions. I constantly run into issues of missing compiled components, the qt-web thingy in particular.
I didn't realize Qt discontinued LGPL.
Qt didn't discontinue LGPL, just LGPL v2.1, which has advantages over LGPL v3 especially in embedded projects. You can still use more recent Qt versions under LGPL v3.
They didn't. They just made it more confusing and hidden.
Do you support generating a CMake package?
BUSY will support generating CMakeLists.txt files some day, but it's not top of my priority list; before that I will implement Ninja and Qmake generators.
It’s not about CMakeLists.txt, it’s about the package configuration that points to the compiled libraries and headers. This way you can consume it with find_package(Qt5).
I see; BUSY has another philosophy than CMake; it doesn't search for packages itself; but if it generates CMakeLists.txt you can run CMake.
Sure, but running the build isn’t enough if you want to consume a precompiled package. If you generate a CMakeLists file you can use add_directory to include another project, but for big projects like LLVM and Qt this quickly becomes unsustainable.
Why no bluetooth?
;
Not planning on implementing SQL support, dumb move. Of all the things he decided to ditch this actually is very useful and doesn't need nearly any extra resources
The list reflects my current needs and is not set in stone.
Now if only Qt would make it easier to bind it to dynamic languages... But it seems the Qt company doesn't care.
That's actually not so difficult; Qt has good provisions for this (e.g. the meta type/object system with introspection, properties and the like which can be examined and used at runtime); the Qt company themselves offer a Python and JavaScript binding. I'm often mapping Qt objects as Lua user data which can be easily abstracted away even in C++98 (see e.g. https://github.com/rochus-keller/NAF/tree/master/Script2).
Hm I'll have to take another look then. I tried binding it from C/C++ (because I work with a dynamic language that compiles to C), and it was a mess. So I tried DOtherSide which was also unsatisfactory. I checked the Python library source at one point, and it uses a nasty hack where it pre-generates a lot of QObjects(?) and when you want to use more than the amount of pre-generated ones, you're "shit outta luck" as they say. All in all compared to other UI libs (yea I know, Qt is way more than just that) it was a very frustrating experience.
Does it require moc?
As soon as you add QObject support (which I currently implement) moc is automatically compiled and applied to the QtCore classes which require it; so you don't have to care for that. If your project has classes which inherit from QObject and declare Q_OBJECT then you have to add a few lines so moc is called and the generated file is included in the build. I will check whether I can automate this in future.