Qt 5.5 Released

New submitter mx+b writes: The latest version of Qt, the cross platform GUI toolkit and development platform, is out for all major platforms. Highlights include better 3D, multimedia, and web support, as well as better support for the latest OS X and Windows releases (including Windows 10) and more Linux distributions.

Comments

TITS!

[Anonymous Coward]

That is all!

I suppose it'll have to do

[Anonymous Coward]

until its functionality gets folded into systemd.

Re:I suppose it'll have to do

[Anonymous Coward]

until its functionality gets folded into systemd.

Thankfully OSX, Windows, Android, iOS and Windows Phone aren't burdened with systemd like the Linux desktop is.

Re:I suppose it'll have to do

[Barsteward]

yawn... that is getting very old now, can't you think of anything original?

Re:I suppose it'll have to do

[Barsteward]

they all have their own versions..

Re:I suppose it'll have to do

[Anonymous Coward]

Thankfully OSX, Windows, Android, iOS and Windows Phone aren't burdened with systemd like the Linux desktop is.

All those operating systems run a service daemon similar to SystemD.

Hey, if you really want it, some BSDs and Linux distros still allow you to run an init based on crusty text scripts and text configuration files, just like AUTOEXEC.BAT and CONFIG.SYS in the DOS days.

Why do they bother

[faway]

QT is a huge stinking pile of bloatware. I eschew it.

Re:Why do they bother

[Gravis Zero]

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

Re:Why do they bother

[Barsteward]

" bloatware" is always used by people who don't know what they are talking about.

Re:Why do they bother

[Gravis Zero]

"bloatware" is always said by people who don't know what they are talking about.

pff! that's a bunch of bloatware!

Re:Why do they bother

[Anonymous Coward]

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

I was bored at work and checked libqt5core and libqt5gui vs gdk/gtk. Those two qt5 components amount to ~10 MB vs ~5MB for gdk/gtk. QtQuick probably gets that well over 20MB.

But you're not going to use either on some Cortex-M MCU anyway, so who cares.

Re:Why do they bother

[gbjbaanb]

sure, but I thought gtk had a dependency on systemd nowadays so you have to count it's, and all its dependants' binary sizes too :-)

Re:Why do they bother

[Anonymous Coward]

Agreed. It there a worse C++ library? Perhaps Boost. Qt should be rejected for its slots and signals alone.

Re:Why do they bother

[Anonymous Coward]

and is easy to cross-compile for your device [doc.qt.io] of choice.

For some value of "easy"... Ever seen Go? Or Oberon?

Re:Why do they bother

[Anonymous Coward]

QT is a huge stinking pile of bloatware. I eschew it.

You are right, QuickTime is bloatware. However, Qt is well written and you are given the option to build only what you need and which libraries it should use. The render engine is exceptionally flexible too, allowing it to leverage many different methods of rendering. Don't have X? no problem, add a runtime argument (-platform linuxfb) and your qt program will display using the linux framebuffer. Qt also builds for desktops (e.g. Linux, Windows) and embedded systems (e.g. Android, iOS) and is easy to cross-compile for your device of choice.

if you think GTK+ is slimmer, guess again and check your binaries.

I live in Montreal -- two official languages French/English. I also do development for Latin America. QT bloatware is great. User selects his language and there we are, one software for E/F/S.

Slashdot Beta is crap share shit crap fuck

[Anonymous Coward]

Everyone hates slashdot share beta shit crap pile of shit crap

Web support

[TuringTest]

When I've read "web support" I though "Cool! I will finally get good support to run QT apps on a standard browser". But alas, it just means running a Chromium engine embedded in a QT app. Who wants to run web sites in an app nowadays instead of opening them directly in a browser?

Re:Web support

[UPi]

Using web technologies to embed rich content into your application is not unheard of. The Steam client comes to mind as an obvious example: most of their UI lives in a webkit container. We do it at the company I work for, because it allows us to release new client and server versions separately. (We have a good reason to do that, not going into details.)

The alternative is either to launch an external browser and display your application's content there, which is cumbersome and then you end up having to test your application with all the browsers in the world to make sure it's compatible. Yet another alternative is to use a non-webbased rich content widget; in this case you are likely to end up with something inferior AND with a smaller pool of experienced developers to hire from.

