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?"

do it in .Net with GTK#

[tongue]

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.

Visual Studio...

[ConceptJunkie]

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!)

Absolutely, cross-platform is worth a lot.

[Futurepower(R)]

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.

Re:pragmatic answers

[Jerf]

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.

The second sentence is trivially true, but the first is probably false. There are any number of ways to approach the problem, but one first-cut possibility is an 8x8 grid of wxBitmapButtons. You can set all the bitmap states so it doesn't 'look' like a button (raised, etc), and then you need one bitmap per piece per color (plus probably a selection), which isn't that big a deal.

That's probably what I'd personally go with, just because the events are quite natuarally set up, and the bitmap generation isn't that big a deal. You could of course paint directly into the dialog (wxPaintDC), just like you'd end up doing in MFC.

Another interesting thing that you can do with wxWindows that is much harder to do with MFC is the possibility of using the various wrappers around it. wxPython is quite mature, and while I've never used it, I'd bet wxPerl is similarly mature. In this case, C++ probably is your best bet, because chess is one of those things that you need speed, thus you need C(++), and it probably isn't worthwhile to write the GUI in Python or Perl and then shell out to the chess program. But learning wxWindows leaves that as a future possibility.

And believe me, a nice windowing toolkit plus a nice language (Perl or Python depending on temprement... I recommend giving both a good shake before deciding) is a really nice tool to have around. I've knocked together programs in Python/Tk and Python/wxWindows in a couple hours that I'd never even think about doing in MFC/C++ or VB... that goes for (Python/Perl) * (wxWindows/Tk/QT/GTK bindings), not just the combos I've described here.

zerg

[Lord Omlette]

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.

If you're used to MFC, then you should check out .NET... C# & Windows Forms are a godsend compared to MFC's nonstop bullshit.

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!