As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
While I have played with parts of Qt in the past I am thinking of putting some real effort into learning it but also wondering what the potential monetary payback might be down the road. So I have some general questions about Qt's future.
What is Qt's place in the job market? Are there many, or do you sense a growing number of installations using it? What are its main competitors?
What kind of enterprise niches does Qt satisfy? Are more corporate applications trying to be cross-platform these days or do most of those efforts go the Java, etc., route?
Since being bought by Nokia I assume Qt has a viable future on mobile devices. Has this in fact been working out? Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Please feel free to comment on any aspect of Qt's future that I may have missed.
Don't have a real answer for you, but I recently saw this diagram for job trends with various C++ libraries.
They have been around since 1995, and recently some feared that Nokia would buy them to stifle the competition in favour of Symbian. Now that seems definitely out of the way by the way Qt will soon support Symbian and Maemo 5. Seeing the effort they spend in R&D and what their framework already provides on so many platforms, I wouldn't worry about their future.
As an open-source platform, I would venture Android devices are more of a competitor, rather than a possible platform, but it's just a wild guess ;-) There are some fierce debates out there on the subject.
Another real competitor would be .NET, both offer more than just IDE building tools and deal with workstations and the embedded world.
Clifford's advice about not sticking with only one framework is very wise IMHO. Another argument to start with Qt beside the advantage of covering more platforms is that it uses the C++ language, which is more demanding than C#. Starting with that will give you good programming habits, and it will be much easier to investigate something else later, be that a C# or a Java-based framework: you'll have a better idea of what lies behind the scenes of memory management (if that is not already the case, that is), and your code will be potentially more efficient.
I started using Qt in 2007. I liked it a lot, but the price meant that I couldn't use it as much as I would have wanted to.
The Nokia acquisition has been a good thing so far: (ex)Trolltech have completely opened up their development process. You have access to their VCS and bug tracker, you can contribute code, test development snapshots, open and track issues and so on. They value input from the community.
The framework is high quality and very popular in the open source world (KDE comes to mind). LGPL licensing has resulted in a bigger adoption with commercial software developers. This year's DevDays has seen a record attendance.
What is Qt's place in the job market?
I'm not based in the US so I don't know what the situation is over there. Most C++ jobs are MFC in my area. I know of a few places that use Qt.
Are there many, or do you sense a growing number of installations using it?
I've definitely seen more interest in newsgroups/forums/online communities.
What are its main competitors?
.NET on Windows, Cocoa on Mac and GTK+ on Linux. When it comes to C++ only wxWidgets, MFC or WTL could be considered as alternatives, although I would argue that Qt is in a different league from them.
Is Qt pretty much limited to Nokia offerings or does it have a place on Android devices, etc.?
Qt is also available on WinMo/CE and Linux devices. Symbian is not Nokia-only any more.
I don't think that we'll see an official Android or iPhone port. Right now they're working full steam on S60 and Maemo support.
Qt is one amongst a number for GUI frameworks and libraries, such as wxWidgets, Windows Forms, MFC, GTK+, VCL and many others. I suggest that the choice of framework is seldom a critical business decision, the choice is most often determined by such things as platform, functionality required, existing developer experience, and development tool support.
A general working knowledge of GUI frameworks is probably far more useful since it would make your skills more portable. Specialising in a single technology seldom pays in this business, flexibility and an ability to acquire new and relevant skills quickly is.
However Qt is the basis of the KDE environment, so for any Linux development targeting KDE, Qt would be a useful skill.
I know for a fact that this company's products are Qt based to provide cross-platform portability.
I've been doing contract work using the Qt framework for about two years now, for entertainment software. Here's what I have found:
It's a great toolset for developing
cross-platform applications. Easy,
fast, powerful, advanced. I never
feel constrained using it. Since it's developed in C++ you can easily embed any
number of C and C++ libraries out
there and quickly delve into the native system
APIs when you have to. If it has a niche I would say it's performance critical GUI applications, dealing with 2D/3D graphics...etc. I personally have not seen an enterprise-level company which uses Qt.
I live in the South-Eastern US
(Atlanta) - I rarely see any job
offers around here, mostly .NET or Java. The job offers I
see tend to be on the West Coast, or
overseas. However, I do see more
than I used to, probably due to Nokia's involvement.
I do feel it is growing in
popularity instead of shrinking. I
see things like QtCreator and the
like as good indications of this.
I'm doing embedded development and see Qt increasing market share with innovative ideas. Stopping QtExtended worried me for some time, but now I'm convinced QT in embedded is growing rapidly.
Not only in mobile/smart phones, but automotive as well.
Wanting your App cross-platform for Symbian AND Maemo AND WinCE AND Linux (AND all Desktop) platforms, I don't see a competing Toolkit.
Yet I have no seen a company hiring that skill, but everythin under LGPL and developments like Qt Mobility are quite new.
Qt is not available on Android, link: http://sourceforge.net/p/necessitas/home/necessitas/
And it will be made available to more platforms with project Lighthouse.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to have working experience in c++ application programming. I am in dilemma to choose game programming or standalone programming. please suggest me which framework/API is beneficial for me to learn.
Qt mobile / QT gui programming , any other APIs ,
what about learning MFC instead of QT,
are there any other gui framework than qt
On the first part of the question: I suggest you try some lightweight programming in both directions.
Now on the part of what framework to use. If you truly decide on game coding only you would probably need to go with specialized framework/engine for game development. Still, Qt will let you do some game development so you can try it for game and standalone programing before you make up your mind.
Regarding the frameworks you suggested. MFC is not popular as before and probably will not be much supported by microsoft in the future. Qt and wxWidgets are popular frameworks that will allow you to do cross platform apps. I recommend Qt because it makes coding much easier, wxWidgets becomes more useful if you are really interested in making native apps for the major platforms.
There are a variety, with different benefits and limitations. MFC is pretty much just Windows, whereas QT is cross platform, and (IMO) much more in demand in the current job market (which until recently I was searching very tenaciously!) Another popular option might be WPF, which is Windows specifc.
Short answer: do QT until 'the next big thing (tm)' comes along.
I can't give you opinions here. To gain experience, start programming in whichever framework fulfills your requirements.
Qt is good enough, and there is wxWidgets as an option. These two are cross platform unlike MFC.
As for choosing between game programming or GUI programming, you can do both, one after another.
Hope this helps!
MFC is windows and if you are mainly targetting windows, WPF is the new Micorsoft desktop GUI standard. Having said this, most games do everything in a 3D API-native (OpenGL/Direct3D) manner, and the main platform-specific parts is the windowing and user input.
There also comes a tradeoff between using an existing User Interface library compared to rolling your own. You will find it quite hard to deeply integrate Qt or WPF widgets into your game as first class citizens, and may need to jump through some hoops to do certain custom behaviours. Doing it manually from scratch comes with the benefit of really learning what is going on and being able to do exactly what you want to do; but the cost of this is you arent leveraging an existing complete library.
My personal advice is to take some time to learn either Qt or WPF (Qt if you care about multiplatform, a lot of projects use Qt, but WPF is pickup up momentum, especially due to Windows 8) just to get an idea of what a UI API looks like from the client side. Also learn the basics of a graphics API (OpenGL or Direct3D). Then you will be in a much better position to make your decision. Ultimately I would recommend creating a non-game UI program, and a seperate game program. This will give you a much better idea.
In the context of a game, you can leverage Qt/WPF/etc in the area of tools and editors. But generally realtime in-game UIs use a tightly integrated 3D accelerated UI library. One such library is Scaleform (commercial, flash-based), and another is CEGUI (LGPL/MIT).
STL/Boost cover all the low level stuff.
But what about the higher level concepts?
Windows: We have multiple windowing libs
KDE(Qt)
Gnome
Motif(C but written in OO style)
MS Windows
etc
But is anybody working on a unified standard for windowing?
Something that wrapped all the above would be acceptable. (even if it only accessed the common stuff it would be a starting point).
Networking:
There are a couple out there (including the Boost low level stuff).
But is there anybody working on a Service based network layer?
All the other stuff that Java/C# have in their standard libraries.
The stuff that makes it simpler for a beginner to jump in and say Wow done and it works everywhere (nearly).
Anyway. Here hoping there are some cool projects out there.
Edit
Maybe there is not one.
But if there are a couple that could be bundled together as a starting point (and potentially modified over time (where is that deprecated keyword)) into a nice consolidated whole.
Note: Windows is just a small part of what I am looking for. The Java/C# languages consolidate a lot more under the hood than just the GUI. What would be a good set of libraries to get all the functionality in one place.
There are too big differences between platforms to get a definitive C++ standard for GUI programming. I think Qt is about as close as you will get in the forseeable future. wxWidgets is another popular choise, but as I understand it, they are using less modern c++ features.
As for networking, I think you are being kind of vague. If you mean web services over HTTP, I would have a look at Pion.
Well it is almost 2010 and C++ almost has threads.
I'll probably get slammed for this but C++ moves too slow - to its own detriment and its user base. I readily acknowledge the difficulty of the technical and political issues involved but that's still the dirty reality of it. The language can't build in higher level concepts when it takes 5-10 years to agree on and implement the building blocks.
The reasons for this have endlessly debated but the sad truth is that C++ has relegated itself to a niche language. I like C++ but I look at the progress C#, Java, and even Python and Ruby have made over the last 5 years and I increasingly question whether C++ is worth the effort.
The Poco C++ project aims to deliver all that you ask, except for Windowing:
The POCO C++ Libraries aim to be for
network-centric, cross-platform C++
software development what Apple's
Cocoa is for Mac development, or Ruby
on Rails is for Web development — a
powerful, yet easy to use platform to
build your applications upon.
Qt might be the only framework complete enough to be what you suggest.
I guess there's some kind of keyword lookup driving the advertising here because I'm seeing a REALbasic ad, which is what I generally use for cross-platform GUI's nowadays.
I have spent a lot of time over the last 15 years working in C++ GUI's including retailing my own portability layer for CodeWarrior PowerPlant and working on the two Macintosh-based GUI code generators, including adding Windows generation to AppMaker. I've worked with wxWidgets, mainly wxPython. So, my opinion on difficulties in cross-platform GUI is fairly well-qualified :-)
Cross-platform GUI frameworks are hard to the point of nearly impossible without significant compromise - the issues come down to subtle matters of behavior which generally bother users at a level where some of them can't quantify but know that the application doesn't feel right. This is a lot harder to fix than just rendering native controls.
I started using REALbasic because their framework does a better job of getting the feel right than anything else I'd tried (I didn't get into Qt because of the expensive commercial license).
The reason it has taken so long for things to evolve is nothing to do with the C++ world moving slowly, it's just an intractable problem. The very best cross-platform Java apps do some stuff conditionally for OS/X and it is still screamingly obvious to an experienced user that they are not a native Mac app, although some are very usable and come pretty close to looking native - Oxygen XML editor and DeltaWalker are two of my favourites.
I don't think it is achievable to make a really comprehensive portable GUI library. Operating systems are just too different. Can you imagine a GUI library that would cover everything from iPhone to Windows 7 and wouldn't feel wierd on any of them?
A Boost gui library comes up occasionally.
The general opinion seems to be that the problems is too wide (are you targeting cellphones, FPS games or CAD workstations) and that it is too much work - Qt/wxWidgets has taken 10years.
see http://lists.boost.org/Archives/boost/2005/09/94453.php for a discussion.
It would have been nice because GUI usually means cross platform and threads, so all the GUI toolkits have invented their own cross platform,filesystem and thread classes. On the other hand if a standard GUI had been introduced in C++ it would probably look like TK !
What's so great about standardization ? Sure, if novice coders want to download one SDK to build portable apps, let them download Qt (or something similar) and forever remain within it's fine walled environment. But it'd be a tragedy if the C++ world revolved around that one library and boost and POCO and wxWidgets and clutter and blitz++ and eigen and and 101 other wonderful things (yes, gtkmm and ACE even) were stifled at birth because the gatekeepers of The Standard Library didn't see fit to admit them.
Diversity is good I think (although when dealing with it, it helps to have a good package manager; I've spent hours setting up build dependencies on Windows which just needed a few seconds of apt-getting on Debian).
ACE is great for concurrent communication and networking.
For cross platform windowing, there's wxWidgets. (formerly wxWindows).
Only everybody and his brother, but hardly any of them actually get anywhere.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
There are now so many ways to write windows apps, win32, MFC, ATL, .NET, WinForms, and probably some others that I don't know of. Which one should I choose? I'd like one that works on a fresh install of Vista, and is modern and easy to use.
I highly recommend Qt. It's cross-platform, very easy to use and LGPL licensed.
If you are amateur with C++ you'll have much easier time learning WinForms than any of the native Visual C++ frameworks (Win32, MVC, etc.). WPF will give you best versatily. It's a bit harder to master than WinForms but managed and so keeps you away from the nasty Win32 stuff.
The native frameworks are good mainly if you want to crunch the last bits of performance or need to keep the footprint small for stuff such as shell extensions.
I'd recommend checking WinForms at least first to get some quick understanding of the principles. If WinForms doesn't suit you, you can then move to either C++ if you feel you need more low level control or WPF if you wish more shiny features like skinning and theming.
Edit:
Though if you have a look at WPF, remember that fresh Vista contains only .Net 3.0 so 3.5 and 3.5 SP1 features require a separate runtime installation.
actuallly it's very easy to start with Qt - you get a complete SDK incl. a very nice IDE as a simple package and a smart integration into VisualStudio.
Plus the LGPL licensing which allows anybody to write opensource and closed source/commercial apps without paying any fees - the commercial support/licenses are optionally!
The biggest advantage of Qt is the very easy to learn and very very clean C++ API, which can do more than just building GUI apps (it supports low leven networking and file io etc.).
Best regards,
Chris
Short answer... It depends.
Whats your skillset/background? Why are you developing a desktop app? Is it for work or as an experiment for you to learn something new? Will there be multiple other developers working on it and whats they're skillset?
My personal preference would be winforms because that's what I spend most time coding in (in C#). They're very quick to put together and the VS IDE is very quick & stable for building the UI elements of your application. And you can publish/deploy them using Click Once which allows easy updating of the clients when you make changes & updates.
Alternatively, you might want to look at WPF which is the new Presentation Foundation in .NET 3.5. This will allow you to leverage a newer "shinier" UI experience for desktop applications.
Straight up Win32 is getting better with the Scenic Ribbon. Will work on Vista and Windows 7.
I'm probably biased (aren't we all?), but since your question states you're interested in Windows development and you want a modern and easy to use GUI framework that's works with Vista out of the box, the obvious answer is .NET WinForms.
I personally prefer gtkmm. Although it doesn't look as good as Qt or the native frameworks on Windows, I think the API is the most transparent among all frameworks I tried. It feels very OOish, and is very easy to learn. You can easily create GUI layouts with Glade, but you can also create decent designs with nothing but code. In this regard, gtkmm is similar to Java GUI programming.
I would recommend WxWidgets. The API is easy to understand; it is very well documented with samples; and it is cross-platform. If you are programming an application that is going to have any a large number of users, you will eventually want to have the option of running it on a different operating system. By choosing a Microsoft only API you will permanently put yourself into the Microsoft corner. Getting out will require a serious refactoring of your software which will require that you learn yet another API. Take my advice and start with a cross-platform API - it will save you a lot of grief in the future.
I would recommend C++Builder 2009, which can create applications that work with Windows 2000, XP and Vista.
If you go the Microsoft route, be sure to check which frameworks they are putting the most muscle behind lately. For instance, MFC is an older framework that should NOT be used for new development because MS isn't putting any time into it, and the marketplace for add-on MFC components has dried up and blown away.
Basically, when choosing MS backed technology, make sure you pick one that isn't already on the outs.
So you're a student with only PHP knowledge? Well before even considering a GUI you'll need to come up to speed in a proper language. I would suggest C# as you are already used to curly braces and you want to program Windows. WinForms is part of .Net, not a separate thing. Just download Visual Studio 2008 Express and you're up and running. By the way, GUI programming can be hard in any language, especially after you move past the stage of toy programs to real apps.
If you knew C++ to a higher degree I would have suggested Qt. Simply because the new LGPL licensing removes the final impediment. It's also cross-platform, high quality, high performance and now has the financial backing of a huge company (Nokia) to ensure further development.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Pros. and cons? how long do you use it? What about jambi?
I have been using Qt for several years now for commercial development and have been very happy with it.
One of the nice things with Qt is that it provides a large set of libraries as well as the GUI stuff (eg XML parsing, threads, networking), all in a consistent style and all multi-platform. This means we rarely need to use other libraries, though we do use boost for some things.
Another very important factor for us was internationalization. In a previous, MFC based application we had to maintain 2 localized versions, for the two languages we support. In our Qt based app we just have the one version.
The Qt translation system, using linguist is easy to use and makes supporting multiple languages easy (of course you still have to translate the strings which is a lot of work!)
The GUI layout system where the widgets resize themselves according to a layout makes everything much easier. In different languages the length of the strings are different. With fixed size widgets (like MFC) each dialog needs to be adjusted for each language, otherwise parts of labels get cut off. With Qt they resize themselves. Of course, there are cases when it does not work exactly right but it still makes everything much easier.
QString does everything in Unicode and handles the conversions from different codecs very easily.
One thing that has been very valuable is the access to the source, although e this is certainly not unique to Qt. On several occasions the ability to check the Qt source has explained some strange behaviour or given a clue how to achieve something.
We have found a few bugs in Qt, some of which have been fixed after reporting to Trolltech. In other cases they have suggested a work around. These have all been fairly obscure and not had a major impact on our development.
One of the main downsides to Qt would be the lack of 3rd party libraries for use in commercial applications. However, Qt is fairly complete so for us it has not been a big problem, though that will depend on which type of application you are developing.
I have not used Jambi either.
I've used Qt on a couple of projects I did in c++ on several platforms over a period of seven years. I think it works pretty well and definitely was quicker for me to develop a decent GUI app on the Mac than plodding through a language I didn't know (Objective-C) at the time.
I think the signal/slot mechanism is a bit funky but isn't horrible. Once you're use it for a bit, it's not a show stopper. The connection stuff is easy to bungle up (or at least it was) and it's always good to check the return on those because your app will go merrily on its way and not tell you that it didn't work.
I've never used jambi.
Here are some of my Pros and Cons with Qt:
Pros:
Cross-platform
I know this one is always used, but after going back and forth between Windows and Linux with Qt, it's amazing how little I have to do to get up and running. I think this is helped by the fact I only use Vim with Qt Designer.
QMake
This is one of my favorite aspects of Qt. After doing work in wxWidgets, FLTK, etc., I get so tired of messing around with different build systems and I don't want to manually create my makefiles. I currently use CMake on anything other than Qt right now, but I think I'm slowly moving even Qt over to CMake. However it's just so easy to get going with QMake.
QTestLib
I looked at a couple other C++ unit testing frameworks and when I created my tests using QTestLib, it felt very similar to NUnit(C#) and within minutes I had several passing tests. I also noticed that it would be very easy to create my own continuous integration environment.
Closest to Java and .Net in productivity
The biggest thing I hear/read people say about C++ is, "I can be more productive with Java or .Net". From personal experience I can get a prototype of an application running in Qt using Vim and Qt Designer, before Eclipse or Visual Studio even load. I also get a very similar set of libraries in Qt that I have in .Net or Java and if it's not there I can leverage the existing C++ code out there.
Cons:
Price
This is the biggest factor I can think of right now. However, the cost is worth every cent, um if I knew how many cents I had to save up without making a call to a sales rep. I purchased a license back in the day when they had their small business discount and it was worth it then, I would've paid three times as much and I think that's the current price.
Develop anywhere with commercial license
I would love to be able to develop on any platform, but build and sell for another platform. For example, develop on Linux, then build and deploy on Windows if you just have the Windows commercial license. From what I know, you can only develop and build a commercial application on the platform you have a license for.
Vendor lock-in
Well sort of, this is more of a personal con. I don't like being tied to a specific vendor because I get side tracked by the company direction and product direction. TrollTech was purchased by Nokia, is this good or bad I don't know, but a company that size can do evil things.
I think I'm done for now :). Oh, I haven't used Jambi but I'm really interested in doing a couple prototype projects to find out how easy it is to use a plugin developed in C++ with Jambi. Especially using Jambi as a web interface with C++ plugins.
To be honest I haven't read much on it, so it may be impossible or very easy.
I used Qt in a previous job. I'd only had the absolute briefest of contact with Qt several years prior to that, so I was pretty much a Qt newb.
When I started I was told to choose my language and environment, but cross-platform support was desirable. I tried Qt and Java, and even gave C# a go just for the heck of it. I gave myself two days to evaluate each option.
Maybe I was slightly biased with my history as a C++ developer, but after spending time on each option Qt was the only one that showed any hints at being useful without a long learning curve.
The documentation provided with Qt and the example applications made it very easy for an experienced developer but Qt beginner to get up and running very quickly. I had UI prototype/mockups of the end application done by the end of my trial period. With Java/Eclipse, Java/SunStudio and C#/VS.net I had trouble getting anything nontrivial happening in that time.
Signals/slots took some getting used to, but it wasn't too bad, and I wrote some simple wrappers to assert when connections failed to stop silly typos from stopping the app. from working.
The other thing I liked is that Qt had almost everything I needed. You name it - storage, networking, GUI, threading, containers - Qt has a class to deal with it. Which IMHO is important because mixing libraries can sometimes cause problems.
Having the source code to Qt was a big plus, one for just plain interest's sake, but also it allowed me to compile Qt using the compiler and settings of my choosing, including a debug version for use during development.
I also found Trolltech's support to be fairly good. I raised a couple of bugs on Qt, one of which was fixed and released whilst I was still working on the project (only a 6 month job).
The only negative I can recall was the difficulty in debugging Qt objects (using VS) - there is a Qt plugin for VS that can examine Qt objects but I was using the free version of VS and plugins don't work for it. But that wasn't Qt's fault.
I haven't used jambi so can't comment.
On C++ your only other alternatives are MFC and wxWidgets.
QT / wxWidgets is largely a personal preference. I do think QT is a clean design with good documentation.
QT costs about one month of developer salary if you aren't using it for GPL.
I have been using Qt for over two years now.
Things I like on Qt are:
Easy GUI programming (compared to
MFC), Qt Designer
Nice container classes
Nice graphics scene framework
Excellent documentation with useful examples
Translation support
Good technical support
I can highly recommend the Qt Developer Days. If you have a chance to take part, then do it! Lots of nice and very interesting talks there.
Qt is a very nice library, but it has an expensive per-seat developer license, so it's not always useful for all projects.
Don't use it, however...
Pro:
QT has an optional 3 phase layout, where as WX only allows for 2 currently (I believe they plan to do 3 phase, just have not worked it in yet).
One of the bigger problems with using layouts is static text and wrapping. WX asks how big is your min width/height and portions out the screen, QT has option to say how wide do you want, how high do you need to be if your X wide. This allows you to express the flow of a page much better.