Re:Web support

[sexconker]

Web support in apps is for cows, you are all cows, moo?

Re:Web support

[Anonymous Coward]

How about just dumping the browser layer? Or making it vanish into OS? I mean.. you have an OS that can handle apps and windows, in one of these you have a browser app, and then inside that you have some framework that can.. handle windows. That's just.. urgh. What's next? Oh I know, a facebook like web app that has multiple windows, you know, for facebook preper, and then separare windows for games and such. So you'll have three layers of app and windows handling on top of eachother. Or four, if one of the games is a "game collection" that consists of multiple smaller games.

Re:Web support

[Anonymous Coward]

http://vps2.etotheipiplusone.c...

Re:Web support

[Anonymous Coward]

When I've read "web support" I though "Cool! I will finally get good support to run QT apps on a standard browser". But alas, it just means running a Chromium engine embedded in a QT app. Who wants to run web sites in an app nowadays instead of opening them directly in a browser?

It's not part of the official releases (yet?), but there's https://wiki.qt.io/Qt_for_Google_Native_Client and emscripten-qt.

Re:Web support

[Gravis Zero]

When I've read "web support" I though "Cool! I will finally get good support to run QT apps on a standard browser".

actually, you can do that

But alas, it just means running a Chromium engine embedded in a QT app.

no, it uses WebKit while Chromium uses Blink, a fork of WebKit.

Who wants to run web sites in an app nowadays instead of opening them directly in a browser?

well... if you wrote a web browser in qt you would. what about an RSS feed reader? it has it's uses but it's true it shouldn't be abused.

Re:Web support

[gbjbaanb]

I found Wt really interesting, replacing desktop UI controls with their equivalent in HTML ones, passing the data back to the same c++ backend that the desktop would use. I'm sure it'd be a cool thing to replace your QApplication woth WApplication and have it turn into a html5 GUI, but what's the chance the GUI components supported would just be the most basic?

Re:Web support

[Carewolf]

no, it uses WebKit while Chromium uses Blink, a fork of WebKit.

No, the new web module for Qt called QtWebEngine is based on Chromium, and yes, it is pretty much running a Chromium webview inside your application. It is the cost of having to have a standard web engine that works on all platforms, after Apple became too difficult to work with after Google left.

Re:Web support

[Anonymous Coward]

I've used Wt and I like it. You get looked at funny for "doing websites in C++" but, compared to an Apache/PHP stack it is lightweight enough, especially for embedded use. It's C++, so hitting low level hardware is straightforward. Documentation and examples are a bit threadbare, though.

Modularity

[UPi]

