LeanQt
BUSY
LeanQt | BUSY | |
---|---|---|
42 | 24 | |
558 | 80 | |
- | - | |
2.9 | 3.7 | |
about 1 month ago | 12 months ago | |
C++ | C | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
LeanQt
-
Ask HN: Do you stay away from Contributor Licence Agreements?
> Then do you (developers on HN) stay away from CLAs?
Depends on the CLA, but generally I do stay away. E.g. I never checked in anything to the official Qt repository because I don't agree the the CLA by QTC. Instead I finally made my own fork and call it LeanQt and LeanCreator (see https://github.com/rochus-keller/leanqt/ and https://github.com/rochus-keller/leancreator/).
The "weird licence which is basically a modified version of the MIT licence but with a clause that prevents competitive usage" is likely not even recognized as a true "open source" license.
> would it be possible to relicense a fork of Polaris to MIT (removing the Shopify clause?)
Likely not, because only the IP owner can determine who can do what with their IP under what license. If you use the software of an IP owner under a specific licence, you usually don't have the rights to re-license their work, even if you modified it.
-
Is Qt6 a good move?
My response to this question was https://github.com/rochus-keller/LeanQt, but I'm not using QML nor xmlpatterns.
-
Adventures in Debian's Qt Land
I made myself independent of the adventures in Qt Land by switching to https://github.com/rochus-keller/LeanQt.
-
Qt 5.15 Standard Support for Legacy License Holders Ends Today
https://github.com/rochus-keller/LeanQt
A minimum and easy to build fork of QT
-
I found Qt6 is so heavy to learn, can I just use it just like Qt4?
If you (like me) don't need all that stuff and are not up to the latest craze, have a look at LeanQt (https://github.com/rochus-keller/LeanQt).
-
Alternative widgets framework in qt?
Right. In the Gui module you have everything you need for this: platform independent windows and events, 2D bitmap and vector graphics, fonts and even rich text handling. Unfortunately there are some dependencies in Qt Gui to Qt Widgets, but if you use e.g. https://github.com/rochus-keller/leanqt/ instead of original Qt these are resolved. So with this you can implement your own widget toolkit on top of the Gui module if you want, and still benefit from the very powerful platform independent foundations of Qt.
-
Using Qt 6 under LGPLv3
> Qt for MCU [..] seems like a big advantage over Qt LGPL-3.0. I have my doubts. MCUs powerful enough to run Qt GUIs smoothly are more expensive than, say, an i.MX6ULL with a Cortex-A7 application processor and Linux. It’s a lot easier to find developers for an embedded Linux system ...
This is a very convincing argument. A Linux embedded system is also more flexible and the degree of code reusability is usually higher.
> Shall we use Qt LGPL-3.0 or Qt Commercial?
LeanQt (https://github.com/rochus-keller/leanqt/) is still available under LGPL v2.1. I will not switch to Qt 6 with my projects.
- LeanQt – Widgets are here, in time for the holidays
- Show HN: LeanQt Widgets, item and graphic views – GUI feature complete
- LeanQt: Widgets are ready - in time for the holidays
BUSY
-
Xz Backdoor and Autotools Insanity
CMake - as autotools - is a meta build system; it e.g. generates make files, which are essentially scripts. Also CMake itself is essentially a VM with a scripting language. Both CMake and Make are Turing complete (and dynamically typed, as mentioned). And yes, not all build systems are the same; e.g. https://github.com/rochus-keller/BUSY has a statically typed specification language and intentionally avoids a Turing complete language.
-
New build system for C/C++
> Have you coded the lexer/parser from scratch
Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c
and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c
and here is the specification: http://software.rochus-keller.ch/busy_spec.html
I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .
- What should be used to build the CPython of tomorrow?
- A simple shell based build tool for C/C++
-
Knit: Making a Better Make
If you haven't seen it: https://github.com/rochus-keller/BUSY
> BUSY is a lean, statically typed, cross-platform, easily bootstrappable build system for GCC, CLANG and MSVC inspired by Google GN
It uses lua and config files that are mostly directories and filenames.
-
Using Qt 6 under LGPLv3
> Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY) is used
It must be a rite of passage to make(!) one's own build system, damn
- BUSY lean build system with new Qmake backend
- Show HN: Busy build system now has a Qmake back end
- New BUSY build system, MVP release
What are some alternatives?
wa-tunnel - Tunneling Internet traffic over Whatsapp
scratch - Personal scratch code
nle - The NetHack Learning Environment
remake - Enhanced GNU Make - tracing, error reporting, debugging, profiling and more
slint - Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
shellb - Simple Shell based build tool
NAF - NMR Application Framework
GnTools - GN meta-build system parser, static code model and navigable code browser
crowd-jpeg
gtec-demo-framework
zfsbootmenu - ZFS Bootloader for root-on-ZFS systems with support for snapshots and native full disk encryption
nappgui - SDK for building cross-platform desktop apps in ANSI-C