Show HN: Procal: A simple Qt-based programming calculator
github.com
github.com
But it's probably very inefficient and I'd advice to just write a web app if you need a web app.
[1] https://play.google.com/store/apps/details?id=com.kebstudios...
> No; incorporating or linking against GPL requires that your project-as-a-whole be distributed under GPL. But you can include MIT licensed parts (or another GPL-compatible license) in the project. Also, it depends.
As the quoted part says: the project as a whole (which includes the library itself) need to be GPL, but part of it can be MIT. So the code of the program on GitHub can be MIT.
Under the GPL terms, the derived work becomes GPL (this is why people call GPL infectious or viral). The project may include unrelated MIT components alongside GPL components, but the project itself becomes GPL, along with any derived components (i.e. components making use of the GPL components). It’s kind of the entire point of the GPL. It’s also why we ended up with LGPL, which offers a linking exception.
The virality is something else: It is that you must disclose the source of the whole program that use a GPL only library. And you're doing that with MIT
It doesn't. It just doesn't give you permission to use the GPL licensed code unless you comply and use GPL.
you don't need to dual license it - either it's compatible with the GPL (MIT is) and then can be shipped as part of a GPL program, or it isn't and then you cannot distribute the complete program.
I didn’t say all of its components, I said components making use of GPL licensed components or code. His math code could totally be licensed MIT, depending on how the program is put together. His UI code is inextricably derivative of QT though — you can’t separate the two. So even if that code itself could be licensed MIT (which is not clear to me), practically speaking, it can only be used alongside the GPL component and thus in a GPL work.
In some few situations, I suppose the distinction could matter, though.
That said, does it even count since he's not distributing it (Qt) at all?
Its the whole reason PySide exists, to have a Qt Python library hat is LGPL to allow works that use it not have to be GPL like PyQt does.
> You must license the entire work, as a whole, under this License
"That is, their code can be combined with a program under the GPL without conflict, and the new combination would have the GPL applied to the whole (but the other license would not so apply)."
This is from when Qt still cared about LGPL, i.e. the Nokia days when the aim was to be the commercial-friendly Nokia SDK.
Then it was released under its own QPL license, and KDE negotiated that if Qt went bankrupt it would change to an MIT license.
Finally it was released as GPL.
FWIW, I think Gtk+ was independently extracted from Gimp as Gimp Toolkit, but KDE success drove GNOME creation based on LGPL-ed Gtk+, which, as you point out, later put pressure on Qt to be relicensed.
Both of these were struggling in the changing workstation/PC/mobile market, so I don't consider it against Gtk+: eg. Nokia was soon acquired by Microsoft and even Qt version barely hit the market.
Still, I do believe success of KDE and GNOME has had at least some of the effect on getting Qt LGPL-ed: there is little doubt KDE was great marketing for Qt (there was a plethora of Windows GUI toolkits: cross-platform, not so much).
OFC, I was in none of those boardrooms, so it's all speculative ;)
When it comes to Qt vs. GTK: I would guesstimate that at the peak, GTK+ perhaps had around 10 concurrent paid devs? The peak for Qt was in the 100s, from markets like embedded and automotive that GTK+ hasn't really been able to access (yes, I had all the Maemo devices too). And even for its core focus area, desktop apps, GTK+ hasn't seen a lot of adoption outside the Linux niche, whereas there's a seriously large amount of commercial Windows/Mac software using Qt. This is really what I meant.
Bottom line: Most PC users have a few copies of Qt on their computer, and perhaps own a device or two in their home and another in their garage that also has Qt on it. The same cannot be said for GTK+. A computer with GTK+ on it is relatively rare, perhaps in the tens of millions vs. billions.
It's also worth noting that users who migrate away from Qt do it to either Flutter (because of more permissive licensing - BSD - or mobile capabilities) or Electron (to share tech with their website) or Unity/Unreal (because of the rendering capabilities), but not to GTK+. Users who migrate away from GTK+ often migrate to Qt (e.g. Wireshark and a couple of others). I can't think of an example of anyone moving to GTK+ from really anything else (probably exists but likely minor). To me that means that while Qt has fierce competition, GTK+ is not really among it.
And it's certainly a valid claim that Qt is more omnipresent than Gtk+ today.
Thanks for the lovely chat, I enjoyed going back ~20 years :)
… but most importantly it can calculate with units and show the result converted to your liking e.g. you can write
10 Nm×2pi×20/minute to W and Qalculate will show the result as 209,4395102 W. When you get used to that, you don't want to use any calculator that doesn't have that feature any more.
e.g.
> 100 GB/minute to kB/s
I guess the reason I chose Qt over any web-based frameworks is I wanted a standalone app that would launch in a fraction of a second and just do its job. I don't think a webapp (if that's what they're called) would give me that. At the time, it seemed that Qt would work well and, as a bonus, be cross-platform. I had some Python experience to boot which helped.
Edit: I do have a personal site at https://www.fellerts.no/ but it's entirely static, no real js to speak of.
It's just that the Qt company always tries to make it non-clear that Qt is not open source to drive their sales.
Regarding bloat, Qt is quite modular and if you want just the widgets you only need QtBase and none of the additional modules.
I'd go 100% native because that's how you make the best app for that platform. I also enjoy working with different toolkits and if I wanted this on more than one platform, I think I would enjoy designing and building it for different environments. For example the version I'd make for my small screen touch-based phone would probably be significantly different than what I'd want on my keyboard and mouse equipped big screen desktop.
A multi-platform or web-based solution would have too many compromises.
I think instead of "truly reusable" I should have said something like "requires minimal configuration." I think Python's reflection capabilities allow one to supply less boilerplate when writing PyQt apps. This is just a subjective impression that I have, and unfortunately I am having trouble elaborating on this in a way that I think would be effective. That is why I asked the author what they thought, since I am wondering if anyone else has had this impression. However, I will think about this more, and I might provide more examples if I can think of them.
[1] https://pyapp-kit.github.io/superqt/widgets/qenumcombobox/
Neither JS nor Python really have types at runtime or any other time, but you can approximate them with Objects and/or Classes (of course, I repeat myself ;) ). With some TS magic you can even get the `setEnumClass` call to be well typed, though if I were building it from scratch I'd make the EnumClass prop immutable, too many weird corner cases otherwise.
I've never worked extensively with Qt myself, but when helping out a friend making Maya plugins in Qt we'd occasionally hit SEGFAULTS from writing seemingly mundane Python that'd crash all of Maya. That was enough to turn me off of it, but looking through the docs you linked there are some compelling components. It's nice to have a component library separated from a specific framework (in the React/VUE/etc. sense)... I don't know of any in JS. Every framework seems to think their (incompatibile with everything else) approach to reactivity is the hold grail, and being modular across it would be impossible.
Though reconsidering, I suppose Qt is sorta the same... it's just another framework and their "signals" aren't Python. Ah well.
Diving deeper, signals are weird... they aren't even really part of the underlying C++! Some sort of strange new modifier Qt invented at the level of `private`/`public`/`protected` and such. https://doc.qt.io/qt-6/signalsandslots.html
https://docs.huihoo.com/qt/solutions/4/qtcopydialog/qtcopydi...
Is the result by any means passing through a double? like in freakin' JS!
It includes a C interpreter and is very handy when manipulating registers.
Unfortunately not open-source.
Unfortunately with macOS's "Dark Mode" enabled the colors have little or no contrast. And the UI renders very small for my eyes (and compared to the demo gif). This is a criticism of Qt (or maybe its python bindings) rather than this project. (Screenshot: https://imgur.com/a/G9eAPoO)
I wonder if there's a way to shimmy in a "modern macOS Qt renderer" or something into an existing project like this without a rewrite?
Apparently there is. I hacked something together in a new branch: https://github.com/fellerts/procal/tree/fredrik/theme. Feel free to check it out and let me know how it works for you.
QFont('Monaco', 12)
Edit: merged a fix for this, thanks for reporting.
But in my experience with Qt, you always have to adjust font names separately for every OS. This is especially true for nice coding fonts.
If I had written that program, I would have brought my own font (like "Hack"), and simply set the pixel size of the font, to ensure it's exactly the same size on any OS (and I would have written it in QML, with heavy usage of Repeater, which would simplify the UI code a lot, but I digress...).
You could play with the QT_SCALE_FACTOR environment variable to fix the scaling issue at least. Something like this could work:
$ QT_SCALE_FACTOR=2 python procal.py
My daily calculator is `jupyter qtconsole` (formerly `ipython qtconsole`). I've had it binded to Meta+Q forever and it is very handy to have a full Python REPL which can occasionally display graphs and stuff that can pop up at hand.
If it were executing third party input on your machine, then it’s a completely different ball game.
E.g. if you want to compute the width of some object in Inkscape or Freecad, using some formula not supported by those programs.
How is the developer experience for that? Anyone able to contrast with Tkinter?
This can be remedied to a degree: https://doc.qt.io/qtforpython/considerations.html#features