QT is modular. This allows them to add features (you call it bloat, but I don't think it means what you think it means), and then it is up to application developers to pick and choose the modules that they want or need.

The demand for more features is omnipresent, and software developers can either choose to fulfil them one way or another, or lose their market share to someone else who does.

Re:Modularity

[DrXym]

It's modular but it's still got bloat. I'm writing an application which has a fairly modest UI that has a main window, some tabs and dialogs. The weight of the runtime I have to ship with it - icu*, Qt5core, Qt5Guid.dll, Qt5Widgets runtimes is nearly 38MB. Most of the modular bits with the exception of webkit - (multimedia, networking, OpenGL, SVG etc.) are comparatively lightweight compared to the slab of unavoidable "core" stuff that you need whether you like it or not.

Re: Modularity

[Anonymous Coward]

QtCore has to handle unicode, so it needs all the information on all defines Unicode characters. Those are huge. That is hardly something that Qt can be blamed for. It tries to use the tables in the OS where possible after all.

Re:Modularity

[Kjella]

The very page you link to says:

Some might argue that there might arise a small problem with shipping 27M ICU libraries. If you don't need ICU (http://site.icu-project.org/) you have to recompile Qt with ./configure -without-icu.

What's ICU?

Here are a few highlights of the services provided by ICU:

Code Page Conversion: Convert text data to or from Unicode and nearly any other character set or encoding. ICU's conversion tables are based on charset data collected by IBM over the course of many decades, and is the most complete available anywhere.

Collation: Compare strings according to the conventions and standards of a particular language, region or country. ICU's collation is based on the Unicode Collation Algorithm plus locale-specific comparison rules from the Common Locale Data Repository, a comprehensive source for this type of data.

Formatting: Format numbers, dates, times and currency amounts according the conventions of a chosen locale. This includes translating month and day names into the selected language, choosing appropriate abbreviations, ordering fields correctly, etc. This data also comes from the Common Locale Data Repository.

Time Calculations: Multiple types of calendars are provided beyond the traditional Gregorian calendar. A thorough set of timezone calculation APIs are provided.

Unicode Support: ICU closely tracks the Unicode standard, providing easy access to all of the many Unicode character properties, Unicode Normalization, Case Folding and other fundamental operations as specified by the Unicode Standard.

Regular Expression: ICU's regular expressions fully support Unicode while providing very competitive performance.

Bidi: support for handling text containing a mixture of left to right (English) and right to left (Arabic or Hebrew) data.

Text Boundaries: Locate the positions of words, sentences, paragraphs within a range of text, or identify locations that would be suitable for line wrapping when displaying the text.

And much more. Refer to the ICU User Guide for details.

Not sure exactly how much Qt functionality you'd lose, but it's an optional dependency.

Re:Modularity

[Anonymous Coward]

Neither Qt5Core, Qt5Gui, nor Qt5Widgets require ICU libs in the default builds anymore. You need to ship ICU for Qt5WebKit though.

Re:Modularity

[angel'o'sphere]

Erm, then learn to code?
Compile the libs statically and link only what you need?
Calling a library/framework bloat because you are an idiot who has no clue is an insult to the men and wemon behind that framework.
38MB is bloat? Wow, I guess an empty word document has a similar size ...

Re:Modularity

[TheRaven64]

38MB sounds only a bit larger than just ICU (31MB on my machine), so Qt isn't adding much there. ICU is used by most GUI frameworks (Microsoft has their own version, but OS X ships it as part of the standard install) and includes things like fast unicode collation (locale-aware sorting is hard!) and fast unicode regular expressions. Most apps that need to work in places that aren't just the English(ish)-speaking parts of North America need most of that functionality.

Re:Modularity

[Anonymous Coward]

Compile the libs statically and link only what you need?

Yeah, that would work, except that Qt is licensed under the viral LGPL if you aren't paying big bucks for a commercial license.

Look what the Qt licensing FAQ says (emphasis added):

The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.

and

The user of your application has to be able to re-link your application against a different or modified version of the Qt library.

So dynamic linking is pretty much the only option for many Qt users.

Now that you know this, you can quit being such a smug fuckface and realize that the bullshit you're suggesting is just that: bullshit. You can also apologize to us for subjecting us to your idiocy.

Re:Modularity

[DrXym]

My, aren't you the patronising one?

Re:Modularity

[tao]

Any sensible distribution contains Qt already, meaning that you don't need to (and shouldn't) bundle Qt with you app. Those 38MB might seem a lot, but if you spread that out over all apps that use Qt (and factor in all non-Qt apps that also uses icu, which nowadays is almost everything) it's basically background noise.

Re: Modularity

[DrXym]

Most desktop OSes would have services that could provide that information and do encodings and transformations between character sets. I don't see that QT needs to ship all of it. Aside from that my app is localizable so I can't do away with the way its implemented either.

Re:Modularity

[DrXym]

It breaks down to about 25MB icu and 13 MB of QT on QT 5.4 on Windows.

Re:Modularity

[Anonymous Coward]

Any sensible distribution contains Qt already

Does that include the "distributions" used by more than 90% of PC users (i.e. Microsoft Windows) ?

Re:Modularity

[Anonymous Coward]

38MB is bloat? Wow, I guess an empty word document has a similar size ...

Adding 38 MB to the size of the package does not look very good when it would be 1-2 MB without Qt for an otherwise not very large application written in C++ (and contrary to what someone will probably say in a trollish reply, that can be far more complex than Notepad with competent optimization, and of course not including excessive bloat from third party libraries), and there are other toolkits like FLTK that only add ~1 MB when statically linked. Now of course people nowadays seem to be fine with applications that are unoptimized by factors of orders of magnitude, but an extra 38 MB is indeed bloat when only a few basic widgets are needed.

