Slashdot Mirror
wxWindows vs. MFC
EvanED queries: I'm going to devoloping a chess program, and was until a couple days ago planning to do it in MFC. But then I ran across wxWindows. I think it would be cool if it were able to run under Linux. (At the moment, I do not have Linux on any computer but will as soon as I get my own machine.) Do the benefits of supposed cross-platformness outweigh the drawbacks of having to learn a new system and not having all the (incredibly wonderful) automatic code generation features Visual C++ provides for MFC programs? Or would it perhaps be better to write it in MFC since I am reasonably familiar with it then port it to wxWindows?"
wxWindows provides a nice api that renders using a native method (windows uses windows controls, unlike qt which draws its own).
.Net (which also means platform lockin).
:-)
MFC is not going to be supported by microsoft now because of
I can never recommend qt, because of its wierdness with having a preprocessor of its own. If you could, Objective C would be a nice language to do it in
What we see depends on mainly what we look for. -- John Lubbock Now search for that bug slave!
I can pretty much guarantee that you will be more productive and have your product out the door faster, event if you need to ramp up on both Python and wxWindows.
Lots more information at:
Look into Qt as one of your options. It is very mature, widely used, intuitive, and now supports Mac OS along with MS Windows and X-Windows. From a Free Software perspective, one downside is that you have to purchase a license for Windows development and/or commercial development (upside: it remains free for Free Software). If you have no budget and are set on the Windows platform, then Qt is not the best option.
In any case, I wholeheartedly recommend that you do not use MFC. My argument is that developing software around proprietary APIs is very risky. I've witnessed serious problems arise in long-term projects when API vendors go under or stop supporting their products. The fact that Microsoft is #1, etc., does not reduce the long-term risk, since all companies is mortal (and more than a few people argue that MS' days are numbered). If you want to make sure the long hours you put in now don't go to waste later on, choose your APIs wisely, and, no matter the API, find ways to compartmentalize your program to isolate risks.
Healthcare article at Kuro5hin
If you are a newbie, then write it in MFC. Porting to wxWindows is easy--I recently ported an MFC project at work to wxGTK on Solaris, and chaning all the MFC calls to wxWindows calls only took a couple of hours for a 2 man-month project.
If, on the other hand, you are confident with MFC, then just skip it and write straight to wxWindows. Basically, if you write in MFC with VC++, you can use all the class wizard stuff to set up message maps and create stub functions, etc, and it's just faster to get it up and running if you don't know how to do this yourself. Then, you can do easy search and replace to convert to wxWindows. For example, all of your Invalidates become "Refresh," all of your CDCs become wxDC, CString becomes wxString, etc etc. You will have to make a couple of small changes here and there, but search and replace will be 90% of the work.
If you know how to set up the message maps and whatnot yourself, then just take one of the example programs (it comes with loads of examples) and start modifying to taste. There is really good documentation on the website, although I found the search capabilities cumbersome.
This is a question you can only answer yourself. It's always more work to take more than one platform into consideration, and wxWindows is no panacea in this regard. Only bother with cross platform coding if you really indend for the code to be run across platforms. That said, wxWindows is nicer to use than MFC, although for a Windows-based chess program, I doubt you'll be able to avoid MFC entirely. MFC just does more than wxWindows.
This autogenerated code is so awful, I used to create it just to frighten people: "Look how many lines of code it takes for this dialog box!! Pay me more!!" MFC is the single largest reason I've given up on Windows programming permanently (Winsock is a close second). Since this is clearly a learning experience for you (right?), then go ahead, play with MFC. Nothing teaches like pain. But be warned, MFC plus Visual C++ can make you hate real C++ by warping your mind. __int32 indeed.
This is the path of greatest work and quite likely greatest learning. If you'd like to pursue the path of least pain to produce a truly cross-platform GUI app, I suggest, from experience, TrollTech's QT.Qt does require a strange precompiler. This is the biggest reason I avoid it. I'd rather my programs remain standard C++.
If you want real portablity, use an ASCII terminal for the display. You'd have a better chance of getting that to work 10-20 years from now than wxWindows, Tk, or MFC.
-- Argel
Not really a huge deal... just think of the non-standard Qt constructs as macros and go about your life. MFC/VC generates code too, the same as Qt's moc.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
CLX is the cross platform version of Borland's VCL which is used in Delphi and C++ Builder. Delphi has a counterpart in Kylix that would allow dual development for both Linux and Windows.. the only downside being you would have to know Delphi (Object Pascal). But it seems as a great multiplatform tool. There are free personal versions of Delphi and Kylix on Borland's website for GPL use, but to distribute a commercial application without the initial popup you would have to purchase one, get someone else to compile them for you, or compile both in Delphi and Kylix. Good luck in whatever you choose.
if you use .Net with GTK#, you not only help out the development effort of gtk# (by testing) and mono (if you go for the whole platform-independent thing), you learn a toolkit that is going to be commonly useful. I don't know much about wxWindows, only that its never been a requirement for any job i've interviewed for, and as far as i'm concerned, MFC is dead... yeah, there's still a lot of apps written in it, but very few new ones.
First, having used both MS Visual C++ and Borland's C++ builder, I almost take offence to the statement that Visual C++ has nice GUI building and code generation features. It is strictly a minimal tool. Borland's GUI designer is actually fully featured and well integrated.
Now, on to Qt -- it is a C++ API, it is clean, very portable and very easy to use. It used to cost money for a development license for anything on windows, but it no longer does. See the Windows non-commercial edition. I work on a project which uses Qt for the GUI, and that source builds unmodified on Linux, Win32, SunOS, AIX, IRIX, and (I think) Mac OS X.
In addition, it also has a nice graphical designer with some nice code generation features, and excellent documentation.
Their "pre-processor" is in fact what lets the code REMAIN standard C++ -- it does NOT require language extensions to operate, unlike MS VC++ and Borland C++ Builder.
They've been around for something like 10 years, too. This is a mature product. And no, I don't work for them or own stock (if it exists) -- just a pleased user.
I always felt if someone thought VS's "automatic code generation" is anything other than an annoying waste of time, you've either never used it, or are only a cookbook programmer, and you don't sound like either.
Starting from scratch, I'd be more inclined to go with wxWindows, although I personally would get up and running much faster with MFC since I have used it for years.
MFC makes some things easier, but many features carry an obscene amount of bloat, and are often less hassle to write from scratch than deal with Microsoft's way of doing things (I certainly found that to be the case for doing ftp... using MFC required writing more code than doing it from scratch!)
You are in a maze of twisty little passages, all alike.
VC++ does not require language extensions. I would, of course, not recomend you try to use MFC with any compiler except VC++ because it'll probably drive you up the wall.
VC++ and wxWindows both require lots of macros, however.
Gentoo Sucks
Absolutely, cross-platform is worth a lot.
If you use MFC, you tie yourself to whatever Microsoft decides about its money-making schemes.
wxWindows is here to stay. The GUI is native on any platform. Yes, there may be slow-downs in development, but the need will not go away.
Within two years, after governments evaluate the security risk of using U.S. software, they will pass laws that government workers must use Linux or BSD. That will cause the movement away from Windows to accelerate.
There will come a time when Linux is the dominant OS. It would be unfortunate if you could not run your program on Linux.
No, but MFC does. Try compiling any MFC app with the standard compliance compiler options set in VC++ and see the fireworks. This is one of the major reasons that VC++ still has bizarre non-standard behaviour in places they should long since have fixed; it would break millions of lines of existing MFC-based code if they changed it.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
What about java. Cross platform, has AWT and Swing, can do 2D graphics and 3D graphics, even has xml in 1.4
What will you lose?
Be very wary of starting any application using MFC extensively if you want to port. Because MFC insists on being an "application framework" rather than simply a GUI library, it forces concepts and designs upon you that simply do not translate well to the more usual idioms employed by almost every other GUI library. You could pick most of the others and later move/port to a different one with relative ease, but not to/from any extensive use of MFC.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Uhhh... no. See the SSDF Rating List.
[disclaimer: I'm a wxWindows developer]
The main advantage wxWindows has over Qt is that it has truely native look and feel (LNF). Try running your Qt program under Windows XP and compare it with a wxWindows one -- which one looks really native? Personal preferences aside (i.e. forgetting that I hate XP LNF), wxWindows clearly fullfills the goal of allowing you to create native looking applications better. The same goes for wxGTK port: Qt apps will never use yyour current GTK+ theme, but wxGTK ones will.
Further, why ask "why not just use Qt"? Why not rather ask "why use a proprietary and closed (in the sense that you can't modify it nor participate in its development) library instead of completely free, open and at least in some ways superior one"?
Sounds like you've got a pet project you'd like to develop in order to get your feet wet. Which I heartily recommend. And maybe it will lead to bigger and better things, as time goes on -- maybe even commercial possibilities -- who knows? Or if not, at least it will be fun.
I've used MFC and wxWindows quite alot. MFC is quite primitive by comparison to wxWindows -- the MFC design is old, and it shows. For example, try making a resizeable dialog in MFC! If you use MFC, you'll be stuck with Windows. Porting the app to wxWindows (or any other GUI framework) will be non-trivial -- you'll be writing from scratch, using your MFC app as a model. Not that that would be all bad -- it's one way to iterate toward a good design. But really, there are faster ways to get to a good design. So, MFC is basically bad, mostly because it ties to you Windows, and secondly because the GUI framework is excessively primitive.
wxWindows is free. Not GPL -- just plain old free, almost anyway (you'll have to read the fine print -- I think you have to give attribution, etc -- but there is no restriction on selling your creation). That trumps Qt, which is a much GUI framework (on technical merits alone, Qt is hands-down the best C++ framework that I've seen). The problem with Qt is that you must decide up-front whether you're going to create a forever-free (GPL-style) app, or whether you might want to charge for it some day. If you start creating it as a free app, it must forever remain so. What a horrible license. So, for most small-time operators with potential commercial aspirations, that puts Qt firmly out of reach (their developer's license is, or was, around $1000).
If you go with wxWindows, then by all means you _must_ get wxDesigner - a proprietary GUI builder. I think it's $50-$100 or so (it was $50 when I bought it). What a great program! Once you become fluent with the layout paradigm (which I found to be quite natural), you'll be very productive with it -- much more productive than with MFC.
Well, I could go on and on.
A couple of quick thoughts: As someone else pointed out -- you should probably check out wxPython, which makes the wxWindows API available to Python. You'd probably be alot more productive that way -- development with C++ can be very slow (especially on Linux!). If you go the wxPython route, you'll be able to reuse all your GUI design -- wxDesigner can produce both C++ and Python code.
In short, if you want to have fun, and explore the world of GUI programming, stay away from MFC. It has little to offer. If you want the best, and you're ready to GPL your software, go with Qt, which is the best GUI framework hands-down. If you want to keep your options open, especially in terms of which platforms you want to deliver on, then go with wxWindows (and look into wxPython).
Programmers are easily seduced into creating code to cover all the possibilities of the world. It's more comfortable because;
a) you avoid doing a lot of the design choices that are involved in actually finishing and shipping applications, and;
b) you feel like you're doing "good work" and reducing the risks by covering all the possible cases because you don't really know what the design needs
You're doing good work all the time, you can't possibly fail, right? Wrong! Many projects die well before finishing the library, the engine or the platform that was supposed to be the carrying structure of the application.
Letting technology desires drive development you can continue your good work for the rest of your natural life without ever having to face the fear of actually completing a project.
In the real world, porting software is actually often left for the interns and/or outsourced to other companies. Porting solid code after it's done is not the problem that kills projects. Most projects never live long enough.
Here is a radical idea: design and develop the application first, worry about porting it later. Write solid code for any platform of your choice, it will only take you a fraction of the time to re-do your UI for other platforms you plan to target. If you want to finish, force yourself to only write code that takes the application forward by concrete, measurable steps.
Work with a product designer who knows what they need to accomplish and how to get there.
Conquer your fear of making choices and finishing applications, only shipped products contribute to your track record of greatness.
Jouni Mannonen | Game Designer, Consultant
> VC++ and wxWindows both require lots of macros, however.
.NET), they're so similar in many respects (not by accident either) that learning one makes you comfortable in all the other ones. Leaning MFC OTOH prepares you for not much else. You might as well learn win32 API (well, you have to anyway), since at least you could then create your own framework.
Learning MFC is learning Microsoft Macro(TM). It's the most shallow and unambitious class framework I've ever seen, almost to the point of making you wonder why they even bothered with C++ (the templates I guess). Doing anything remotely interesting with the GUI requires falling back to messages and win32 calls. If you look at serious class frameworks (Borland's original OWL, then VCL, Java,
Make up your mind. If you want Windows only, do it in WTL. There is no part of WTL that is not better than MFC. Microsoft uses it internally.
.NET... C# & Windows Forms are a godsend compared to MFC's nonstop bullshit.
If you're used to MFC, then you should check out
If you're going to use wxWindows, keep in mind that it works very well with Python, so you may want to go that route rather than play the "VC++ does it this way and GCC does it this way and everyone's telling me to rtfm and I hate my life" game.
There are plenty of other people here who are qualified to tell you about tk or qt or mozilla or other cross platform toolkits.
For God's sake, don't do MFC. Not when there are SO many other options and each one brings more benefits to the table. Nothing you could have done, including raping prematurely born babies, could possibly deserve having to write an app in MFC. The world has come so far in the last 10+ years... Join us!
[o]_O
There is a lesser-known C++ GUI framework out there called the Windows Template Library that is based heavily on ATL. It is released on the Microsoft Platform SDK, but is officially unsupported. Search for it on google. It is what MFC should have been.
BTW- my 2 cents on the whole QT/wxWindows thing is don't bother unless you really need cross-platform. Knowing the Win32 API, which is very important when using MFC or WTL, is invaluable being that 95% of the machines on this planet run an operating system that uses Win32.
Of course, that requires moving to Object Pascal (for now). But if you're using the CLX, you're in for the easiest porting job of your life. It also requires shelling out some money for Delphi Professional on Windows, since the Personal Edition (free) doesn't support CLX development. But since you're considering the MFC anyway, I assume you're not afraid to pay for your tools.
Later this summer, Kylix 3 will support cross-platform C++ development via C++ Builder on Windows. But even learning Object Pascal is not that daunting--I've seen many C++ programmers become proficient in a matter of weeks.
Why limit yourself to two platforms? Write the back-end of your chess program so that it communicates with a front-end client by passing certain messages (perhaps in XML format). You might even make the message specifications public so that others could write clients for your chess engine.
The back-end only needs to concern itself with a virtualized game, not worrying about the details of how to go about putting a picture on the screen or interacting with the user.
This also allows the engine to apply 99.99% of its compute cycles toward planning its next move. It won't waste any time on mouse movement or other windowing events. Only when it receives a message will it be interrupted from "thinking."
By separating the core part from the presentation part, it allows you to use your chess engine with multiple front-ends. You might write one front end for Windows, one for Linux, one for Mac, and another with a web interface. The front end only has to know how to interact with the user and send and receive messages to the chess engine.
You could even expand the engine to handle multiple games at once. That extra feature should be easy to implement if the back-end and front-end are separated. It just means keeping track of more than one game and communicating with more than one client. You could be playing against it on your Windows box while someone else is playing over the web. Or perhaps you could set it up so that another human could play instead of the computer.
If you write your back-end using reasonable standards, then you should be able to easily port your chess engine to another system since you don't have to worry about different windowing systems.
Just a thought
Ouch! The truth hurts!
It is OTHER governments to which this comment applies. If you are an official of the French government, what must you think about the virtual certainty that the U.S. government is spying on the French government using unpatched security holes in Microsoft Internet Explorer or, possibly, back doors put into Windows on order of the U.S. government.
Would the U.S. government use any means to spy on other countries? Well, the U.S. has killed more than 3,000,000 people in the last 33 years partly by bombing 14 countries. Does anyone believe that people who think killing is acceptable suddenly become moral when they think about spying using computers?
For documentation of U.S. government activities from some of the world's most respected news agencies, see What Should be the Response to Violence?
I thought wzWindows also was more encompassing than QT.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
FLTK is portable between Linux (and other Unix/X systems) and Windows 95/NT/XP, and is also being used on handheld Linux systems, and there is a Mac port. The license is LGPL with an exception added so you can statically link a program with it and not release the source, and the license is the same on all platforms. It's my project, too, so I'm advertising it, I guess.
While it is true that you can get a version of Qt to play with without having to shell out any $$$, there is a catch. If you at any point in time touch your project with any one of their 'no-cost' versions (Non-commercial windows, Free Edition, Academic, etc. ) you can never at any later time buy a commercial Qt license and use your project commercially. As Trolltech says:
So... that first sentence especially might be something to consider. However, if you want to pay for developer seats up front (it's a per-developer licensing scheme, IIRC), there's not a problem. Or if you only ever want to do Open Source work while your're not getting paid to develop. Otherwise, check with a lawyer.