4 ms·

LeanQt – a stripped-down Qt version easy to build from source and to inte (cont)

45 points by whack 4y ago

slondr 4y ago
Interesting to fork an old version of Qt ostensibly to remove qmake when simply updating the version of Qt you use would also accomplish that goal. Personally I'm not sure I see the utility in this if something as baseline to typical Qt applications as QtWidgets is only a "long-term plan."
- signaru 4y ago
  For me, it's the GUI and widgets that is the reason for using Qt. So seeing these in "long-term plan" makes it less useful as a possible lean alternative (for me at least). But then again, I had experienced modifying some hardware SDK example that is just a console program, yet heavily dependent on Qt. Can't deny that there are a lot of useful non-GUI functionalities also bundled in Qt.
blondin 4y ago
a lean version of Qt sounds impossible to me. it's the nature of that particular beast. the available/planned features made me realize that the author and i have a different idea of "lean". i mean, threads, IO abstraction, collections... i have always wondered why Qt has a tendency of re-inventing everything. anyways, i hope it works out for their Oberon project.
- brnt 4y ago
  I'm hoping for a modern At, that integrates much better with modern C++(20+) and as a bonus does not have to bring half of STL's functionality anymore. Strangely using Qt in a modern C++ project is a huge pain, and their At for Python API feels much more lean and modern. It needs a similar refresh for modern C++.
  - pjmlp 4y ago
    Given the compiler support matrix, that is going to take a while, specially given clang current state.
- pjmlp 4y ago
  Because Qt is older than the STL, and also has cross platform abstractions that the C++ standard library might only get on 2050 or whatever.
- arinlen 4y ago
  > I mean, threads, IO abstraction, collections... i have always wondered why Qt has a tendency of re-inventing everything. Qt is a very well known cross-platform application development framework. Qt does not reinvent everything, it just provides basic cross-platform modules, much like Java, and modules that leverage Qt's basic features such as their signals-slots, event loop, multithreading support, etc.
- Rochus 4y ago
  > have a different idea of "lean" 10 MB (LeanQt) vs. 230 MB (Qt 5.6.3) source tree?
kayson 4y ago
I work with a couple of Qt-based applications on a day to day basis, and every time I interact with the applications engineers or R&D, it makes me think that Qt is a huge pain to work with. They take the forever to make any improvements or add new features, and the core application is still horribly buggy and unstable. Am I on the right track with Qt as the culprit or is it more of a legacy code or poor PM type thing? Curious what kind of experience HN folks have had using Qt.
- neodypsis 4y ago
  Qt is one of the most decent frameworks for developing quality Desktop GUIs. It probably is due to legacy or PM issues. That said, if I needed to develop a Desktop app nowadays, I'd probably give Flutter a try (https://flutter.dev/multi-platform/desktop https://flutter.dev/multi-platform/desktop).
  - kayson 4y ago
    I've been interested in flutter but it's still so new I'd be hesitant to commit to it. And the Google influence seems similarly risky to me, though if Go is any indication it hasn't been catastrophic. Curious how flutter compares to Qt in terms of performance if you've got intense 2D rendering.
    - neodypsis 4y ago
      Agreed. There's always the risk of Google ending the project. Qt has been around for decades.
      - joezydeco 4y ago
        If it's not Adwords-related, I wouldn't touch it. If a cloud service like IoT isn't safe then nothing is.
- saidinesh5 4y ago
  It's probably the old codebase. I have seen this kind of thing happen more often with old C++ codebases in general. Typically, the symptoms are: * They have no unit tests. No linters or other code quality checks. No CI at all. Gui testing is usually not automated in most places I worked at, but skipping out on CI tends to make the code suck extra hard in the long term. * They have to manually run 4-5 steps everytime to build and test the code they're working on. This kills the developer productivity instantly. * They don't manage the memory properly. They sprinkle new/malloc, delete/free everywhere. They use shared pointers everywhere. They probably implemented their own auto_ptr classes. It's hard to figure out who owns and frees an object in such code. It usually leads to very buggy and unstable applications. Qt complicates this even more because it comes with automatic life time management of QObjects (if you delete a parent, all the children get deleted). For me, I've worked with Qt on and off over the last 11 years or so. It's a mixed bag. For describing GUIs on embedded systems, i haven't seen anything better than QML/QtQuick so far. But because of the licensing situation with Qt, a lot of companies I've worked at still choose an old and outdated version of Qt (just like the above project which uses Qt 5.6), which means we reimplement the same functionality again and again. For cross platform desktop applications, Qt/C++ is still the most mature framework ice seen. I don't have that many complaints with Qt itself here. But C++ projects don't have a proper way to manage dependencies. No standardized build system. So I've seen annoying "solutions" like electron having less friction than Qt/C++ projects. Modern C++ and tooling solves a lot of these headaches. But you still have to use a lot of good but old C++ code that doesn't come with any of those goodies. So is say it's a mixed bag.
naturedivine 4y ago
Hoping to see AI rewrite big chunks of code while retaining the same functionality...
- LtWorf 4y ago
  Lol sure.