Re:Modularity

[DrXym]

I'm developing for Windows first where the general practice is for applications to ship with whatever DLLs they need rather than install them in shared folders, the windows\system directory or somewhere else on the PATH. Otherwise DLL-hell will surely follow.

Ultimately the application may end up an embedded device, where space is at a premium. In that instance I'll probably have to static link but it depends on licencing issues.

Re:Modularity

[Anonymous Coward]

Windows users are used to bloatware. With Qt, that bloatware is more malware for a change.

Windows is broken because there is no package system. We all know this and there is nothing we can do about it. That is what you get from using a 1980 era operating system. Sure it was greatly improved since then, but it is still a series of incremental improvement on top of ms-dos. This is why you got 'drive letter' and have to 'install software'. Seriously, at this point stop complaining about Windows or stop using it. You ether never going to change or really enjoy it anyway.

Re:Modularity

[Anonymous Coward]

LGPL does not pre-clude static linking... but you need to provide the files necessary to re-link against a different Qt version then.

You can also trim down the dynamically linked Qt you use for your project (e.g. by removing the dependency on ICU, which is only recommended but only required for the web stuff). You do loose features then and give up on all markets that have a non-Latin script.

Re:Modularity

[Anonymous Coward]

27MB for something that sounds like it should fit on a floppy disk.. wtf.

Re: Modularity

[Anonymous Coward]

Actually, no. On OS X and Linux, for example, ICU _is_ the de facto library for processing Unicode text. Remember, in Unicode word, line, and paragraph iteration requires applying the complex Unicode rulesets. Windows has DirectWrite, which can parse syntactical elements in Unicode strings, but the API is directed toward display, not text manipulation. Can you imagine using _callbacks_ just to determine where to break a line!? That's horrendous! Plus ICU includes things like a decent Unicode-aware regular expression engine.

So I'm pretty sure ICU is also the de facto library for Unicode text manipulation on Windows as well. You just don't see it very often in general because too few people actually care about proper treatment of Unicode. Too many people think that just by using a wide character type, whether 16-bit or 32-bit, they can process string arrays just like they did in ASCII or various traditional 8-bit encodings.

Re: Modularity

[Anonymous Coward]

You always have to 'install software'.

Shit ain't magic.

P.s. Chocolaty

Re: Modularity

[Anonymous Coward]

Package system are magic. Everything work.

'Installing software' mean that every software has is own installer utility that copy file and corrupt the global register in it own unique way. It also mean that dependency can't be resolved and each installer utility has to 'install' it own version of each dll or fork and call a other installer utility that will place outdated runtime because fuck you.

If you still can't see the difference between package and 'installer' please kill your self.

Re:Modularity

[Anonymous Coward]

So, you have a problem statically linking Qt, which is LGPL licensed, but you have no problem statically linked FLTK, which is LGPL licensed? Also, FLTK's feature set is ridiculously poor compared to Qt. FLTK is a widget set. It doesn't provide collections. It doesn't provide threading. It doesn't provide Unicode manipulation. It doesn't provide a great default theme. It doesn't provide support for using CSS to easily add more themes to your application. TL;DR: Your comparison is bogus.

One of these days

[msobkow]

One of these days I'll have to get "into" QT. It looks like a great successor to some of the concepts originating with Neuron Data's tools, which I spent a lot of years learning and working with. For now I've been focused on Java server code, but I've never really been a fan of Java for writing client applications, and I've no interest in buying an Android device just so I can stick with Java while working on front-end code.

No, to me, client side means an actual computer, not a mobile device. And QT hits almost as many platforms as Java does, so it would seem to be an excellent fit for my goals. :)

Re:One of these days

[angel'o'sphere]

Java is excellent for client code, first of all we have Swing and if you like to use Groovy: Griffon, a GUI framework, and secondly you have JavaFX the new Java GUI Framework.

Against Java and for Qt only speak, what you don't want anyway: portability to mobile devices.

