Related
I have recently regained some interest in learning Qt, but have the following doubt:
Does Qt have enough classes that are not GUI-related?
For example, Python is "batteries-included", .NET is definitely "batteries-included", and as far as I have seen, Android API also has a lot of classes to design and implement application/domain logic, not directly related to visual presentation.
The main reason I am asking is because I don't know C++ and don't plan to learn it deeply (too much time needed), so if I had to take third party C++ libraries all the time and struggle to use them inside Qt projects that would be a strong point against going ahead.
The intended use is mostly to create small desktop apps for personal use while gaining insight on software design good practices - a profession I am slowly migrating to.
I have already used some Python/Pygtk (without IDE) and WPF (in VStudio/ExpressionBlend). In both platforms, most of my work is related to scientific computations, image processing and interactive scientific visualization, and there are good libraries for that either in Python (Numpy, Scipy, Matplotlib, Pandas, PIL, cairo) and .NET(AForge, alglib, System.Media.Media3D). I wonder if the Qt ecosystem is so complete in that regard.
Qt isn't a language in itself, so you can't compare it to Python or .NET. With that being said, Qt does provide general-purpose classes like containers, a Unicode string class, character set encoders/decoders, multimedia, device and file I/O, etc. All these modules are fully documented.
There are also some external modules available for Qt, like Qwt which provides widgets for technical applications.
For other functionality where something Qt-specific isn't available, you can obviously use another appropriate library. Like OpenCV.
Oh, and you can use Qt in Python too, through PyQt.
As far as I know, Qt doesn't have image processing libraries. For that, you'll need to use something like OpenCV. Qt does have libraries for loading most common image types.
However, Qt does extend beyond just GUI classes.
There is a database module that's quite convenient. The concurrency/threading classes are nice. I've enjoyed making use of the Qt Networking classes. The FileIO classes are alright.
These classes/modules are all useful for making platform-independent code. Things like image processing are mostly algorithmic and tend to be platform-independent by nature. So I think they fall out of the scope of the Qt framework. It shouldn't be too difficult, however, to simply find a library that does what you need and link that in to your project.
A lot of the Qt Core services that heltonbiker and Nikos C. mentioned, can be thought of as extensions to C++, a little like std. Although I often prefer the Qt implementations myself. But Qt has gone much further with their libraries, with the I/O, and web services etc...
The QtXML library provides reading and writing of XML files. Traditionally we had always used xerces, but the Qt XML library is almost as simple as .NETs.
The QtNetwork library offers TCP/IP and other networks services
The QtMultimedia library performs playback and recording of audio
and video content to the use of available devices like cameras and
radios.
The QtSQL library interfaces with SQL databases.
And there is much more than that. Although these are probably services that are used to most. The other benefit is that for the most part the implementations are cross platform. So for example using the I/O services does not require you to write separate code for Linux and Windows. That is a general rule, and there are exceptions. But I am sure most people would agree that any of the services they offer are easy to use, and well documented.
Happy coding.
Qt provides ample abstraction besides UI - it comes with a set of functionality enhancing features that come with certain usage paradigms.
Container classes - shallow copy by value, copy on write
Implicit sharing for containers and certain data types
Event driven, signals and slots
A powerful and usable metasystem
Properties
Platform abstraction for a lot of functionality, from file access to network and multithreading
Cross platform atomics (not that important since C++11 atomics)
Settings API
Undo API
OpenGL abstraction (not necessarily UI, custom graphics)
Basic image formats and basic image manipulations
Qt Declarative, a.k.a QtQuick and QML markup (usable for all kind of structure markup BTW)
Dynamic plugin API
Platform abstraction and portability - same code, multiple platforms
High and low level multimedia - audio, video
Sensors and serial port
Unit test
XML, JSON, SQL
An outdated and hopefully soon updated OpenCL abstraction
Last but not least, a lot of 3rd party modules built around Qt fitting a wide range of applications
Honestly, all its missing is support for some more popular formats for file, media encoding/decoding and containers, some parallel and vector abstraction, USB, WIFI/NFC (in the works in an addon module) and it will be 100% versatile.
Note that you can also use Python with Qt, although I have no experience with that, Qt is a very versatile tool that allows for quick and easy application development - and since 5.1 supports pretty much the entire market, with the addition of Android and iOS to the list of supported platforms. It is very useful for creating custom use applications for creative or research purposes.
Although not perfect for every task, Qt is easily the "best of the bunch" of tools you can use in this regard. Unbeatable in terms of portability and very thorough, if not a little bloated for the set of functionality it provides. And finally, it is free, you can even develop commercial applications under LGPL as long as you link dynamically. All in all, it is well worth the investment to learn, the only downside is it lacks uniformity between the old C++ native APIs and the QML runtime, which is actively worked on and is based on JS, so the APIs are a bit different and some glue APIs are required to fuse C++ with JS and QML.
(just for the record, from the official site):
The Foundation: Qt Core Module
The Qt Core module forms the foundation of all Qt-based applications
with core non-graphical classes used by other modules.
Key Functions
File IO, event and object handling
Multi-threading and concurrency
Plugins, setting management
Signals and Slots inter-object communications mechanism
Benefits
Reduce development time and cost by leveraging a complete set of application building blocks
Develop portable code from the ground up with cross-platform functionality
I am going to develop a new GUI for an existing C++ application. The application works on Windows and Linux, and the communication with GUI is through client/server.
What are the pros and cons between Eclipse RCP and Qt?
Some pros of Qt:
C++ stuff will generally perform better; however, this is arguable.
Qt is the base of Meego, the mobile platform sponsored by Intel, AMD and others; however, its current momentum seems not too high to me. This means you can also create applications for various mobile and generally embedded devices
There are a lot of Qt-based applications out there.
It has a WYSIWYG designer.
Good for small to large projects especially because of QtQuick, which allows the creation of small applications in no time and with almost zero knowledge about C++
Qt has an amazing wrapper in Python called PyQt (there is also the PySide of course), which allows rapid development and slick prototyping. People often use PyQt (or PySide) for the UI-side of a Qt application because of that. You can of course combine with ease Python and Qt in the same application taking advantage of all their strengths (but also weaknesses). This allows relatively fast and smooth development cycles even for large projects
Some cons of Qt:
The code of Qt-based applications make use of some elements that are not part of C++, which have to be converted into C++ by a special preprocessor called moc (Meta-Object Compiler) prior to the actual compilation. You and your build system have to take that into account.
Nokia (former owner of Qt, since it acquired Trollech) has sold it to Digia. However, this does not imply their involvement in the development of the open source Qt has changed.
Some pros of Eclipse RCP:
Eclipse RCP is far more than a graphical toolkit:
It sports a plugin-based architecture that can help distributing functionality among different components (plugins) and keeping control over dependencies among such components (plugins). Eclipse plugin system relies on their own implementation of the Java component system specification called OSGi.
It provides a mechanism to enable decoupled application extensibility called extension points.
There are many Eclipse plugins that you can use in your application and many of them have distribution licenses that are friendly to commercial products.
It has a WYSIWYG designer.
Some cons of Eclipse RCP:
Eclipse uses a custom windowing toolkit called SWT; on each platform it relies on the native graphical layer. On Linux, it relies on Gtk+ (although it's also possible to use Motif), which in my experience (and other's) has performance problems, mostly with widgets that are updated at high rates. Actually many of us embed Swing elements in Eclipse RCP applications to overcome performance problems while keeping Eclipse's extensible architecture; this, however, can bring integration problems. There's a version of SWT that uses Qt as backend, but its incorporation into Eclipse's codebase seems stagnated since October 2010.
Startup time (understood as the time elapsed since the application is launched until it shows up a window) of Eclipse RCP applications can be very long.
If you intend to integrate C++ stuff with Java by means of JNI, be aware that some people find it difficult.
Eclipse has lots and lots of bugs. Eclipse's bugzilla is a very useful resource for the RCP developer.
The more you want you Eclipse RCP application's look&feel and behaviour to differ from Eclipse IDE, the more troubles you will get into.
Eclipse RCP development has a big learning curve, in my opinion.
Using Eclipse RCP for small projects is basically a suicide (unless you are restricting yourself to only creating a plugin or similar). It is meant for medium to large and very large projects due to the complexity of its infrastructure, resource requirements and the above mentioned steep learning curve.
Eclipse RCP is not for mobile development because...it's RCP (Rich Client Platform). If you want to go mobile, this is not for you.
Both their distribution licenses (LGPL/GPL/commercial for Qt, EPL for Eclipse) are flexible enough for most uses, in my opinion. Nevertheless, I am not a lawyer, so I may be mistaken about that.
And of course, other factors like the experience of the developers, their technical skills, the size of the team, concrete requirements, etc, should be taken into account.
BTW, I have much experience in Eclipse RCP but only theoretical knowledge on Qt, so I may be biased/mistaken in my statements.
Now that Qt has an LGPL license I would choose Qt any day of the week over Eclipse RCP.
I have used both to create fairly complex applications.
Since you can use eclipse to develop c++, I am assuming that we are comparing mostly swt/jface vs Qt, and not the eclipse development environment itself.
Some things I have noticed having used both:
1) Qt has better documentation and samples
Other than some half-baked examples on the web, I could find little useful eclipse documentation.
2) Qt has a lot more 'professional' users
There are many professional companies out there using Qt as their UI framework. Given it's three platform support (Windows, Linux, Mac), it is very flexible, and has a lot of backing.
3) Qt tends to be more complete and mature -
Using Eclipse I noticed that quite often the controls, and packages that were available were only partially done, and not quite complete. They were typically developed for someone's use, and only coded as far as that. Qt's controls were almost always a complete design.
4) Styling.
Both Qt and Eclipse render using local platform libraries, so your UI will 'look' like other UIs on the platform you are running on (i.e. Linux vs Windows). However, Qt also provides fairly sophisticated styling functionality that allows you to easily alter the look of any control, and gives you much more control over the look of your application.
With the new declarative language (Qt 4.7.*) you are approaching WPF level of control which is really amazing.
5) UI Designer:
Qt has a much richer Designer that allows you to layout your form, and do basic testing without having to compile any code. The designer also gives you the capability to add interactions between the controls on your form. Ex. Click this button - disable this option
Eclipse also has a form designer, although my experience with it is limited. I did try to use it a couple of times with very limited success. Finally I coded every form by hand through code. That is painful.
6) Interfacing with existing source code
If you don't have this problem, then you are very lucky. Because Qt is c++ based it integrates seamlessly with legacy C and C++ code. Integrating Java and C is not easy.
7) Drawing Libraries
I tried coding some hand-drawn shapes using the swt libraries and was forced to bypass large parts of the swt drawing library, because of the cludge that was in there. Using Qt to do something similar was no trouble at all.
8) Tree and List Models
Eclipse does provide some nice out of the box functionality for propagated data into trees, and lists and things. It is almost as good in Qt, although a little trickier to set up.
9) Application Layout
Eclipse provides some nice functionality to manage 'view's (dock panels), and 'perspectives' (workflows) that if you decide to use them makes life nice and easy. Qt requires you to do this yourself. Qt does have dock panel functionality, but when building a rich application you have to set this up yourself.
Extra Note:
Qt has also provided some extra libraries to support things like xml, etc... So this helps bridge the gap a little between c++ and java for things like this.
Suppose I develop an application with the logic as a CLI program that can be compiled to various platforms. To add a GUI, I could develop native versions separately for each platform or I could use a cross-platform tool like Tcl/Tk, wxLua, or PyGTK. Some people, like Bruce Eckel and James Ward, promote Flash/Flex on Adobe AIR for this.
I've looked into it, but haven't been able to find clear answers to these basic issues.
Native look and feel
The Spark architecture in Flex 4 improves support for skinning to the extent that you can match any L&F, it seems. What resources are available for implementing Windows/GTK+/Cocoa L&F and how much work is it?
Responsiveness
I would rank these popular toolkits from most to least snappy: FLTK, FOX, GTK+, Tcl/TK, Swing, Qt. Where does AIR fit in this range?
Stability
For a long-running app with extensive user interaction, how are the stability and memory management? I've read that memory leaks have been a significant issue with AIR.
Local system access
I think the biggest complaint about AIR 1 was its isolation from the local system. Now, AIR 2 adds communication via stdin/stdout with the NativeProcess class. How well is this working out for implementing the functionality you typically want in a GUI?
Package size
Ranging from a minor interface with a few buttons and textboxes up to something like an IDE, how big would an AIR version be, compared to say, something in Tcl/Tk or wxPython?
Hand coding
If you don't use Flash Builder, how hard is it, relatively, to create or maintain a nontrivial project?
Native look and feel: It's possible to skin a Flex app to make it look native. And load a different skin depending on the OS. There are already Windows and Mac skins (not sure if they are Flex 4 compatible yet) available on www.scalenine.com. But these skins will never be a 100% match since it's replicating the l&f, not actually using native widgets.
Responsiveness: I'd guess it's probably somewhere between Swing and GTK+. But I don't have benchmarks to back that up - just my personal experience.
Stability: As long as the code is good and objects are being GC'd then things should be fine. AIR 2 fixed some memory leaks that caused the issues you reference.
Local system access: NativeProcess allows you to do pretty much anything. But more complex use cases probably need something like Merapi.
Package size: The entire UI component set in Flex is around 2MB. Then any custom code will add to that number. Usually the bitmap assets are what really bloat SWF files. You can look at Apparat as a way to reduce the size of SWF files.
Hand coding: I hand code all of the time with just the open source Flex SDK, AIR SDK, and vim (my text editor of choice). That's all you really need. But you will lose out on code completion, visual debugging, etc. But there are some other open source tools out there for doing these things.
For an internship, I'm gonna have to develop a desktop application. The focus is creating a rich UI ( cool effects, sound etc ). Which tech should I go with ?
- Flash ? ( in this case, shoud I go with a flex project ? AIR ? what is the gain between this and a simple raw flash project )
- C#/Silverlight ?
Any other possibility ?
If experienced developers could give their advice, that would be great thanks.
The best technology to use is probably the one you're most familiar with, unless you mean you're going to be learning on the fly. But for the various options I'll take a stab.
Flash itself (the runtime) is a browser plugin, so that's not what you want, but if you build your application in Flash or Flex (the authoring tools), then you can publish it as an AIR application. AIR is also a runtime - basically it's Flash, plus a bunch of extra APIs for running outside the browser. The advantages to making an AIR app are:
The same app runs on win/mac/linux
You can make it with the same skills/tools you use for Flash (dubious utility if you don't have those skills/tools, of course)
Close tool integration with other Adobe tools (photoshop, after effects, etc.)
The main disadvantage is incomplete access to native (i.e. OS) capabilities. The way a runtime allows you to run the same app on win/mac/linux is by restricting you from doing some of the things that you could do with a native application.
As for Flex, whether you use Flex or not is a separate question. Flex is a framework within Flash - an AIR app can be made using Flex or not using it. Basically, if you expect your app to have a lot of controls, slider bars, charts, accordion panels, etc., you might look into Flex. If you expect it to have a lot of animations and pictures and sounds, plain-old-Flash may be better.
Apart from Flash, the other main choice for a runtime is Silverlight. The advantages there are, to be honest, basically the same. You use .NET instead of ActionScript, and the tooling integration is with MS' Expression suite instead of Adobe's creative suite, but the development process and the results are quite similar. The choice between AIR and Silverlight is really a choice between Adobe tools and MS tools, and between two programming languages of entirely comparable power. Most everyone simply uses the one they're more familiar with.
Finally, the other set of options is not to use a runtime, and to simply compile an app from any language/development environment you like - C, C++, .NET, Python, anything. The advantage here is you get (in general) full access to OS capabilities. The disadvantages are, you (in general) need to do extra development to run on multiple platforms, and also I don't think you'll find a language/environment that lets you work with multimedia as easily as you can in AIR and Silverlight.
Depends what programming languages are you proficient in. If you are .NET/C#/VB.NET guy go with SilverLight or WPF. If you know ActionScript, go with Adobe line of products.
My preference goes to the (slightly) most opened universe. Assumed that you know how to write Object-oriented programs, Adobe is using Eclipse as a base for his tools, using plugins.
Actionscript is just like Javascript syntax. You just have to learn the flex 4 libraries.
Then, publish you app as an Air desktop application that can run everywhere. Really everywhere
The only thing to know about MS tools and languages and libraries is that they are very well designed and usable. and it runs on Win and mac also. and Only.
If the main request is to have a rich UI the simplest approach is to build a Flex application running under Adobe AIR platform. The answer to the questions Flash or Flex is very simple: if you are a designer go with Flash, if you are a developer stay away from Flash and use Flex. The Flex framework was created for developers, and is really hard to replicate all its features in Flash (think only what you have to do in Flash if you want to resize your app).
On the other hand if you are coming from a .NET background it will make more sense to stick with Silverlight/C#
I'm not sure if this helps but I'm developing in Flex and now I have started to learn Silverlight and I can say that developing in Flex Builder is much more faster then developing in Silverlight( Visual Studios ) . For me Flex Builder is much better because you use only one IDE to develop both back and front end. And that's when it comes to web development. If you want to do desktop applications then you do the same thing and a plus is that you get everything in only one file. You also have a small SQL database that comes with it.
But on the other hand when you develop in Silverlight you have to use several IDE's or tools outside Visual Studios to make awesome graphics. But if you want to have more time for design then I would suggest to use Flex Builder and not Silverlight.
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe -- iPhone: Objective-C , Android: Java, etc.)
Desktop (maybe -- AIR, .NET, etc.)
TV sets (maybe eventually)
Currently, I’m looking into application frameworks to build upon and I’m torn between pureMVC and Swiz.
I LOVE swiz for its simplicity and how it just gives you a way to hook things up and then apply your own patterns. From a flex-only perspective, this is my 1st choice.
But, PureMVC is platform-independent and has already been ported over to most of the platforms that are mentioned above. How valuable is this portability? Will it really make our lives significantly easier when it comes to porting and developing/maintaining multiple applications? If so, then it seems like PureMVC is the way to go.
Alternatively, since Silverlight has the most definite business case for porting of our application, maybe we could port Swiz to Silverlight? I'm not too familiar with which AS3 language and Flex framework features Swiz depends on and whether they are available in C#/Silvelright. Would this actually be possible?
Thanks so much!
Karthik
The way I see it, if you used pureMVC you could port to a new language, without too much trouble (other than what the new language will give you) your commands, mediators and proxies, provided you program your mediators to an interface, instead of a concrete component implementation, and the proxies use a services layer to get the data from server. That way you'll only have to implement the components and the service layer in the new language.
A quick look at the Swiz framework:
uses the flash event model (see CentralDispatcher)
uses some flash.net, and mx.rpc classes (see net and rpc swiz packages)
PureMVC framework doesn't use the flash event model, and eventual flash.net/mx.rpc references would normally appear in the service layer. On the other hand Swiz seems to be aimed at taking full advantage of flex, and the mxml format, so it might get the job done faster there. So you might also want to consider using Swiz for flex and PureMVC for the other languages.
Any framework, including Swiz, can very easily be ported to just about any language. Actionscript is touring complete, so theoretically any code writen in actionscript can be transformed into another touring complete language. For example, we use the Swiz framework in our mobile apps, which get cross compiled to run in iOS. There are many other open source cross compilers for a variety of languages, as well as Adobe's Alchemy project.
The only thing that is not easily portable in Swiz the usage of runtime metadata tags. This can be solved by using an advanced search and replace utility, or a custom transformation framework to convert custom metadata tags to their native code implementation. Hopefully we will see some cool new open source tools for this soon, now that Flex 4.5 was released with custom compiler hooks.
In short, I wouldn't even take portability into consideration when deciding on a framework. Choose the one which is most comfortable for you or your developers to use. I personally prefer Swiz myself.
Cheers!