Additionally, QWidgets, the old pure-C++ based UI libraries are still available too. It also bundles a ton of other stuff, an embeddable web browser, javascript engine, collections library, concurrency library, networking library etc.
I’d much rather write a lightweight desktop app in any of the native toolkits, but especially Cocoa/Swift, and do the heavy lifting parts outside of the GUI application. But you’ll still have to write a native Linux one, and QT is my front runner there. But I do recommend looking at the Xamarin stuff too. Depends on your needs and where you’re coming from as a dev.
QT is awesome, don’t hear me wrong. But if your target platform is distros running gnome, it might not even be the right choice for a native Linux desktop app. And again, none of this cross-platform compatibility discussion necessarily makes it a better choice than Xamarin stuff.
I’m just saying, it’s not “the” option. It’s just a very good choice.
Point is... it's a gray area.
Linking technology itself is actually rather irrelevant to the legal questions that a court general ask in defining copyright. FSF happen use it as a bright line in the sand on where they will enforce the license, but any author can make their own decision on that matter. Game companies has for example gone after mods that inject itself through windows libraries, arguing that the mods purpose and existence is dependent on the original game and thus created a derivate work.
There was a historical case when a person legally bought a painting and cut it into several pieces only to stitched them together into a mosaic. The court judged it as a derivate work and thus requiring additional copyright permission from the author.
As with other gray areas in copyright, derivative work also have semi-exceptions. Compatibility is one. Since there is multiple different C standard libraries, it would be hard to argue that a program is specifically a derivative work of one. It would also be very easy to demonstrate the works independence by simply using a different standard library.
PyQt brings a interesting question but in the end I doubt it would be that much of a gray area. In theory you could make a program that is only compatible with Qt but don't actually depend on it, but in practice I suspect most such program do not start, operate, and function if you remove the Qt parts. In such cases I expect the accused will have a hard time arguing that the final work when used has no copyright-protected elements of Qt.
Even then, only if you dynamically link to the library.
If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.
If you dynamically link to an LGPL library, then only the library must be under an LGPL-compatible license (ie if you modify the library, those modifications must be made available), but your own code that links to the library can be under any license you wish.
This is because the LGPL considers statically linking as a single work, while dynamic linking as multiple works, which can be licensed independently.
GPL:
Regardless of linkage, your code must be under a GPL compatible library.
The GPL considers the software as a single work regardless of linkage.
This isn't right. You can statically link proprietary code to LGPL libraries and the LGPL license does not "infect" your proprietary code.
The only thing you have to do if you go this route is ensure that the people receiving your combined work are able to relink any modified version of the LGPL pieces. This can be done, for example, by providing object files for the proprietary pieces and a script to link them to the LGPL pieces, upon request.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Qt has language bindings.
Maybe the bindings are good? I just don't know, and I'm suspicious of an approach that seems to be entirely outside of mainstream Qt practice.
Yes you still write QML.
work great with Python
All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.
Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.
30 years in the making, still waiting for that thing to actually exist.
How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.
My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.
If you are comfortable with C++ and both traditional and event driven flows, Qt is worth a look -- you may love it or hate it, but you will have something to compare it to and know enough to form your own opinion. Otherwise, pick at least 3 different languages/toolkits and implement a simple application in each to be aware of different ways of doing the same thing. Repeat for a different simple application.
This vaccinates you against taking a model of your first toolkit and using it as the only way to solve every problem.
That said, Qt is a solid cross platform toolkit that you can use it to write robust applications. However, it severely locks down your choices. If you use it, force yourself to at least be aware of other options. My 2c.
Do you want to make cross-platform things? Sure, try this https://github.com/picoe/Eto (or these http://www.mono-project.com/docs/gui/ )
Do you want to be closer to the metal? More OpenGL? Go C++ or Rust ( https://github.com/rust-unofficial/awesome-rust#gui and https://github.com/rust-unofficial/awesome-rust#graphics )
Do you want less setup for your users? Go the Electron way, and/or eventually just build Web Apps!
The learning curve and full fledgedness of Qt was not needed for me.
I wouldn't even begin to know where to start with Electron. There are so many web frameworks and they're all badly documented... whenever I have to make a website I usually start off thinking "Right, I'll do it the 'modern' way this time - with React or Vue... and Typescript.. and and do I need webpack? and...??" but there's so much badly-documented half-finished stuff out there I usually end up giving up and doing plain Javascript. Doesn't help that the modern web stack is a total hacky mess.
I'd gladly take Qt with C++ any day even though I only know enough C++ to shoot myself in the foot with.
(Another thing that comes to mind is that there is a huge amount of software for testing, analysing, introspecting and debugging C++ applications - I would say that most other ecosystems are lagging behind in that aspect)
But more often than not Electron is good enough and there are even approaches to get JS on the desktop with less memory consumption than Electron.
Since we're in a submission about Qt: if you really don't want to touch C++ (which is kinda understandable, although C++ with Qt actually isn't that bad), Qt is very well supported in Python. Using them together is a breeze, and if you really do miss the craziness of JavaScript, you can still use it in QML :P
And if QML is what you only care about, you can even wrap it with Rust.
Just in order to retain your sanity, you need to use several layers above JS to transpile your code - like JSX when you do UI or TypeScript when you do... well, anything.
I believe that JS is considered easy only because you can get your first impressive results very quickly when combined with HTML and CSS, which makes it easy to not lose your focus when learning. That might make it a good language to learn in, say, primary school on IT lessons - of course, only if there weren't other, better suited stuff available targeting these cases specifically already. Anything else actually makes JS harder than, say, Python. Or Go. Or C#. Or Java. Or even C++ with Qt (although C++ is easily second worse). Or Rust. There's just so much stuff you have to keep in your head while writing JS, it's not worth it. But you have to let go of "I know it, so I'll use it, no matter how well suited it is" mentality, and that can be challenging.
It depends on the setup. I use CoffeeScript 2 which gives me most of what I miss from Python (which was my favorite language for years). And when I go back to Python I miss having a debugger as good as Chrome's, as well as some CS2/ES6 features.
> There's just so much stuff you have to keep in your head while writing JS, it's not worth it.
Can you give me some examples?
This alone clearly states that you known nothing abou C++ beyond tired old, meaningless clichés about irrelevant stuff you've heard somewhere and are complaining about something you know nothing about.
Because you're repeatedly showing profound ignorance on very basic aspects of using a programming language.
> Has C++ eliminated undefined behaviour recently?
You are aware that you're parroting on and on about an entirely irrelevant issue, don't you? I mean, any behaviour which has been left undefined in the international standard only means that there is a chance that two implementations may not implement the same obscure aspect exactly alike. And that's perfectly fine because these obscure corner cases shouldn't be used to begin with. That's what undefined behaviour does mean in practice.
But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.
Additionally, rust and go and python and other programming languages are not defined at all and somehow programmers don't get bothered by the fact that these programming languages are entirely undefined. But somehow you feel differently about a language you clearly know nothing about.
By undefined behaviour, I mean things like null dereferences, buffer overflows, memory leaks etc. that are done by accident and result in serious issues at runtime. I'd rather use a safer language where I can be more productive where possible.
Sounds like you're talking about implementation defined behaviour or unspecified behaviour which are different from undefined behaviour (these three terms are defined in the C++ standard document).
> But somehow you feel differently about a language you clearly know nothing about.
You're not even trying to understand the point you're leaping to attack. You clearly have a chip on your shoulder about something.
Big community, with many learning resources.
Nice package managers, with libraries for basically everything.
Since many people already know JavaScript from working as a web developer, they also have a faster start.
Is there any project similar to those two, for Windows?
- Repo : https://github.com/nidium/Nidium/tree/windows-x86
- Screenshot : https://i.stack.imgur.com/5hTqR.png
RStudio VS Code Discord / Slack (Well slack has not been rock steady)