 |
Migrating from MFC to Qt: Questions and Answers
|  | |
Why would I want to move my application away from the
Microsoft Foundation Classes (MFC)?
|
 | |
There are several reasons why you may want to do that:
 |
To bring your application into the
future, and stay current with the state of the
art in GUIs. According to Microsoft (ref.
MSDN Webcast), MFC is
"becoming dated as an application
framework", and moving forward, Microsoft is "not
going
to put in a lot of investments for adding new
UI functionality into MFC".
|
|
To let your application run on other platforms
in addition to MS Windows. The rapidly growing
adoption
of Linux in particular means that you will
want to be prepared for your users demanding
that your application can be supported that
platform.
|
|
To increase productivity. Programmers
generally agree that when compared to using a
more modern toolkit, development with MFC is
more complex, tedious, and error-prone. Also,
while MFC covers only GUI functionality,
productivity gains can be had by employing a
more complete toolkit which avoids the
developers having to resort to other,
unrelated APIs for handling tasks like
networking, multi-threading, database access,
etc.
|
 Back to index |
| | |
Moving my application away from MFC, why would I
select Qt as the toolkit to move to?
|
| |
The features of Qt in general are presented on the
main product
page. For moving an existing MFC
application, the following facts are particularly
relevant:
|
Qt is actively maintained and developed.
|
|
Qt lets you target multiple platforms (Linux,
Unix, Windows, Mac) with a
single source code base.
|
|
Qt is commercially developed and commercial
support, training and consultancy services are
provided.
|
|
The Qt API has an intuitive, logical design
that makes it easy to learn and efficient to
use.
|
|
Qt is a C++ toolkit, just like MFC. This means
that the porting job will be much simpler, and
allow for a much higher degree of code reuse,
than than if porting to e.g. Java or .NET/C#.
|
|
Through the
Qt/MFC Migration Framework, MFC
applications can be partly and gradually
ported to Qt. It is not necessary to do the
entire port in one go.
|
|
Qt provides a consistent class API that covers
both GUI and all the operating system
functionality needed by most applications.
|
Back to index |
| | |
If my goal is to get my MFC application to run on
Linux, Unix, or Mac, how does a Qt-based solution
compare to a
solution using a Windows/MFC emulation toolkit?
|
| |
Initially, a Qt-based solution will usually require a
larger porting job. From that one-time investment,
there are significant rewards:
|
Qt applications do not require any separate
emulation toolkit or runtime system to be
installed on the target machines. That also
means that there are no version conflicts
and maintenance hassle when the application
and/or the toolkit needs to be updated.
|
|
Qt applications have native look and feel on all target systems.
|
|
Qt applications have native performance, and
have low memory requirements: The entire Qt
runtime library is only around 5 Mb.
|
|
Qt applications can be distributed without
paying any royalties or run-time fees.
|
|
In addition to Linux, Qt applications can be
run on practically any Unix variant, as well
as Mac OS X and embedded Linux.
|
Back to index |
| | |
Can you point me to any comparisons between MFC and Qt?
|
| |
Of course:
|
Many Qt users that have converted from MFC
have offered their comments in our discussion
forum. There are too many to be listed here;
they can be found by searching for MFC in the
qt-interest archive.
|
Back to index |
| | |
Do you have any reference companies that have converted from MFC to Qt?
|
| |
Many companies have done this; we have portrayed just a few of them:
Back to index |
| | |
How would I move my application from MFC to Qt?
|
| |
To get an overview of the porting job, start out by
identifying which modules of your application that
will need to be modified. Obviously, this includes any
code that use MFC classes. If you want the Qt
application to run also on non-Windows systems, it
will also includes modules that use other
Windows-specific APIs. For example, code that uses the
Direct3D API can only be run on Windows. OpenGL
libraries, on the other hand, are available on all
platforms, so it will not be necessary to rewrite code
that uses OpenGL. However, if you only need the Qt
application to run on Windows (at least in the first
iteration), Direct3D code, for example, can be
kept. In this case, you also have the option of
keeping Windows/MFC modules, and integrating them with
Qt through the Qt/MFC Migration Framework. Internal
modules, i.e. modules that do not use external
libraries, can be reused as is.
Back to index |
| | |
Are there any tools for the job?
|
| |
Yes, the GUI layout of Windows dialogs can to some
degree be
automatically translated to the Qt equivalent,
ref. KDAB's tool KNUT.
Back to index |
| | |
How long time will it take me to move my application from MFC to Qt?
|
| |
Naturally, that depends on the number and size of the
modules that require porting. However, other factors
are also important. If the code is well modularized,
it will be easier to isolate modules that do not
require modification. In particular, the porting job
will be quicker the better the GUI is separated from
the functional code or business logic. Another
important factor is the skills of the programmers
doing the job. In general, you can expect to find that
Qt skills are more useful than MFC skills for such a
porting job. As a general rule of thumb, the modules
that require modification can usually be ported at a
speed of 200-500 lines of code per man-day.
Back to index |
| | |
Is there any assistance available?
|
| |
Yes, Trolltech and our partners can offer expert help
with your porting project. Contact
sales@trolltech.com for details.
Back to index |
Other questions? Contact us at info@trolltech.com!
|
|