Re:One of these days

[Anonymous Coward]

You can sell your apps if they're written in java. For Qt you have to buy a license.

Re:One of these days

[Anonymous Coward]

Qt can be licensed under GPL/LGPL or commercial. All three options allow you to sell your own code.

Re:One of these days

[Anonymous Coward]

But only the commercial one allows you to keep your source code.

Re:One of these days

[msobkow]

Umm. Yeah.

And why would someone writing GPL software care about that?

Re:One of these days

[Anonymous Coward]

Nope. LGPL does *not* require you to hand out *your* source code.

You do have to hand out all changes you did to the Qt code and you do need to provide for a way that enables your users to replace Qt in your application (easy when you dynamically link to Qt, harder -- but still possible -- when you do static linking).

Re:One of these days

[spitzak]

Wrong. The LGPL license of free Qt allows you to keep the source code to your program secret.

I think it was GPL in the long past but they changed at least 10 years ago.

Not just a GUI toolkit

[Prien715]

Qt is not just a GUI toolkit. Doxygen has been using it for years. I do high performance computing and copy-on-write data structures (as Scott Myer suggest a decade ago in "More Effective C++") means I don't have to worry about functions returning references to a std::vector because QVector's copy constructor is O(1) as Scott Myers recommended a decade ago. I have a sane cross-platform cross-DB SQL interface. My strings are Unicode (and copy-on-write).
Qt allows you to write high performance code but in a style closer to Perl (especially with 11. "Auto" is "my") while enabling a coder to use high performance C code without needing to write fancy interfaces and compile schemes Everything from threading (QtConcurrent is great!) to file access to JSON to regex to is well-documented and the compile errors are sane (see: boost) and the code is terse (also: boost).
If you're doing serious C++ development with a small team, Qt is the best way to get things done in my experience...and it's also trivial to make a GUI to represent a SQL query.

Re:Not just a GUI toolkit

[cheetah_spottycat]

Mod parent up! The value of Qt as at a cross-platform c++ platform / enhancement is much undervalued. It is so much more than just part of a Desktop Environiment and the GUI Toolkit reallky is just a small part.

Re:Not just a GUI toolkit

[jma05]

I don't disagree with anything, but I am just curious: what kind of improvements did you get with C++/Qt stack over say, Java or Scala? (I am assuming you evaluated alternatives) Say, over 2x improvement in performance? Much lower memory utilization?

Re:Not just a GUI toolkit

[Anonymous Coward]

Holy crap, if you are using QT because it lets you write Perl-esque C++ code, you deserve to be taken out and shot. Must be academia, only place you could get away with such awfulness.

Re:Not just a GUI toolkit

[taupter]

