You can link statically as long as you make it possible for your users to re-link with a modified version of Qt. If you have ClosedProgram.exe and distribute ClosedProgram.obj and QtSource.zip you're fine.
Last time I checked, Qt was GPL/LGPL/Commercial. You can use the LGPL license just fine as long as you statically link the so/dll files.
I do understand not wanting to have to verify/check your obligations, of course. Still, Qt is a fantastic piece of software and a number of companies that I know of use the LGPL version just fine.
Glad to see one of the best C++ IDE's getting even better. The best part of it: even after all this years of active development and improvements it still feels very lightweight, it's more like sublime in terms of speed, when other comparable (by features) IDE's are feeling very heavy and bulky (like Visual Studio for example).
The only thing I would love to dream of is to Qt Creator have a better stand-alone support, now it's completely and fully integrated with Qt ecosystem, and that's really nice if you use Qt, but when I'm trying to convince my co-workers to give it a try, the getting on-board curve is a bit too much. Though this being said: it become much better in last years.
It's interesting, I used Qt Creator for a few years, overall I quite enjoyed it, the refactoring features builtin to it were much better than the VS builtin ones IMO. The code completion was brutally slow sometimes though, especially if using the Clang code model which basically maxed a core for over a minute every time I saved a file. In the end I switched to VS and Resharper C++ for the performance gain there and coworkers comfort.
I tend to use includes everywhere and only minimal forward declarations when required - this might be the source of the problem, but many modern C++ standards I've seen actually encourage that as best practice and discourage use of forward declarations. VS is able to keep up with that and Qt Creator just isn't. I find maintaining forward declarations a pain in the ass. See https://google.github.io/styleguide/cppguide.html#Forward_De... for example.
Google style guide is well known in C++ circles for not being that good of a style guide, other than taming the minions of employees at chocolate factory.
It used to be quite behind what is considered best practices in modern C++.
I've heard this and avoid it in many places, but I think their arguments are sound here. The maintenance effort and unexpected rebuilds needed to upkeep forward declarations is something I'm not interested in doing.
I'm not going to change my coding style because Qt Creator is broken, switching IDEs makes much more sense.
Maybe I'm wrong and I've just been made horribly lazy by writing too much C#, Python and JS, maybe this is some pretty horrible technical debt, but hopefully this will all go away once the planned C++17 modules system is introduced. It's one of my biggest annoyances with the language to date.
> Maybe I'm wrong and I've just been made horribly lazy by writing too much C#, Python and JS, ....
I know the feeling.
Nowadays I only use C++ to write libraries for Java/.NET/Android/UWP, that I have full control over.
When I see C++ code written in enterprise projects, frozen in pre-C++98, the code looks quite different, it is a continuous education process to try to convince devs to move forward, think Python 2 vs Python 3.
I also miss modules, but at least I can play with them on VC++ 2017.
I have said this in reddit, I am saying this again here because I feel if I don't I haven't paid my debt to QtCreator, especially their recent improvement.
Best C++ ide, by far. Especially with their recent enhancement to their CMake support. right now I am writing gtkmm app in QtCreator (I am using gtkmm instead of Qt because target system does not have Qt installed). With Clang Code Model I would say they are almost on par with Java IDE's in term of productivity.
I like KDevelop. It is a great product. Especially after (v5.0 I think) they integrated libclang to their auto completion. But I would say QtCreate is more polished and more robust version of the (idea of) KDevelop. They both trying to achieve the same goal. They both wan to be C++ IDE (although QtCreator does support Qt Project in a special way). But in broader sense they both want to be general C++ IDE for C++ developer.
I prefer QtCreator, just because it is more polished.
When I used KDevelop last, QtCreator's code model was much better. It even handles `auto` pretty well these days. And QtCreator can now use Clang for the code model so it should be very good.
Admittedly I last used KDevelop a long time ago, but has it really improved much faster than QtCreator? Can it autocomplete `auto` variables?
I really wish the Qt Company would stop bundling QtCreator as a required component of the Qt SDK.
I use QtCreator as my main IDE & think it's great, so of course I install new versions as soon as they become available. I compile & test against several different versions of Qt though and every single one of them lumbers me with an additional out-of-date copy of my IDE. This bugs me - more than it probably should.
The horrible thing about QtCreator is plugins support.
Most of them unstable and crashing IDE. Dependency on Qt SDK private sources killing all my attempts to maintain my own plugins.
I wonder if Mac support has improved. I like Qt Creator but a couple of years ago lots of weird bugs in the Mac GUI, like disappearing mouse cursors that wouldn't come back, among other oddities. I had read reports of other users with similar problems on Mac. I suspect most of the Qt dev team doesn't regularly use Mac so they don't spot these issues. I tried Qt Creator again about 9 months ago but it still felt bit problematic in a few areas.
I think you're asking if it's possible to use a debugger with QT Creator. It's had support for debuggers for at least most of the last decade, and I suspect longer.
I have used QML with good success in an embedded environment, although the embedded processor I was using did support OpenGL. If you want to use QML in even more constrained systems, it looks like there has been some work done on this [1], but I haven't tried it to see what the limitations are.
You'll need a processor beefy enough to run the Webkit javascript engine. There was talk a while back about V8 making it into Qt, but I haven't seen much about it recently.
I tried it once on a 400MHz MIPS core and it was awful. I'd say you need at least 800 to 1200 Mhz of ARMv7 core to make it look decent. Otherwise stick to 2D widgets.
>You'll need a processor beefy enough to run the Webkit javascript engine. There was talk a while back about V8 making it into Qt, but I haven't seen much about it recently.
How recently have you used Qt? Qt replaced WebKit with V8 in the 5.0 release, way back at the end of 2012. Since then they've developed a QML-optimized JavaScript engine called V4. It's slightly slower than V8 for some things, but significantly faster than V8 for the most frequent and critical QML use cases.
I was under the impression that once the scene graph is set up, JS performance does not matter all that much, but then I'm running a rather modest application with JS being mostly used for bindings. What parts have been slow to you?
The whole thing was slow, mostly because I had way too little RAM (webengine consuming a large chunk of it), an underpowered CPU, and no 2D or 3D acceleration so it was all in raster mode.
If you use QML, Qt uses the browser engine to execute the scripted part of QML/QtQuick. (Or at least it used to when I worked on this one particular project).
I use it to generate and play with interface layouts, then run the .ui file through pyuic5 to convert the interface into Python code. I've got a number of Raspberry Pi touchscreen projects that this has worked well for - I can develop on my Mac, and use the same interface on the Pi's touchscreen.
A lot of the people not doing web dev. It's a pretty good cross-platform toolkit, both for traditionally looking desktop apps and stuff that's custom design-wise (esp using QML for the latter), and free as long as you can live with an LGPL-dependency.
(Asking less condescendingly might help against downvotes)
There's a world outside web dev, you know! I have used Qt in many companies (some examples: forming a major part of the UI for a unified comms client, UI for screen/interfaces for an embedded system, desktop app for analysing/processing finance stuff).
With Embarcadero's very expensive multi-thousand dollar licensing costs[1], it seems like their strategy is focused on charging existing customers already heavily invested in their tools. (E.g. large legacy codebase with dependencies on VCL.)
I doubt that there's a significant number of new customers that's comparing both Qt and VCL as equal possibilities. Qt has a cheaper commercial license and more programmers in the labor market know it. Qt Creator GUI also runs on Linux today instead of an unspecified tomorrow.
We use Embarcadero at work for our older stuff and have moved to Qt.
It's a clunky piece of crap, built around what used to be a big community due to Delphi in the Borland era. Their standard library is awful, support for 3rd party libraries is slowly dying. I'm sure some people from that era love it, but unless you have legacy code to maintain I really wouldn't suggest it. Maybe their new version with the move towards a Clang-based compiler will be an improvement, but the IDE itself is just... bad compared to Qt creator - doesn't support DPI scaling, no easy jump-to-class, upgrading packages often involves hacking at giant XML project files by hand, it's just a mess. Not only that, but the compiler has some pretty horrid bugs. Just this morning the compiler exited with no error, had to reboot the machine to make it work.
It's also incredibly expensive and making decent use of it almost necessitates buying expensive component packs from 3rd party vendors like DevExpress.
If you're an individual or small time company, you can get better visual IDEs for free via Qt Creator or VS Community. Most old Delphi-style development has moved to WinForms or WPF in .NET land.
Not only did they shoot themselves regarding Delphi, they also missed the C++ RAD market.
I used to joke Visual C++ had nothing to do with visual, when comparing it with what was possible in C++ Builder concerning GUI RAD tooling support.
OWL and VCL were ages beyond what MFC could do, and there was the VB like experience for UI design.
But they went astray with their management decisions and now Visual C++ has actually become visual thanks to C++/CX and XAML (not counting the two C++ .NET variants).
