Slashdot Mirror
Porting From MFC To GTK
crazney writes "Linux.com has an article up by Ryan Gorden of Loki on porting from Windows to Linux, in particular the troubles faced with Microsofts MFC API and the extensions implemented by Microsofts Visual C++ on the C++ language." Talks about porting, the gaming industry, and gives suggestions for portability from someone who should know.
Legality aside, don't forget your end users; not only are win32 wrappers considered to be "cheating" by the Linux community, no one wants to run a native Linux application that looks like a native Windows application. After all, if we wanted to use Windows programs, we'd just run Windows in the first place and save all this hassle. Your users demand more from you. Do not cheat them out of it.
OK - granted, it would be nice if the games had a distinctive Linux look and feel, but I really don't care about that as much as being able to play the bloody game on Linux. If this is the kind of esoteric touching up that makes it impossible to get a game ported to Linux then I am pissed!! Just put out the freaking game already and take the time to make others Linux-distinctive after you have built more of a market for games running on Linux.
Just my $0.02
Yes, thank God. Granted, as pointed out in the article, you're not legally allowed to compile it on non-windows platforms.
As someone who's done a fair amount of programming with MFC before, I don't really see how you could say that. Intended... maybe... but in practice it's not at all.
MFC even has a whole bunch of (very badly designed) STL-equivalent classes that are used very pervasively. This basically means that, if you're doing a decent Model-View-Controller style program you either:
I'm not really fond of MFC in general, either. It's a really poor object-oriented design. It has a horrid set of macros that tend to obfuscate things during debugging, and it really abuses templates (much worse than STL), too.
Since when is it being a Microsoft product an excuse for anything?
DNA just wants to be free...
But user interface stuff is exactly the problem. Yes, you *can* write a win32 app with Visual C++ without using the MFC, but it is akin to writing an X program with raw Xlib calls. And as regard to portability, I doubt most companies give a damn -- that's why there are companies like Loki which buy the rights to do the Linux ports -- the original companies aren't interested.
One of Java's biggest strengths is its cross platform GUI ability. No need to deal with MFC and GTK. Just deal with AWT (or if you are willing to ditch the mac, SWING)
When you combine java jar files with some simple VBS scripts or some bash shell scripts, you can even make installation pretty seamless nowdays.
I'm sorry, but this is nuts. MFC is the worst example of OO UI that I have ever seen.
If you really buy into Object Oriented dogma, and you want to make an OO UI, you have two places to look for real examples:
Unfortunately, I can't speak for QT; I've never used it. {:(}=
Now MFC..?! An object oriented system? It's the epitome of bad OO design. Good lord; when you use MFC, it generates these enormous files for you with macro blocks that say, "DO NOT TOUCH THESE!" around them. You can't add anything except through the grace of the UI builder. Is this "modular design"? This from people who mindlessly repeat the mantra "We must have type safety"?! It's nuts. Okay, now lets move beyond the macro blocks. When you are using MFC, it generates functions for you, and you are supposed to manually modify these functions. You can't register your functions; you have to manually go in and modify the code that it generates for you. And we are supposed to believe that this is "object oriented" design.
I'm not an OO bigot. But really; If you have determined to be an OO bigot, at leastbe a good OO bigot. Pull out your SmallTalk books, Simula, Design Patterns, Objective-C. Trace your roots. Read them. Read about NextStep. Study. Look at well documented, and well implemented, OO UI designs. Please. I'm begging you. As much as I despise OO facists, at least I want to talk with quality OO facists. Please don't align yourself with MFC.
(I generally hate writing flames, but some just have to be written...)
"The reason for this is to give a visual hint as to what is a comment and what is actual code. The rest of the syntax highlighting is less important in this case. While porting, never delete a line of code. Comment it out and make your changes below it. If you need to, comment out whole functions. You are going to find that having an immediate reference to the original code is immensely helpful, but all that text can get very confusing. Syntax highlighting makes everything much easier. "
/* */ blocks.
I couldn't disagree more. Large amounts of commented out code make programs unreadable. Why was it commented out? Was it test code? An older version? Something that wouldn't compile but needs to be fixed? Who knows...often not even the orignal commenter after a few months. Don't think that you will go back in fix it because you will not. There is almost never time to fix badly written code that seems to work because there is always new code to write. You will net get time to look at it again until a bug pops up. And then you will be left wondering what in the world was in that commented code. Writing things the correct way the first time makes life much easier.
Comments should be used for comments. Some text explaining code. They should be used for turning code on and off (use precompiler statments, much more flexible) and they should not be used to save old code. Try using a source repository that has version diff support like cvs. This is a much cleaner way to see what you had before without leaving your old code lying around in massive
As for comment syntax highlighting being the only usefull part of syntax highlighting, I have to disagree again. I like to see different parts of the lanugages syntax in different colors. Hence the name "syntax" highlighting, not comment highlighting.
-- soldack