1. Native appearance is supported since a long ago in Qt, making a Qt program display in an appeasing way no matter what OS it is run on.
2. No VM.
3. No garbage collector.
4. Compiled code. Native speeds. Performance dependent on compiler. Can use MinGW, GCC, MSVC2010-2013, LLVM/Clang. No JNI.
5. Legacy code. Way easier to port already written code instead of translating it to another language and having to learn everything again and possibly adding new bugs and surely losing time redoing what is already done.
6. Performance. I've seen benchmarks before defending one and another, but according to my experience, garbage collection has a perceivable negative impact in performance and memory usage. For client doftware it may be neligible, but for data crunching applications a compiled language makes more sense. The stack machine approach in Java is somewhat slow, and the Dalvik approach (register-based) is speedier but not as speed as native code. ART, despite its ahead-of-time approach has a median performance gain of about 15% only according to benchmarks I saw. Native code on Android doing the same workload is between 4x to 10x faster.
7. Lower level access. I wrote hardware diagnosis software and used C++/Qt. It was portable to Windows, Linux and UEFI firmware. Frankly doing so in Java would be for all practical purposes impossible.
8. Portability. It's easiers to port a dedicated C++ code to a new platform than porting a JRE to a new platform. Some platforms simply don't (and legally can't) have a JVM.
9. Personal taste.

I'm not saying anything against any language at all. Everything has a purpose, and some languages are best fitted to specific environments/purposes/domains. Doing a database-oriented Fortran code or 3D graphics in COBOL will not highlight these languages' strong points. But if you have the knowledge, experience and the language is a tool fit enough to the need in question, then why not?

Re:Not just a GUI toolkit

[jma05]

I understand all that. I used Qt myself, but just for simple GUIs. I was just wondering what his real world numbers were. I was not challenging him for his choice. I know the micro-benchmarks between native and VM code. I was curious of how things fared in his larger apps. I normally do JVM for long-running server code, but C++11 and onwards is increasingly attractive, although JVM is still a bit simpler to work with, on the whole. I am exclusively interested in his (or anyone else's) real world experiences on the performance differences between JVM HPC code (server VM config) and C++ server code that uses Qt as the main library.

Re:Not just a GUI toolkit

[zerojoker]

Another very important point is deployment. Deploy a Qt application to say, Windows, you ship the needed Qt libs as dll's with your program (installed in the program folder). User installs, and starts the program like a native one.

Java: Ship a jar (or say exe), and then the user has to first download a JRE. Start your program, and the user has to wait with a startup screen, cause the JRE takes time to load. Horrible end user experience

Re:Not just a GUI toolkit

[Prien715]

I don't have a direct comparison with my current project, but having worked on other projects in the HPC, it's not 2x. It's more like (O)n vs (O) n log n -- or worse. There was a project I worked on with did feature tracking and at one point, I was asked to save the data for a small project to a DB so another product within our company (team of around 20 on each project) who was working on equivalent functionality in Java. I lazily saved the whole thing for each change which took under a second, but it took 20 seconds to load the same data in Java-land. No matter what feature you tried, it was always dog-slow.
Think of it this way. You've got a triple nested for loops going over a 3D array of data (very common in vision, etc). So the C/C++ programmer goes in and you can optimize the innermost loop with extreme efficiency -- maybe even to the register level -- but it's rarely needed. Much more common is to simply try and reduce your new/frees to take outside of the loop and if it's really a bear, calling something like CUDA can increase performance dramatically (I've seen over 100x) as there's direct hooks from C++. But in Java/Scala/interpreted language land, you just optimize to the same level.
90% of your time is usually spent in 5% of your code, so it's really the ability to optimize easily when you need to without resorting to convoluted tricks and hooks into other languages.

Re:Not just a GUI toolkit

[jma05]

You can bundle JRE with your jar/exe, if you don't want the user to separately download a runtime. Many Eclipse Rich Client Apps do this. I have done it myself. As someone who used Delphi/C++ Builder and is very used to static linking to a 1-2 MB distributables with no further dependencies, I am not that happy with Qt dll sizes for client apps. Its certainly better than Java, but is quite bloated for native code. All other native solutions are much more compact (Qt of course wins by feature set). Static linking with Qt is possible, but not recommended.

I was looking for info on Qt server apps. On the server, runtimes aren't a concern. Startup times are also not important for HPC apps with long execution times. What is important is how things go after the startup. JVM does need to set more memory aside for the GC. Micro benchmarks typically put C++ at 1.5-2.0x faster than Java. I wondered how real world performance differs.

Re:Not just a GUI toolkit

[jma05]

Thanks. That's useful feedback. Obviously, this topic is complicated with several factors to muddy the waters.

> 90% of your time is usually spent in 5% of your code, so it's really the ability to optimize easily when you need to without resorting to convoluted tricks and hooks into other languages.

Interestingly, the Python/glue-language philosophy is just the opposite, for exactly the same reasons. Since it is just the 5% of the code that needs optimization, it says: why not write that in C/C++ and the rest in something easier?

These days, you can get GPU power outside C++. For instance, Theano brings GPU math to Python. I don't have experience with comparing the performance differences between say PyCUDA/jcuda vs straight C/C++ CUDA. The net difference may not be 100x, but C/C++ programmers will certainly tend to do deeper optimizations.

Re:Not just a GUI toolkit

[Anonymous Coward]

Maybe Qt is not ok for your current use cases. But in some circumstances the excess size of the linked libraries is diluted (in case of Linux and Android/Ministro), but in other cases not (a graphic Qt "hello world" is around 38MB). In some other is neligible (resources are way bigger). In server programs the size will be smaller than Java, and multiple instances will have a lesser impact in memory usage while the code will be run faster.
About raw performance, there's Android. The Dalvik performance is notably poor and ART improved it about only 15%, and having a native code is way better performance-wise and battery-wise.
The size overhead may not be an issue in comparison with assets and resources. The portability will reduce greatly the deployment to multiple platforms.
But in the end, it's all a matter of taste.

Re:Not just a GUI toolkit

[Prien715]

why not write that in C/C++ and the rest in something easier?

I guess that's my point -- it's not easier anymore.

Python comes with its own problems; it's hard to write object oriented code in a weakly typed language because (1) changing object interfaces means your code appears to work until it suddenly fails during execution (typed languages check at compile time) (2) no IDE can autocomplete methods on an object (because it's impossible to infer the type and thus the impossible to infer the methods able to be called on an object) (3) writing "glue code" is not a 0 effort proposition (not writing any is;)) and the code itself can contain errors.

