Live data from Hacker News

LeanQt – GUI is here, Widgets are near

github.com

41–50 of 55 posts

Re: LeanQt – GUI is here, Widgets are near

#41
post #13
post #2

Looks useful! > 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 wonder how long it takes to compile on an RPi. I tried it once with the full Qt build and gave up :) Of course, I should have cross-compiled but I guess I didn't want it enough.

Takes about 10 minutes to build on a 3 GHz i7-2600K. So maybe an hour or two on an RPi?

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.

Re: LeanQt – GUI is here, Widgets are near

#42
post #12

Earlier quoted context omitted.

> 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); the same applies to datab…

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 functi…

> 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.

Re: LeanQt – GUI is here, Widgets are near

#43

Are there tools to evaluate (imperfectly) the percent of a binary that actually gets used? 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 wond…

That feels halting problem-esque.

Re: LeanQt – GUI is here, Widgets are near

#44
post #42

Earlier quoted context omitted.

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 functi…

> 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.

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.

Re: LeanQt – GUI is here, Widgets are near

#45
post #3

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 th…

> I have searched high and low for something better, here is one rabbit hole: https://www.areweguiyet.com 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.

There is also 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++.

Re: LeanQt – GUI is here, Widgets are near

#46

Are there tools to evaluate (imperfectly) the percent of a binary that actually gets used? 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 wond…

In an interview I can't find anymore a developer from Farbrausch said that they used such a method to optimize the .kkrieger demo and ended up having a bug in the main menu because while recording the coverage the user never scrolled to a certain main menu item. So once you scrolled there you couldn't scroll up anymore.

See my comment in the same parent: https://news.ycombinator.com/item?id=33575452

Re: LeanQt – GUI is here, Widgets are near

#47

Are there tools to evaluate (imperfectly) the percent of a binary that actually gets used? 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 wond…

That feels halting problem-esque.

It definitely is if you want a 100% correct and 100% certain answer. But if you accept 3 categories 1: this we know is used 2: this we know is not used, 3 this we don't know anything about, then it's doable.

Re: LeanQt – GUI is here, Widgets are near

#48

Earlier quoted context omitted.

See, I’d rather use Qt for the UI, rusqlite for data access, and Lua, Rhai, or an embedded JS engine for scripting.

Why, what is it going to bring you

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.

Re: LeanQt – GUI is here, Widgets are near

#49
post #47

Earlier quoted context omitted.

That feels halting problem-esque.

It definitely is if you want a 100% correct and 100% certain answer. But if you accept 3 categories 1: this we know is used 2: this we know is not used, 3 this we don't know anything about, then it's doable.

But (2) requires knowing everything the binary will do. You can’t know what something won’t do without knowing what it will do.

Re: LeanQt – GUI is here, Widgets are near

#50
post #47

Earlier quoted context omitted.

It definitely is if you want a 100% correct and 100% certain answer. But if you accept 3 categories 1: this we know is used 2: this we know is not used, 3 this we don't know anything about, then it's doable.

But (2) requires knowing everything the binary will do. You can’t know what something won’t do without knowing what it will do.

You can do (2) if you can tolerate false positives. For example, if a symbol isn't referenced literally elsewhere in the binary, consider it unused, but add a configuration option to keep it in case it is referenced dynamically. The JVM world has been doing this for years with ProGuard.
Post reply on HN