We currently maintain a suit of MFC applications that are fairly well designed, however the user interface is beginning to look tired and a lot of the code is in need quite a bit of refactoring to tidy up some duplication and/or performance problems. We make use of quite a few custom controls that handle all their own drawing (all written using MFC).
Recently I've been doing more research into Qt and the benefits it provides (cross-platform and supports what you might call a more "professional" looking framework for UI development).
My question is - what would be the best approach to perhaps moving to the Qt framework? Does Qt play nice with MFC? Would it be better to start porting some of our custom controls to Qt and gradually integrate more and more into our existing MFC apps? (is this possible?).
Any advice or previous experience is appreciated.
In my company, we are currently using Qt and are very happy with it.
I personnally never had to move a MFC-app into using the Qt framework, but here is something which might be of some interest for you :
Qt/MFC Migration Framework
Qt/MFC Migration Framework
It's part of Qt-Solutions, so this means you'll have to buy a Qt license along with a Qt-Solutions license. (edit: not any more)
I hope this helps !
(This doesn't really answer your specific questions but...)
I haven't personally used Qt, but it's not free for commercial Windows development.
Have you looked at wxWindows which is free? Nice article here. Just as an aside, if you wanted a single code base for all platforms, then you may have to migrate away from MFC - I am pretty sure (someone will correct if wrong) that MFC only targets Windows.
One other option would be to look at the Feature Pack update to MFC in SP1 of VS2008 - it includes access to new controls, including the Office style ribbon controls.
It's a tricky problem, and I suspect that the answer depends on how much time you have. You will get a much better result if you port your custom controls to Qt - if you use the QStyle classes to do the actual drawing then you'll end up with theme-able code right out of the box.
In general, my advice would be to bite the bullet and go the whole way at once. Sure, it might take longer, but the alternative is to spend an age trying to debug code that doesn't quite play ball, and end up writing more code to deal with minor incompatibilities between the two systems (been there, done that).
So, to summarise, my advice is to start a branch and rip out all your old MFC code and replace it with Qt. You'll get platform independence (almost) for free, and while it will take a while, you'll end up with a much nicer product at the end of it.
One final word of warning: make sure you take the time to understand the "Qt way of doing things" - in some cases it can be quite different to the MFC approach - the last thing you want to do is to end up with MFC-style Qt code.
I have lead a team doing this kind of thing before (not MFC to QT but the principles should work).
First we documented the dialogs and what their inputs, controls and outputs were. Also, we create several test cases especially for any clever logic inside the GUI.
Sometimes we had to refactor some business logic to provide a clean interface the GUIs but this is the way it should have been done in the first place tbh.
Now we had a list of GUIs, inputs, outputs, tests and an interface that the encapsulated GUI had to match.
We began, project by project, to create equivilant GUIs to the old ones. Once we did that we could slot the GUI in where the old one was, rebuild and test it. At first we tripped a lot but we soon worked out the common errors and fixed them. We navigated (I think) 612 dialogs although there was a team of about a dozen of us working on it.
Related
I'm developing my first Windows desktop application and I'm trying to figure out what the best approach would be to create the program's GUI.
I know, I know... I feel stupid for asking considering the amount of data on the subject on SO. However most answers seem outdated and I'm not sure if they fit my specific project. Also tutorials for Windows 8 'metro apps' are clogging my Google search results, which is NOT what I'm looking for.
I use Visual Studio. I've followed tutorials. I have basic knowledge of C and Java and extensive experience with PHP. I'm excited to learn C++, so I'm not looking for GUIs to create a GUI (like WinForms). I also don't care about managed code and portability for now, especially since I'm trying to avoid dependencies (i.e. users having to install .NET). As long as it runs smoothly on Vista and up, I'm happy.
The application
The software will teach basic physics to kids. I'd like to create a main area and a sidebar. The main area will feature a physics animation, say a bouncing ball, along with some Q&A. Users can zoom in to the animation to measure some stuff and answer the question. Users can track their progress in the sidebar. That's pretty much it.
What I've found so far
I'm getting a bit frustrated with MSDN. Most of their examples are given in four different languages (C#, C++, etc). I can't seem to get more than a bit of Hello World code from them.
I found a GDI API on MSDN and it seems like a good start for me. However I've read quite a few answers on SO saying creating layouts in pure C++ is really hard, that we're better of using frameworks like ATL and WTL. Since I'm also going to create (somewhat interactive) animations, I've wondered whether I should use gaming-targeted APIs like Direct2D.
Since all of this is new to me, and there are a lot of options, I don't know where to start for my particular application. Any tips would be greatly appreciated!
Using the raw Win32 API (no additional downloads or third-party helpers):
Here's a good primer (introduces dialog boxes, text boxes, buttons, etc): theForger's Win32 API Tutorial
And here's where you go from there (numeric up-downs, list boxes, combo boxes, tooltips, and more): Common Controls on MSDN. Most of these require you to #include <commctrl.h>.
I also found this to be a good resource that covered what the other two didn't: Win32 Developer - Window Assets
But the Win32 API doesn't seem like it does exactly what you want. A physics app for kids should have a more visual GUI than the API can provide. Good luck, though!
If you're ok with adding additional Frameworks, I'd suggest looking at Qt.
It allows to create the GUI from code only, has a good structure, and has an Interface for 2D drawing, if required.
If you are concerned about dependencies, you only have to include the Qt DLLs to your executables; no installation is required for the user.
To get started, see my (old) tutorial "Lessons in Windows API Programming".
But you really need a good book, such as edition 5 or earlier of Charles Petzold's classic "Programming Windows".
The problem with latest edition is that it's for C# and .NET, with Charles grabbing the tail of the "new way" at just the wrong time…
Disclaimer: I haven't checked the details of edition numbers.
Using the Windows API is the simplest, but producing advanced GUIs can take a very long time. Microsoft Foundation Class is a way to make the Windows API more user friendly and OOP. Does anyone have any experience with MFC?
Why not use some 2D C++ game engine, like HGE: http://hge.relishgames.com/overview.html.
Is Qt an interesting platform for business apps development, outside of Nokia phones ?
Why ? Strong points ?
Thanks
I like Qt because:
Very well-designed framework, e.g. signal-slot, model-view, graphics view/scene/item/proxy, painter/paint device/paint engine..., too many to be listed here!
Excellent documentation!
Cross platform language/API, as well as tools like UI designer, creator, and so on.
Rich features, e.g. graphics framework, network library, database engine, and so on.
Active community, and active development.
There should be more. If you have ever used it, you'll find it's easy to build your framework upon Qt.
I didn't have any complain to Qt. If I have to say at least one disadvantage here, "convention". You must adopt the convention of Qt, e.g. You have to use moc to make the meta object of your objects, and it's easier for developers to use Qt's vector, list, auto_ptr than STL, tr1. But I never found any issue caused by that. On the contrary, it works very well.
In my opinion, Qt is the state-of-the-art C++ framework in this modern world!
P.S. There are a lot of commercial applications built on Qt. You can find it under Qt's official website. But I'd like add one more here: Perforce, one of the top commercial source code management tools, built its client tool on Qt for Windows/Linux/Mac.
yes it is .. just look at kde apps :)
or see more applications made by qt
and it has alot of bindings in many languages
Documentation
cross-Platform IDE
further reading
may be this is not so related to the question ... but my first deal with qt was just great starting from their well organized Documentation to their great widgets
the GraphicsView is just ammazing ! :)
It's about the only current/modern C++ gui library on Windows.
MFC is so old you have to write comments in Latin
WTL would be nice if they had finished it before abandoning it.
Winforms/WPF + managed C++/CLR - all the fun of several incompatible new technologies at once.
Bad points:
To fit on lots of platforms they have invented their own solutions to things that are now in the STL/Boost
The signal/slot mechanism - tricky to debug and silently fails (with no error) with simple typos.
Although everything is possible it's sometimes a lot of effort to do simple things (they do love MVC) compared to Winforms.
Qt is simple
Qt is powerful
Qt is NATIVELY-CROSS-PLATFORM
Qt is REALLY-CROSS-PLATFORM
Qt is comprehensive (but the Media side of it still needs to grow)
Qt doesn't require Garbage Collection, but it embeds a GREAT model of memory management that makes you forget about memory deallocation
Qt is solid
Qt is modern
Qt proposes some new paradigm of programming that are really good (Signals-Slots)
Qt runs a lot of VERY successful software: (Skype, Google Earth...)
Are those points strong enough?
Maybe you have heard about Google Earth which happens to be programmed in Qt too.
That aside, I like Qt for my in-house development because it
is very well supported and documented,
allows me to write simple and decent-looking apps that are
works cross-platform for Windows and Linux with little effort, and
contains nice to have components for database access, regexps, guis, xml, ...
I also use the Qwt widgets for easy real-time plotting on top of Qt.
I really dont understand whats the point in underestimating tools/frameworks which makes things easy for programmers. Qt is too good for GUI development, I would say its much better than any current existing crossplatform app development suite.
So many advantages, I have been using it for more than three years now for a product to be deployed in Linux/Win environments. The app is thread intensive and initially we had a tough time using pthreads and its conterpart for windows. Then we switched to Qt(and QThreads eventually) and things were a breeze...
Backed by active development, a highly helpful and supportive community along with excellent documentation, training, certification programs, videos, forums... its easy, fast and effective to develop in Qt. You should see the video which they create a web browser in just five mins!
Its really 'cross platform', and it doesnt have a software wrapper(like Java does) to enable this which makes it faster. Cmon, we all know java apps have buttons which takes a second to respond to even a simple 'click'.
I hope Qt will someday do a take on Java. :D
after all, 350000 developers cant be wrong when they chose Qt.
Pixar uses Qt (or at least, used, as of 2005) internally for certain parts of their tool suite (called "Marionette" in the marketing) collectively called Menv, ("men-vee" for Modelling ENVironment)---at least for their lighting sub-tool Lumos.
I have a significant codebase written in MFC and am tasked with creating a port for Mac OS X. I know that I'm going to have to roll up my sleeves at some point and do alot of grunt work to get everything working correctly, but are there any tools out there that might get me partway?
I'm working on one.
From the GUI point of view, the new version of AppMaker is based around an import/generate model. Most of commercial work I've done with AppMaker has been the other way, porting Macintosh applications to Windows. However, there's no reason why the same principles can't be applied in reverse.
AppMaker v2 had a very good importer for PowerPlant UI resources and traditional Mac dialogs. As it is only able to run on Classic, that code base has been discarded (you really don't want to know) and the final generator languge I wrote for AppMaker v2 is an XML exporter which dumps the entire object model to an extended XAML.
I already have a XAML UI generator and am currently working on a Cocoa xib generator - one of the reasons for going to WWDC in June. The focus at this time is on import/generator suites before returning my attention to a GUI editor.
I wrote PP2MFC to allow PowerPlant applications to be compiled for Windows - a cross-platform solution needed because no other framework or cross-platform tool at the time (1997) would perform well enough for the hardware requirements. I've since discussed an opposite program with someone I could chase up and I'm sure an MFC portability layer could be created to map to Cocoa objects. Whilst many developers have a poor opinion of MFC's message-map architecture, the heavily macro-based API sits on top of a reasonably clean OO framework.
This is the kind of project where you need to think about long-term maintainability - do you want something which ends up as large chunks of MFC code working with Cocoa or do you want to migrate to an idiomatic Cocoa program.
Any further discussion should probably be taken off SO - contact me at dent at oofile.com.au but I'm happy to debate technicalities and feasibility on here. The combination of code generation and skinny framework adaptor layers works better than most people expect.
Honestly, the models are so different that I suspect you're going to need to do a nearly complete re-code at least of most of the UI parts.
No, Such a tool would be pretty much impossible to write.
MFC and Cocoa are such fundamentally different platforms there is no easy way to convert between the two.
Depending on how you've written your applications, you will either need to write the GUI portion of your code or even the whole codebase.
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 4 years ago.
Improve this question
I'm spending these holidays learning to write Qt applications. I was reading about Qt Designer just a few hours ago, which made me wonder : what do people writing real world applications in Qt use to design their GUIs? In fact, how do people design GUIs in general?
I, for one, found that writing the code by hand was conceptually simpler than using Qt Designer, although for complex GUIs Designer might make sense. Large GUIs might be possible using Designer, but with time they might become very difficult to manage as complexity increases (this is just my opinion). I also downloaded the AmaroK source code to take a peek at what those guys were doing, and found many calls to addWidget() and friends, but none of those XML files created by Designer (aside: AmaroK has to be my favorite application ever on any platform).
What, then, is the "right" way to create a GUI? Designer or code? Let us, for this discussion, consider the following types of GUIs :
Simple dialogs that just need to take input, show some result and exit. Let's assume an application that takes a YouTube URL and downloads the video to the user's hard disk. The sort of applications a newbie is likely to start out with.
Intermediate level GUIs like, say, a sticky notes editor with a few toolbar/menu items. Let's take xPad for example (http://getxpad.com/). I'd say most applications falling in the category of "utilities".
Very complex GUIs, like AmaroK or OpenOffice. You know 'em when you see 'em because they make your eyes bleed.
Our experience with Designer started in Qt3.
Qt3
At that point, Designer was useful mainly to generate code that you would then compile into your application. We started using for that purpose but with all generated code, once you edit it, you can no longer go back and regenerate it without losing your edits. We ended up just taking the generated code and doing everything by hand henceforth.
Qt4
Qt4 has improved on Designer significantly. No longer does it only generate code, but you can dynamically load in your Designer files (in xml) and dynamically connect them to the running objects in your program -- no generated code however, you do have to name the items in Designer and stick with the names to not break your code.
My assessment is that it's nowhere near as useful as Interface Builder on Mac OS X, but at this point, I could see using the Designer files directly in a program.
We haven't moved back to Designer since Qt3, but still use it to prototype, and debug layouts.
For your problems:
You could probably get away with using the standard dialogs that Qt offers.
QInputDialog or if you subclass QDialog, make sure to use QButtonDialogBox
to make sure your buttons have the proper platform-layout.
You could probably do something more limited like xPad with limited Designer functionality.
I wouldn't think you could write something like OpenOffice solely with Designer but maybe that's not the point.
I'd use Designer as another tool, just like your text editor. Once you find the limitations, try a different tool for that new problem. I totally agree with Steve S that one advantage of Designer is that someone else who's not a programmer can do the layout.
In my experience with Qt Designer and other toolkits/UI-tools:
UI tools speed up the work.
UI tools make it easier to tweak the layout later.
UI tools make it easier/possible for non-programmers to work on the UI design.
Complexity can often be dealt with in a UI tool by breaking the design into multiple UI files. Include small logical groups of components in each file and treat each group as a single widget that is used to build the complete UI. Qt Designer's concept of promoted widgets can help with this.
I haven't found that the scale of the project makes any difference. Your experience may vary.
The files created with UI tools (I guess you could write them by hand if you really wanted to) can often be dynamically loaded at run-time (Qt and GTK+ both provide this feature). This means that you can make layout changes and test them without recompiling.
Ultimately, I think both raw code and UI tools can be effective. It probably depends a lot on the environment, the toolkit/UI-tool, and of course personal preference. I like UI tools because they get me up and running fast and allow easy changes later.
The organisation I work for has ported its GUI application to Qt several years ago.
I think there are several aspects that are worth mentioning:
Working with Qt Designer, at least at that point, was not a realistic option: there were too many features that couldn't be done with Qt Designer;
Conventions and structure that had to be preserved prevented the use of Qt Designer;
Once you've started without Designer, it is probably difficult to return to it;
the most important aspect, though, was that the programmers were very much used to programming using vi or emacs, rather than using a GUI IDE.
My own experience, which goes back approx. 4 years, using Qt3.3, is that dynamic behavior in dialogs was not possible to realise in Designer.
Just to say I've written and maintained complex GUIs in Qt without using Qt Designer -- not because I don't like Qt Designer, but because I never got around to working that way.
It's partly a matter of style and where you're coming from: when I started on Qt, I'd had horrible experiences of Dreamweaver and Frontpage and other visual HTML tools,and far preferred writing code with HomeSite and resorting to Photoshop for tricky layout problems.
There's a danger with visual code IDEs that you try to keep within the visual tools, but end up having to tweak code as well -- in ways that aren't well understood.
Learning iPhone development, for example, I've found it frustrating to hit 'magic' visual stuff ('drag from the empty circle in the Connections inspector to the object in the Interface Builder window...') that would be simpler (for me) to understand in plain old code.
Good luck with Qt -- it's a great toolkit, however you use it, and Qt Creator looks like being a great IDE.
I'd add that one of the reasons for using graphical designer was the lack of layout managers in Win32, for instance. Only absolute positioning was possible, and doing that by hand would have just sucked.
Since I switched from Delphi to Java for GUI apps (back in 2002), I've never used designers any more. I like layout managers much more. And yeah, you get boilerplate code, but moving objects on a UI designer may take as much time as changing the boilerplate. Plus, I would be stuck with a slow IDE; that's for the Java/C# case, OK, while for Qt (especially Qt4) it doesn't apply. For Qt3, I wonder why one should edit the generated code - wasn't it possible to add code in other files? For which reason?
About the discussed cases:
1) Hand Coded GUI is likely faster to write, at least if you know your libraries. If you're a newbie and you don't know them, you may save time and learn less with a designer, since you don't need to learn the APIs you use. But "learn less" is the key factor, so in both cases I'd say Hand Coded GUI.
2) Menu bars are quite annoying to write code for. Also, think to details like accelerators and so on. Still, it depends on what you're used to. After some time, it may be faster to type that boilerplate than to point-and-click into designer to fix all those properties, but just if you can really type like into a typewriter (like those admins for which typing Unix commands is faster than using any GUI).
3) I'd extend the answer for case #2 to this one. Note that, for Win32 platforms, it may be possible that using designers which generate Win32 resources might be faster to load (no idea about that).
However, I'd like to mention a potential problem with using Qt Designer there. Real world case: it took some seconds (say 10) to load a complex Java dialog (the Preferences dialog box for a programmer's text editor) with a lot of options. The correct fix would have been to load each of the tabs only when the programmer wanted to see them (I realized that after), by adding a separate method to each preference set to build its GUI.
If you design all the tabs and the tab switcher together with a designer, can you do that as easily? I guess there might be a similar example where a hand coded GUI gives you more flexibility, and in such a big app, you're likely to need that, even if just for optimization purposes.
One of the main benefits of using designer to create GUIs is that other programmers can change or maintain forms and widgets easily without the need to delve in to a complex code.
Its strange that you're saying the writing code is simpler than manipulating objects in a graphical environment. It's a no-brainer.
The designer is there to make your life easier and in the long term it makes your code more maintainable. It's easier looking in the designer to see what the your UI looks like then reading the code and trying to imagine what it might look like.
With current Qt you can do almost everything from within the designer and the very few things you can't do, you can fix with very few lines of code in the constructor.
Take for instance the simplest example - adding a signal-slot connection. Using the designer it's as simple as a double click. Without the designer you need to go lookup the correct signature of the signal, edit the .h file and then edit write your code in the .cpp file. The designer allows you to be above these details and focus on what really matters - the functionality of your application.
I like to first turn to the designer to develop GUI widgets. As mentioned in the other posts, its faster. You also get immediate feedback to see if it "looks right" and isn't confusing to the user. The designer is a major reason I choose Qt over other toolkits.
I mostly use the designer to make the one-off dialogs.
Having said that, I do the main window and any complex widgets by hand.
I think this is the way Trolltech intended. QFormLayout is a class they provide to easily programatically create an input dialog.
By the way, the designer in Qt 4 is not an IDE like the one they had in Qt 3. It's just an editor for editing .ui files. I like it that way. The new cross platform IDE is going to be called Qt Creator.
It's an old post but I would advise you to look at Clementine - a music player which (I think) derives from Amarok. They use Qt4 and from what I can see there is a ui folder in the src folder of the project. In the ui folder as one might expect they have all sorts of .ui files. If you compile and start Clementine you will see that the GUI is fairly complex and quite nice.
For me, it depends how much logic is encapsulated in the widget/GUI. If it's just about simple forms, I prefer to use QtDesigner.
If it contains complex checks or interaction, I tend to program it.
We're using the Qt Designer if anyone needs to create a Gui.
The thing is to create just little Widgets for certain tasks (like you would do in a class-design) and then get them together into a "parent-gui".
This way your widgets are highly reusable and could be used for Guis in a modular way. You just have to specify which signals each Widget is sending and which slots they provide.
We additionally are creating .ui-Files which than could be generated during build-process. Until now there was no need to edit those files by hand.
Build different parts of your UI
in different .ui files using QtDesigner,
then bring them together (and add complications) in code.
There are things you can't do in Qt Designer, you can only do in code,
so Qt Designer is just one (great) part of the tool chain.
I see many user interface control libraries for .NET, but where can I get similar stuff for win32 using simply C/C++?
Things like prettier buttons, dials, listviews, graphs, etc.
Seems every Win32 programmers' right of passage is to end up writing his own collection. :/
No MFC controls please. I only do pure C/C++. And with that said, I also don't feel like adding a multi-megabyte framework to my application just so that I can have a prettier button.
I apologize for leaving out one tiny detail, and that is that my development is for Windows Mobile.
So manifest files are out.
I just notice how many developer companies have gone crazy with making pretty looking .NET components and wondered where the equivalent C/C++ Win32 components have gone?
I read about how many people ended up writing their own gradient button class, etc. So you would think that there would be some commercial classes for this stuff. It's just weird.
I'll take a closer look at QT and investigate its GUI support for such things. This is the challenge when you're the one man in your own uISV. No other developers to help you "get things done".
I've used Trolltech's Qt framework in the past and had great success with it:
In addition, it's also cross-platform, so in theory you can target Win, Mac, & Linux (provided you don't do anything platform-specific in the rest of your code, of course ;) )
Edit: I notice that you're targeting Windows Mobile; that definitely adds to Qt's strength, as its cross-platform support extends to WinCE and Embedded Linux as well.
The Code Project has lots of UI controls for C/C++
Most of them are focussed on MFC or WTL but there are some that are pure Win32.
As an aside if you're not using a framework, you really should consider WTL over pure Win32. It's low overhead and about a million times more productive.
For prettier buttons, etc., if you aren't already doing it, embed an application manifest so that your program is linked to version 6 of the common controls library. Doing so will get you the Windows XP- or Vista-styled versions of the standard Windows controls.
If you want types of controls beyond what Windows offers natively, you'll likely have to either write it yourself or be more specific about what kind of control you are looking for.
I you don't mind using the MFC libraries you should try the Visual C++ 2008 Feature Pack
Stingray
CodeJock - Toolkit Pro for MFC/ C++
The MFC feature pack is derived from BCGSoft components.
Using winAPI's you can do almost anything you want and really fast too. It takes some time to figure it out but it works. Go to MSDN, lookup MessageBox(), check out DialogBox() and go from there.
I personally do not care for MFC by the way. If you want to use an MFC like approach I'd recommend Borland's C++ Builder. Pretty old but still very usefull I think.