With Qt/C++11 it's entirely possbile to write code that is both performant AND readable with less effort than an interpreted language (even one I've been using for over a decade -- yes I'm Perl guy). YMMV.

Expensive!!

[Anonymous Coward]

$4200 per year per developer! My interest in Qt just fell off a cliff

Re:Expensive!!

[Anonymous Coward]

You can use the GPL/LGPL versions of Qt. Those options work well for a wide range of users (incl. some that sell proprietary software based on Qt).

If you need to have a commercial license for your proprietary software and can't affort 4,2k per year and developer, then you got more important problems than whether or not to use Qt;-)

Re:Expensive!!

[taupter]

Well, if you can't addor 4,2k per year and a developer it may mean you're an Indie trying to break even and launch something nice. What is good and all, no prejudice. But some resources that would help an indie developer, as the Qt module that allows in-app purchases, aren't available to low-income developers, despite being the people who would mostly benefit from it. That's why if I was Qt I would add a new payment regimen, similar to what's already done by Unreal Engine and Unity 3D: pay after you earn something. "Do you have an idea? Use Qt Commercial and pay us when you break even!". If the indie project doesn't take off no harm was done (as no money to be earned existed anyway). This way Qt would gain traction and be more popular than how much it already is. A model like this:

Indie: Pay 5% of your income after you earn $10,000.00
Commercial: Pay $whatever/year.
Open Source: Pay nothing but publish the source accorging to GPL/LGPL/whatever.

Hope some old troll will listen and act accordingly.

Re:Expensive!!

[zerojoker]

Indie: Just use the LGPL version of Qt and pay nothing. At least not until you break even.

Re:Expensive!!

[taupter]

Do you develop mobile apps with in-app purchases using the LGPL version? AFAICT the in-app purchase module is not distributed with the LGPL version. I'd love to be proven wrong.

Re:Expensive!!

[Anonymous Coward]

There used to be an Indie license, pretty much along the lines you listed yourself. That was discontinued with this release of Qt, so apparently there was not enough interest in it to warrant the effort of having it.

Note that even with open source you do not need to publish your source code.

you FAIL i7?

[Anonymous Coward]

numbers continu3 Officers. Others

embedded is not open source

[Anonymous Coward]

> and embedded systems (e.g. Android, iOS)

Qt for embedded is not open source.

Good for mobile development?

[WWE-TicK]

How well does using Qt for iOS and Android development work? Last I checked, the documentation on how to effectively utilize Qt for this purpose wasn't nearly as informative as using it for it's more traditional use case. I would love to be able to do cross platform mobile development using C++.

Re:Good for mobile development?

[taupter]

Actually it's pretty straightforward. Compile and run. It will deploy to an AVD, an Android device, to virtual and physical iOS devices, all directly from the Qt Creator IDE.

Who cares.

[Anonymous Coward]

QT Mobile was a total farce and joke.

We dumped it after attempting to do a project on it. TOTAL FAILURE.

NEVER AGAIN will we believe cross platform claims. Total hype, lack of features, total fail.

Re:Who cares.

[WWE-TicK]

I'm sure lots of people would be interested in the details of your experience with Qt Mobile.