Am4TIfIsER0ppos 4y ago
"inte" what? "Integrate" I assume and I will make this comment before checking. Also me next question "does it have a C binding"?

45 points by whack 4y ago

Interesting to fork an old version of Qt ostensibly to remove qmake when simply updating the version of Qt you use would also accomplish that goal. Personally I'm not sure I see the utility in this if something as baseline to typical Qt applications as QtWidgets is only a "long-term plan."

signaru 4y ago
For me, it's the GUI and widgets that is the reason for using Qt. So seeing these in "long-term plan" makes it less useful as a possible lean alternative (for me at least). But then again, I had experienced modifying some hardware SDK example that is just a console program, yet heavily dependent on Qt. Can't deny that there are a lot of useful non-GUI functionalities also bundled in Qt.

blondin 4y ago

a lean version of Qt sounds impossible to me. it's the nature of that particular beast. the available/planned features made me realize that the author and i have a different idea of "lean". i mean, threads, IO abstraction, collections... i have always wondered why Qt has a tendency of re-inventing everything. anyways, i hope it works out for their Oberon project.

brnt 4y ago
I'm hoping for a modern At, that integrates much better with modern C++(20+) and as a bonus does not have to bring half of STL's functionality anymore. Strangely using Qt in a modern C++ project is a huge pain, and their At for Python API feels much more lean and modern. It needs a similar refresh for modern C++.
- pjmlp 4y ago
  Given the compiler support matrix, that is going to take a while, specially given clang current state.
pjmlp 4y ago
Because Qt is older than the STL, and also has cross platform abstractions that the C++ standard library might only get on 2050 or whatever.
arinlen 4y ago
> I mean, threads, IO abstraction, collections... i have always wondered why Qt has a tendency of re-inventing everything. Qt is a very well known cross-platform application development framework. Qt does not reinvent everything, it just provides basic cross-platform modules, much like Java, and modules that leverage Qt's basic features such as their signals-slots, event loop, multithreading support, etc.
Rochus 4y ago
> have a different idea of "lean" 10 MB (LeanQt) vs. 230 MB (Qt 5.6.3) source tree?

kayson 4y ago

I work with a couple of Qt-based applications on a day to day basis, and every time I interact with the applications engineers or R&D, it makes me think that Qt is a huge pain to work with. They take the forever to make any improvements or add new features, and the core application is still horribly buggy and unstable. Am I on the right track with Qt as the culprit or is it more of a legacy code or poor PM type thing? Curious what kind of experience HN folks have had using Qt.

neodypsis 4y ago
Qt is one of the most decent frameworks for developing quality Desktop GUIs. It probably is due to legacy or PM issues. That said, if I needed to develop a Desktop app nowadays, I'd probably give Flutter a try (https://flutter.dev/multi-platform/desktop https://flutter.dev/multi-platform/desktop).
- kayson 4y ago
  I've been interested in flutter but it's still so new I'd be hesitant to commit to it. And the Google influence seems similarly risky to me, though if Go is any indication it hasn't been catastrophic. Curious how flutter compares to Qt in terms of performance if you've got intense 2D rendering.
  - neodypsis 4y ago
    Agreed. There's always the risk of Google ending the project. Qt has been around for decades.
    - joezydeco 4y ago
      If it's not Adwords-related, I wouldn't touch it. If a cloud service like IoT isn't safe then nothing is.
saidinesh5 4y ago
It's probably the old codebase. I have seen this kind of thing happen more often with old C++ codebases in general. Typically, the symptoms are: * They have no unit tests. No linters or other code quality checks. No CI at all. Gui testing is usually not automated in most places I worked at, but skipping out on CI tends to make the code suck extra hard in the long term. * They have to manually run 4-5 steps everytime to build and test the code they're working on. This kills the developer productivity instantly. * They don't manage the memory properly. They sprinkle new/malloc, delete/free everywhere. They use shared pointers everywhere. They probably implemented their own auto_ptr classes. It's hard to figure out who owns and frees an object in such code. It usually leads to very buggy and unstable applications. Qt complicates this even more because it comes with automatic life time management of QObjects (if you delete a parent, all the children get deleted). For me, I've worked with Qt on and off over the last 11 years or so. It's a mixed bag. For describing GUIs on embedded systems, i haven't seen anything better than QML/QtQuick so far. But because of the licensing situation with Qt, a lot of companies I've worked at still choose an old and outdated version of Qt (just like the above project which uses Qt 5.6), which means we reimplement the same functionality again and again. For cross platform desktop applications, Qt/C++ is still the most mature framework ice seen. I don't have that many complaints with Qt itself here. But C++ projects don't have a proper way to manage dependencies. No standardized build system. So I've seen annoying "solutions" like electron having less friction than Qt/C++ projects. Modern C++ and tooling solves a lot of these headaches. But you still have to use a lot of good but old C++ code that doesn't come with any of those goodies. So is say it's a mixed bag.

naturedivine 4y ago

Hoping to see AI rewrite big chunks of code while retaining the same functionality...

LtWorf 4y ago
Lol sure.

Am4TIfIsER0ppos 4y ago

"inte" what? "Integrate" I assume and I will make this comment before checking. Also me next question "does it have a C binding"?