LeanQt – GUI is here, Widgets are near
github.com
github.com
Like, run an application, run the watcher tool, then “walk the application” as best as possible and get an output: “35% of the binary was never read.” ?
What’s on my mind is evaluating the actual result of tools and methods for not including unnecessary things. I struggle with this in web land. Tree shaking and such does a wonderful job but I honestly don’t know how much of my bundle is still superfluous.
The section called "A plan so insane, it might just work" describes what you mention.
I'm reminded of a Smalltalk hack called Spoon. It required two systems: a host system running the full Smalltalk with all its classes, and a target system which had the barest possible Smalltalk environment. Any time an attempt was made to access a class that didn't exist on the target system, it would ask the host system for that class and if available, download it in serialized bytecode form and run it. This may have worked at method level granularity -- i.e., classes were only populated with methods that were actually used on the target system -- I'm not sure. But the result was the target system only contained enough of Smalltalk to actually run the program.
> Solving a constraint satisfaction problem on a finite domain is an NP-complete problem in general.
https://en.wikipedia.org/wiki/Complexity_of_constraint_satis...
With the new gui, image and thirdparty modules, the uncompressed size of the source tree has grown to ~43 MB (10 MB zip compressed), with close to 3000 C/C++ files and more than 700 kSLOC.
LeanQt is designed to build only the modules you actually need.
..The resulting source tree has less than 800 files and requires only ~11 MB (2.6 MB zip compressed), and perfectly works as a substitute of the full source tree in this guide; see the attached LeanQt_core_only.zip file.
I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com
Many people are trying, but frustratingly, even in 2022 you could do a lot worse than QT.
If you really want to get depressed read about the internals of Servo (rip) and how they tried to render text.
No wonder something that calls itself lean is still somehow hundreds of thousands of lines.
if this was enough that's what we'd use though, no ?
While I like this project, I don't use half of the features it mentions in the supported features, and I use half of the features with no support planned so it's not an option for me ; i'd wager anyone not making todo apps has different set of requirements which leads to something like Qt which comes with everything. Simple example: no scripting support means pretty much that it's unuseable for any technical app e.g. in CAD/CAM or similar. No SQL means that it's unuseable for any kind of enterprisey CRUD client app.
It's mostly about concentration of responsibilities, or as they say on Unix: "do one thing and do it well". Scripting support can easily be delegated to other projects (LeanQt inherits meta and introspection facilities of Qt which make dynamic bindings easy to accomplish, see e.g. this one for Lua: https://github.com/rochus-keller/NAF/tree/master/Script2); the same applies to database integration and other topics.
Well, that's not particularly what the Unix philosophy is up to, unless Qt Sql is a separate project.
> use another JS engine but you'll just end up reimplement all the glue code that is in QJSEngine
There is no necessity to have it in the same project. And there is still original Qt if you want to have it all.
Some people are doing things that don't fit neatly in such frameworks, and when that happens, they're fighting against it rather than actually choosing what they want to code.
If it is so onerous that not having QtSQL is a deal killer, then it sounds like Qt has some weird problems with how it's API is designed preventing it from being flexible. Otherwise, if it it easy to load your own data in to Qt from whatever source, SQL or not, then not having QtSQL is fine, it just means an extra hour of coding and a little extra boilerplate, whoopdeedoo.
It is the nature of idealists that they see the world idealized. Smalltalk-80 itself has nearly 30 kSLOC (the low-level code for the VM adds another 5 to 10 kSLOC); it's just more difficult to count, but I wrote tools which can do it (https://github.com/rochus-keller/Smalltalk/).
But if we're really going to compare stuff.. Systemd alone is over 1 million lines. Probably X/Wayland as well. And the not-slim QT is probably going to end up over 1 million lines soon enough. There is a reason why this slim version exists.
That's at least two orders of magnitude difference in complexity. Maybe there's no getting around it but one has got to wonder whether things went horribly wrong somewhere.
For the people who are comfortable with even less, it's worth comparing it to the 1991 Ceres Oberon System, which has less than 14 kSLOC including the compiler and TUI.
I'm very interested in the KDAB/cxx-qt path from that page: https://github.com/KDAB/cxx-qt
Once they get Arm & Android coverage, that'll be my go-to solution. Rust for all business logic and remote synchronization. Qt/QML for display with accessors into the Rust model.
> LeanQt is a stripped-down Qt version which includes the essential features and is easy to build from source and to integrate with an application.
I think people working on cross compilation are wasting their time. They are trying to fix it "properly", separating build time dependency and run time dependency, because host system can't run cross compiled target binary. The obvious solution (what Scratchbox2 does) is for host system to run cross compiled target binary, instead of trying to "fix" the build system.
Especially since many ARM platforms are stuck on old libcs that are difficult to support.
The impressive thing is that the build instructions are like 3 lines long, and actually result in a working build. No drama, no specific compiler versions required, no CMake or autotools or other external crap, no dependency hell... just lots of cl.exe invocations scrolling by, followed by a command prompt.