4 ms·

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++ fi

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. Good. Not Alan Key 10kSLOC for the entire universe good. But certainly a step in the right direction. I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com 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.

jcelerier 4y ago
> Not Alan Key 10kSLOC for the entire universe good. 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.
- Rochus 4y ago
  > no scripting support ... No SQL 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); https://github.com/rochus-keller/NAF/tree/master/Script2); the same applies to database integration and other topics.
  - jcelerier 4y ago
    yes, and Qt SQL does one thing and does it well, which is getting SQL data in a format compatible with Qt's data model. You can do it by hand but you will just literally be reimplementing what is in QtSQL's module as soon as you want to display the result of queries in a table in your GUI. Same for scripting: the "meta and introspection facilities of Qt" are exactly what makes it possible to just call a member function or set a property of a C++ object from QJSEngine ; you can use another JS engine but you'll just end up reimplement all the glue code that is in QJSEngine, and for the sake of what? Having DLLs that start with another letter than Q?
    - Rochus 4y ago
      > and Qt SQL does one thing and does it well 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.
      - jcelerier 4y ago
        I don't understand why being in the same or a separate project matters at all. It's an entirely theoretical thing. The only actual meaningful question is if it is in the same shared library or not (and it isn't). Your CPU does not care that function A comes from company A and function B from company A or B when executing, it'll be the same code.
- ComputerGuru 4y ago
  See, I’d rather use Qt for the UI, rusqlite for data access, and Lua, Rhai, or an embedded JS engine for scripting.
  - jcelerier 4y ago
    Why, what is it going to bring you
    - redsaz 4y ago
      Sounds like (based on this thread of comments) that you're arguing that this should be a framework, where all the boring stuff is already taken care of, for run-of-the-mill, enterprisey projects. 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.
Rochus 4y ago
> 10kSLOC for the entire universe 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/ https://github.com/rochus-keller/Smalltalk/).
- recuter 4y ago
  Not at all being idealistic, this is a hard problem. 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.
  - robinsonb5 4y ago
    Oh they definitely went horribly wrong somewhere. And I suspect that shared sense is the reason so many alternative, niche, minimalist and retro projects are springing up. Personally I'm keeping a close eye on Haiku and SerenityOS as potential ports in the storm of ever-taller Jenga towers of dependencies and complexity...
  - Rochus 4y ago
    Well, to be fair Qt Core, Gui and Widgets can du much more than ST-80; there are more platform abstractions, things like threads and unicode, more and more powerful widgets, more powerful font and 2d drawing, etc.; it's not just the same functionality with a different number of SLOC. 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.
- smackmybishop 4y ago
  I suspect they're referring to VPRI's STEPS research, not Smalltalk. (And it was a target of 20k, not 10k.)
deleted 4y ago
[deleted]
TjZkxkxeky 4y ago
> I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com https://www.areweguiyet.com I'm very interested in the KDAB/cxx-qt path from that page: https://github.com/KDAB/cxx-qt 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.
- varajelle 4y ago
  There is also Slint: https://github.com/slint-ui/slint https://github.com/slint-ui/slint which is written entirely in rust. The UI is fairly similar to Qml. And you can have the logic in Rust or in C++.

jcelerier 4y ago

> Not Alan Key 10kSLOC for the entire universe good. 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.

Rochus 4y ago
> no scripting support ... No SQL 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); https://github.com/rochus-keller/NAF/tree/master/Script2); the same applies to database integration and other topics.
- jcelerier 4y ago
  yes, and Qt SQL does one thing and does it well, which is getting SQL data in a format compatible with Qt's data model. You can do it by hand but you will just literally be reimplementing what is in QtSQL's module as soon as you want to display the result of queries in a table in your GUI. Same for scripting: the "meta and introspection facilities of Qt" are exactly what makes it possible to just call a member function or set a property of a C++ object from QJSEngine ; you can use another JS engine but you'll just end up reimplement all the glue code that is in QJSEngine, and for the sake of what? Having DLLs that start with another letter than Q?
  - Rochus 4y ago
    > and Qt SQL does one thing and does it well 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.
    - jcelerier 4y ago
      I don't understand why being in the same or a separate project matters at all. It's an entirely theoretical thing. The only actual meaningful question is if it is in the same shared library or not (and it isn't). Your CPU does not care that function A comes from company A and function B from company A or B when executing, it'll be the same code.
ComputerGuru 4y ago
See, I’d rather use Qt for the UI, rusqlite for data access, and Lua, Rhai, or an embedded JS engine for scripting.
- jcelerier 4y ago
  Why, what is it going to bring you
  - redsaz 4y ago
    Sounds like (based on this thread of comments) that you're arguing that this should be a framework, where all the boring stuff is already taken care of, for run-of-the-mill, enterprisey projects. 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.

Rochus 4y ago

> 10kSLOC for the entire universe 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/ https://github.com/rochus-keller/Smalltalk/).

recuter 4y ago
Not at all being idealistic, this is a hard problem. 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.
- robinsonb5 4y ago
  Oh they definitely went horribly wrong somewhere. And I suspect that shared sense is the reason so many alternative, niche, minimalist and retro projects are springing up. Personally I'm keeping a close eye on Haiku and SerenityOS as potential ports in the storm of ever-taller Jenga towers of dependencies and complexity...
- Rochus 4y ago
  Well, to be fair Qt Core, Gui and Widgets can du much more than ST-80; there are more platform abstractions, things like threads and unicode, more and more powerful widgets, more powerful font and 2d drawing, etc.; it's not just the same functionality with a different number of SLOC. 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.
smackmybishop 4y ago
I suspect they're referring to VPRI's STEPS research, not Smalltalk. (And it was a target of 20k, not 10k.)

deleted 4y ago

[deleted]

TjZkxkxeky 4y ago

> I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com https://www.areweguiyet.com I'm very interested in the KDAB/cxx-qt path from that page: https://github.com/KDAB/cxx-qt 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.

varajelle 4y ago
There is also Slint: https://github.com/slint-ui/slint https://github.com/slint-ui/slint which is written entirely in rust. The UI is fairly similar to Qml. And you can have the logic in Rust or in C++.