Qt 5.5 Released 80
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.
Re: (Score:2)
Re: (Score:2)
Modularity (Score:4, Interesting)
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 (Score:4, Informative)
Re: Modularity (Score:3, Informative)
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: (Score:2)
Re:Modularity (Score:5, Informative)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
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: (Score:2)
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:Why do they bother (Score:5, Informative)
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 [doc.qt.io] of choice.
if you think GTK+ is slimmer, guess again and check your binaries.
Re: (Score:1)
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 [doc.qt.io] 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: (Score:2)
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: (Score:2)
Re: (Score:2)
"bloatware" is always said by people who don't know what they are talking about.
pff! that's a bunch of bloatware!
Web support (Score:1)
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: (Score:3)
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
Re: (Score:1)
Web support in apps is for cows, you are all cows, moo?
Re: (Score:3, Informative)
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 [badassjs.com]
But alas, it just means running a Chromium engine embedded in a QT app.
no, it uses WebKit [wikipedia.org] while Chromium uses Blink [wikipedia.org], 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 [qupzilla.com] you would. what about an RSS feed reader [quiterss.org]? it has it's uses but it's true it shouldn't be abused.
Re:Web support (Score:4, Informative)
no, it uses WebKit [wikipedia.org] while Chromium uses Blink [wikipedia.org], 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: (Score:2)
I found Wt [wikipedia.org] 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?
One of these days (Score:2)
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 h
Re: (Score:3)
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: (Score:2)
Umm. Yeah.
And why would someone writing GPL software care about that?
Re: (Score:1)
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: (Score:2)
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 (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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 lin
Re: (Score:2)
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 t
Re: (Score:2)
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 r
Re: (Score:2)
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
Re: (Score:2, Informative)
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: (Score:1)
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 so
Re: (Score:2)
Re: (Score:1)
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.
Good for mobile development? (Score:1)
Re: (Score:1)
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. (Score:1)
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: (Score:1)