In the original Qt, the platform backends are in separate plugins. I have never understood the advantage of this, but it makes the deployment more complicated. LeanQt puts both the front and the backend in the same library. It is even easy to merge all parts of LeanQt into just one static or shared library.
Because sometimes it’s useful to support more than one in a single application. For example, on macOS you can ship and X11 or Quartz UI with different plugins (normally you’d use Quartz, but you could use X11 for remote display over SSH). I believe the key use case for this was to allow local and remote displays, where you’d use the X11/Wayland/Quartz/Win32 for local display and an HTTP / WebSocket / Canvas back end for remote display. This would let you run a Qt app on your desktop natively and also serve it for your mobile devices to use from a web browser.
I’m not sure the extent to which anyone has taken advantage of this, but it always makes me uncomfortable when people say ‘I don’t understand why this feature exists and so I’m going to remove it’.
Thanks. Last time I used Qt with the X11 binding on a Mac was twenty years ago. It’s still possible to compile an application with LeanQt so it works with X11 on Mac, as long as there is an xcb API on Mac (didn’t check). It would even be possible to statically link an application with both the xcb and cocoa integration to make them selectable at startup and still not using plugings for this. Concerning the use of desktop applications on mobile devices I’m sceptical; usually the look and feel is so different that you have to implement different GUIs for desktop and mobile, unless it’s a very simple application.
it always makes me uncomfortable when people say …
Well, it’s a good criterion for weeding out questionable features; my experience with Qt spans twenty years and a wide variety of application areas including CLI, server and embedded; if it’s not immediately obvious to me that it’s an important feature, I take the liberty of throwing it out. People can continue to use original Qt if someone absolutely needs the feature.
I’m sure there are reasons why such plugin system exists. In fact, every line of code in the Qt codebase ended up there for a reason and, thus, can be reasoned about.
What I will say, however, from a plain ol’ FOSS developer standpoint (me) that has the reasonable wish to distribute his plain ol’ QtWidgets program in a statically compiled manner - this is unreasonably difficult to achieve with Qt and consequently I have spent/wasted many hours in this area … partly because of things like the plugin system that complicate the build process a lot while such feature(s) (seemingly) gain me nothing.
I am excited about LeanQt for this reason; it aims to make Qt development easy for the majority while those with ‘exotic’ requirements can use ‘the real Qt’.
I’m sure there are reasons why such plugin system exists.
There was a time when people thought that a modular program must be composed of dynamic libraries, or even by components in different processes with marshalled calls; anything else would have been called monolythic; but fashion trends come and go, and with each generation of developers priorities change.
distribute his plain ol’ QtWidgets program in a statically compiled manner
That’s easy to do with LeanQt; but it’s also easy to put all Qt in a single shared library to appease LGPL if need be.
while such feature(s) (seemingly) gain me nothing.
So there are already at least two people who see it that way.
I have been following this project since I first saw it posted here a few months ago. It’s very enticing to me as someone who finally gave into using Qt after years of resisting due to how (overly) complex and bloated I judged it to be. I noticed that you explicitly list web stuff as something you don’t plan to support - which makes sense to me on principle - however I was wondering if it would at all be practical to use QtWebEngine with LeanQt in the future. I have a custom HTML document organizer I’m working on, and using nothing “special” from Qt besides this WebEngine monstrosity -albeit, begrudgingly-.
Isn’t the QtWebEngine just a thin layer on top of Chromium (i.e. the Chromium Embedded Framework)? If so you could consider using something like Node.js with Electron (https://www.electronjs.org/), instead of Qt and C++, which is good at HTML and uses the Chromium means to design GUI applications. Building Chromium is quite an achievement itself including thousands of source files, which I wouldn’t want to integrate into LeanQt for many reasons. Qt itself has built-in support for HTML and richtext documents, even without QtWebEngine; but it’s not comparable to a full fledged browser; so depending on your needs you could use QDocument with QTextHtmlParser; I’m using it e.g. to import HTML documents into my outliner (https://github.com/rochus-keller/CrossLine).
Thanks for that info. I didn’t know about QTextHtmlParser, I’ll definitely be taking advantage of that.
Regarding QtWebEngine, my understanding is that it’s a stripped down build of Chromium that removes a lot of the extra garbage. It’s still not lean by any means, of course.
Because sometimes it’s useful to support more than one in a single application. For example, on macOS you can ship and X11 or Quartz UI with different plugins (normally you’d use Quartz, but you could use X11 for remote display over SSH). I believe the key use case for this was to allow local and remote displays, where you’d use the X11/Wayland/Quartz/Win32 for local display and an HTTP / WebSocket / Canvas back end for remote display. This would let you run a Qt app on your desktop natively and also serve it for your mobile devices to use from a web browser.
I’m not sure the extent to which anyone has taken advantage of this, but it always makes me uncomfortable when people say ‘I don’t understand why this feature exists and so I’m going to remove it’.
Thanks. Last time I used Qt with the X11 binding on a Mac was twenty years ago. It’s still possible to compile an application with LeanQt so it works with X11 on Mac, as long as there is an xcb API on Mac (didn’t check). It would even be possible to statically link an application with both the xcb and cocoa integration to make them selectable at startup and still not using plugings for this. Concerning the use of desktop applications on mobile devices I’m sceptical; usually the look and feel is so different that you have to implement different GUIs for desktop and mobile, unless it’s a very simple application.
Well, it’s a good criterion for weeding out questionable features; my experience with Qt spans twenty years and a wide variety of application areas including CLI, server and embedded; if it’s not immediately obvious to me that it’s an important feature, I take the liberty of throwing it out. People can continue to use original Qt if someone absolutely needs the feature.
I’m sure there are reasons why such plugin system exists. In fact, every line of code in the Qt codebase ended up there for a reason and, thus, can be reasoned about.
What I will say, however, from a plain ol’ FOSS developer standpoint (me) that has the reasonable wish to distribute his plain ol’ QtWidgets program in a statically compiled manner - this is unreasonably difficult to achieve with Qt and consequently I have spent/wasted many hours in this area … partly because of things like the plugin system that complicate the build process a lot while such feature(s) (seemingly) gain me nothing.
I am excited about LeanQt for this reason; it aims to make Qt development easy for the majority while those with ‘exotic’ requirements can use ‘the real Qt’.
There was a time when people thought that a modular program must be composed of dynamic libraries, or even by components in different processes with marshalled calls; anything else would have been called monolythic; but fashion trends come and go, and with each generation of developers priorities change.
That’s easy to do with LeanQt; but it’s also easy to put all Qt in a single shared library to appease LGPL if need be.
So there are already at least two people who see it that way.
:(
I have been following this project since I first saw it posted here a few months ago. It’s very enticing to me as someone who finally gave into using Qt after years of resisting due to how (overly) complex and bloated I judged it to be. I noticed that you explicitly list web stuff as something you don’t plan to support - which makes sense to me on principle - however I was wondering if it would at all be practical to use QtWebEngine with LeanQt in the future. I have a custom HTML document organizer I’m working on, and using nothing “special” from Qt besides this WebEngine monstrosity -albeit, begrudgingly-.
Isn’t the QtWebEngine just a thin layer on top of Chromium (i.e. the Chromium Embedded Framework)? If so you could consider using something like Node.js with Electron (https://www.electronjs.org/), instead of Qt and C++, which is good at HTML and uses the Chromium means to design GUI applications. Building Chromium is quite an achievement itself including thousands of source files, which I wouldn’t want to integrate into LeanQt for many reasons. Qt itself has built-in support for HTML and richtext documents, even without QtWebEngine; but it’s not comparable to a full fledged browser; so depending on your needs you could use QDocument with QTextHtmlParser; I’m using it e.g. to import HTML documents into my outliner (https://github.com/rochus-keller/CrossLine).
Thanks for that info. I didn’t know about QTextHtmlParser, I’ll definitely be taking advantage of that. Regarding QtWebEngine, my understanding is that it’s a stripped down build of Chromium that removes a lot of the extra garbage. It’s still not lean by any means, of course.