Porting From MFC To GTK 210
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.
Hey, now - wait a second (Score:5)
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
Re:Why even Windows programmers dislike MFC. (Score:1)
Re:It isn't that bad... (MFC) (Score:1)
Re:Some g++ comments (Score:1)
STL is a nice design with it's orthogonal algorithms and data structures, but each time I've considered using it, I find myself wondering what functionality or ease of coding I'd actaully get out of it!
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:2)
I've always been wary of this, because I haven't found a definitive explanation of how the strings are interpreted before being compared. I'm guessing that the intent is to allow naïve to be considered "less" than naked, where it would normally be considered alphabetically "greater", but I don't know for sure. Other than that, I don't use any of your other pitfalls (apart from the occasional signal when I'm knocking up a quick and dirty prototype, but not in production code)
Re:The real Loki problem (Score:1)
Re:MFC is NOT Object Oriented, GTK isn't either (Score:3)
You don't need to generate code for an MFC app--it's just much easier if you do. Anyone can sit down and write an MFC app from scratch without the aid of a code generation tool if they so chose. Most would rather not.
"If your API needs exact the same code each time you want to make and MDI app then one should not make source code generator."
The thing is, if you're writing non-trivial apps, you don't need the exact same code every time. You need some minor specialization of the basic code. And this stuff gets tedious--very tedious--to write. Your idea of "new application.MDI()" is fine as far as it goes, but it doesn't go very far. What happens when you want a subclass of the default MDI? How would application.MDI() expose it's message handling architecture for the addition of new messages? How does one control the properties of the MDI window? There are lots of things that MFC can do that your application.MDI() approach couldn't. And that's where the complexity comes in.
Re:MFC is *bad* OO, GTK+ isn't even close. (Score:1)
GNOME code would be much cleaner in C++ because of the way it merges nicely with a "respond to event" environment like GNOME, or any other GUI for that matter.
I think I remember reading the reason why they balked at using C++ is that they were concerned about making it portable even to environments that didn't support C++.
Inti looks like an interesting framework, will let you guys know what I think when I've had a chance to play with it.
That'd be nice except for one thing... (Score:3)
The best policy for someone is NOT to use MFC- it's not the API for Windows, it's an app framework and a bad one for many applications at that.
Don't contradict yourself, it makes you look dumb. (Score:2)
No Linux programmer has even thought of creating a GUI network browser.
After several people pointed out that many graphical SMB clients do indeed exist, you then said:
yeah, but in the 0.0000000000001 pre-pre-pre-alpha stage.
So which is it? Or are you just spouting arguments in the hopes of seeming like you have a valid point?
And just in case people thought you might have a clue about how Unix works, you clear up that misconception with:
In my opinion, only daemons and tty clients should be in textmode.
So, let's get rid of the GNU tools, we don't need grep, tar, cat, man, and the like, because they're all confusing and should be replaced by graphical programs that can't be used in scripts or relied upon to exist on all platforms.
Sheesh.
Re:MFC is NOT Object Oriented, GTK isn't either (Score:3)
Methinks you are a hypocrite - you want it free to use in your non free work. In short, a parasite.
KDevelop, btw, has app templates for GNOME apps.
As for KDE's programmers attitudes towards GNOMES programmers, who stole whose HTML renderer without attributing copyright, hmm? Hint - look for KDE names in GTKHtml
Re:Good Object Oriented User Interface (Score:2)
In other words, their use of the langauge is not much better that MFC, though at least they don't supply their own compiler. I keep hoping someday they will give out long standing hacks like that and switch to using the langauge itself to do the same thing. Unfortunately, with Qt TrollTech seems to have gotten the mindset that only they can supply platform independent C++ libraries.
--Karl
Re:/* Commented out code? AHH! */ (Score:1)
Two words:
Version Control
Leaving commented out code in the current version of the source just makes it less readable for future maintainers.
Re:WINE's nice, but not the magic bullet people... (Score:3)
I agree that Wine is a bit "thicker" than other layers (mainly because the Win32 API encompasses a lot more than just widgets), but it's not like it's a whole layer thicker, so I don't think it's fair calling it "non-native".
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:1)
Worldviews come crashing down...
Re:MFC for what? (Score:1)
The problems with VC++ and MFC are a frequent subject of discussion on comp.lang.C++.moderated--if you're interested in this issue, drop by.
To summarize the consensus there:
the compiler is not standard-compliant and is not likely to become standard-compliant in the foreseeable future. Microsoft seems to regard large corporations as its primary customers and the various versions of Windows, IE, Outlook and Office as its primary products. Everything else is frosting. Unless someone in MS is willing to push the technology in a second-tier product, nothing happens.
MFC appears to be incompatible with the new standard, and as the MS programmers use MFC, there is no internal force driving standards compliance.
Yes, the STL is nicer, more elegant, easier to use, less buggy, etc... In fact, the availability of the STL is perhaps the major advance in programming during the last decade. But, there are a lot of second-rank programmers who specialize in Windows applications and who will never use the STL.
Please remember, MS is software for the rest of us. The bug rate (software faults per KSLOC) in MS software appears to be about 3 times the rate that the Government is willing to accept from anyone else. You get what you pay for.
Already being done- it's called WINE. (Score:2)
It might seem like a good idea on first blush, but there's so much that's different, so much that MS products let you get away with that's not a good idea that you're better off converting it and making the result work on both platforms.
Qt's not an option, unless you're GPLing something (Score:2)
Re:/* Commented out code? AHH! */ (Score:1)
And may I ask, what stops you from providing that information in the commented out code-block?
Original quote:
The rest of the syntax highlighting is less important in this case.
You said:
As for comment syntax highlighting being the only usefull part of syntax highlighting, I have to disagree again.
You need to brush up on your reading skills..
Re:WINE's nice, but not the magic bullet people... (Score:1)
--
Re:win32 (Score:2)
#include win16.h and
#include commdlg.h
What eles whould a compiler need to interface with a silly windowing system? A liscence?
No sir... (Score:4)
The Loki programmer clearly doesn't understand MFC. he also doesn't understand VC++'s extensions. That's ok, you can't know everything, but that's not a reason for ranting. It's a reason for investigation and to collect information about the topics he doesn't understand.
I've done some tools in MFC and all I can say is that using it is a breeze, but you have to study it to get to that point. That takes time and effort. The Loki programmer should take more time to clearly understand how the original sourcecode is using the MFC.
Another thing though... he's talking about the code to port to Linux. The code he's porting is from people who write tools that do what they want them to do AT THAT TIME, but not mainstream tools for every user on the planet: i.e.: the sourcecode can be cumbersome to understand. IMHO that's a much bigger reason why it's hard to port a tool from win32 to GTK+ than the MFC calls, which are clearly documented in the MSDN (which is shipped on 3 (not 2!) CD's, he must be using old MSDN's too). I mean... how hard can it be to read the clear MSDN explanation of an MFC method, understand what it does and to use an equivalent in GTK+....
--
before I quit programing WinDoze (Score:2)
Take the advice for what it's worth. I feel beter off learning about X.
Re:MFC is NOT Object Oriented, GTK isn't either (Score:1)
As for the, often repeated, lack of attribution - can you show some evidence of this? I looked in GNOME CVS and couldn't find any lack of attribution when kthmlw was imported into the tree ( http://cvs.gnome.org/bonsai/cvsview2.cgi?command=
Observations (Score:1)
And the suggestions to try the WxWindows libraries are great. Problem is, to be most effective, the original programmers would have to use them. But as Linux becomes mainstream, somewhere a PHB might just lose some pointiness and insist that the game utilities be easy to port to various OS, Linux included.
Re:Who uses MFC? And why did it win? (Score:1)
Re:Porting to Windows (Score:1)
there is no standard to deviate from. In a closed world where everything acts the same one program that looks and behaves differently becomes an obstacle to understanding (however small that obstacle is). Take a look at the new MS media player with it's horrible skins (poor design).
Re:No sir... (Score:1)
"If you don't understand the concepts or of you don't know how everything is build up, MFC looks like a mess and not workable"
Strange .. I've been doing MFC programming for several years now, and have reasonably in-depth and broad experience with it - and the more I get to know MFC, the more it looks like a mess to me.
MFC is a mess. It's a terrible design, it clearly was not thought out properly. I know one of the MS programmers who worked on the early versions of Visual C++, and he said basically the same thing - they were in such a rush just to get *something* out the door, they pushed out the first crap they could come up with - and they knew it was a mistake all along, but they had to get "version 1" out the door. After that, they were stuck with it.
"so no main function, nothing. everything is an object"
Dig into the MFC source code a bit, underneath the hundreds of layers and layers of MFC crap, you'll find the WinMain function.
"function oriented, non-C++."
It is just plain C++, including some MS-specific C++ extensions. Check out the source code.
"The MFC library is a true C++ OO wrapper around win32"
Actually it's more of an application framework than a set of wrapper classes. The MFC classes are horribly tangled together.
"I've done some tools in MFC and all I can say is that using it is a breeze, but you have to study it to get to that point"
Sure it's a breeze to write simple tools in MFC - but wait for the day where you have to do *anything* even vaguely unusual and "outside of the rigid framework". MFC can quickly become a development nightmare, and figuring out what the hell MFC is doing half the time is painful. Since you seem to contradict yourself ("it is a breeze" .. "takes time and effort") I assume you probably know what I am talking about, but haven't quite admitted it to yourself.
And BTW, I have done GTK programming too. It's a breeze compared to MFC - it's clearly a more well thought out, simpler, cleaner API. What I don't like about it is the hacky OO stuff implemented in C. I think they should have done C++ from the beginning. I remember chatting on irc once long ago, when gimp was still alpha, with some of the developers. They were clearly rabidly anti C++. Anyway, heading off topic here ..
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:5)
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?
Re:MFC for what? (Score:2)
Obviously you have no idea what you are talking about, MFC is a UI library while the STL is a collection of data structures, iterators and algorithms. They are practically unrelated.
PS: I saw this story earlier [gnome.org] at the GNOME site, check it out for more insight into porting issues by GNOME hackers.
Second Law of Blissful Ignorance
Re:A little more experts please (Score:1)
"GTK+ is C-function-oriented (like Windows API), and MFC is completely C++ OO"
Actually, GTK is object-oriented, theoretically speaking. They just "hacked" an implementation of OOP on top of C (I don't agree with their choice, I think they should've just used C++, but thats besides the point ...) But it's all there .. an inheritance structure, methods for "classes" (in this case structs.) Basically there isn't really a difference between:
struct Goo {};
void Func(Goo *pGoo);
and:
class Goo() { void Func(); };
Virtual functions are a bit different, yes, but they amount to not too much more than using good old C style callback functions, in a certain way.
My point is, you can implement OOP in C, and the GTK guys did just that. It's not very pretty though, you end up with lots of ugly typecast macros etc. But that was their choice, and they had their reasons, which may have been valid at the time they designed it (I had a 'discussion' once on the gimp dev newsgroups with the developers, I was arguing for C++ .. they somewhat rabidly disliked C++ .. anyways ..)
The main difference between the API's, from a design point of view, is that MFC is an application framework, and GTK is a set of objects of UI elements. Yes, MFC has some UI element wrappers, but in the overall design they don't stand on their own very well, and their interfaces aren't well genericized - everything is kind of tangled together in an MFC app. It's difficult to put across what I mean when I say that GTK UI objects are better "genericized" if you haven't programmed the stuff; but I can try elaborate with an example. In GTK, everything is a "widget", and a widget can be given certain base properties and inherit from others, and widget containers can contain any widget. So functionally, you can easily do things like add any sort of widget to a dockable "toolbar" (like the edit boxes and dropdown boxes you see in apps like MS Word or Visual Studio - those things are a pain to try to implement in MFC, since there CToolbar class is not a container, it's a specialized widget that just takes a bitmap and some resource ID's, and I might add can't handle more than 16 colours.) Now, you get this thing called a "dockable dialog" in MFC. Only it doesn't fit well at all into the MFC framework, because after you've plugged a dialog form into it, only the main view can handle ClassWizard messages from that dialog (unlike a regular MFC dialog which gets it's own class) - so nobody uses dockable dialogs, because they're so stuffed up. With GTK it's so much easier, because a widget container can handly any widget.
MFC has so many quirks and fuckups its just not true. Like for example, if your application has a modeless dialog with an edit, and it has the focus, but you happen to press keys for which their are key-shortcut "accelerators", those keys are swallowed. So you have to write extra workaround hacky things into the message pump to test if its a dialog message, and pass it on *to the current modeless dialog* (which you then have to keep track of) manually. How screwed up is that? GTK has no such problems.
What makes Gtk-- different to MFC is, as I said, MFC is an app framework. That means that when you typically create an MFC app you get a bunch of classes that perform typical roles in an application (typically, a "view" class, a "mainframe", an "app" class, and a "document" class.) These are based on the "document-view" architecture, which is something like the model-view stuff you learn in a CS course at Univ. The "mainframe" encapsulates a Windows window, with menus, toolbars, status bars etc - all the "typical MSWord-style application" elements. The "app" encapsulates the overall Windows application stuff, the "document" holds data your program uses (e.g. a spreadsheet) and the "view" provides the user with a visual representation of that data. In theory, this sounds nice and clean, but in practice in MFC it's awful. GTK is somewhat lower-level, and less spaghetti-like .. it provides a bunch of UI components, but nothing regarding tying the stuff together into an application. So the UI elements are more modular, more well-thought-out, more standalone, and generally cleaner and simpler than related MFC counterparts. And toolbars aren't limited to 16 colours .. powerful stuff, this is the 21st century after all (heavy sarcastic tone ..)
MFC tries (and in simpler types of apps, succeeds) in hiding the message pump stuff away from you. So for simple applications, it can make your life quite a bit easier. But nobody really uses MFC for complex apps, because it starts showing its limitations quickly. For big programs (like 3dsmax) companies generally end up writing all their own UI stuff, so they can do "fancy" things like 256-colour toolbars, and get around all the other annoyances and limitations of MFC.
How MS managed to screw MFC up so badly I don't know. I could go on for days about it. Maybe it wouldn't be so bad to program if the documentation was more accurate, I don't know, but if you're an MFC programmer, chances are that days and sometimes weeks of any project are given up trying to figure out either how to get MFC to do something that should actually be really simple if it wasn't so badly designed, or why something in MFC just plain isn't working like the docs say it should. I suspect the only reason they give the source code for MFC out, is that it would be impossible to get anywhere at all if you couldn't spend hours and days tracing into the MFC source code to figure out what the crap it is doing.
Re:No sir... (Score:1)
--
Marc A. Lepage (aka SEGV)
Re:Some g++ comments (Score:2)
You're right that it does specify performance characteristics, but they don't seem that desireable...I noticed that list::size() is listed as being O(N) rather than constant time! Would it really hurt the implementation to require a count++/-- when items are added or deleted? This may seem like a small gripe, but it makes the list class (one of the must useful basic types!) much less useful than it should be - I often use the equivalent size() function of my own list class assuming that it's essentially zero cost.
The other thing that hits me everytime I look at STL is the complexity vs the functionality provided... just take a look at the iterator invalidation semantics of basic_string! Am I meant to remember that stuff? It certainly seems to put an undue burdon on anyone having to maintain code.
If I thought that STL adoption was inevitable, then I might still grumble but start using it anyway, but considering how long it's been out and the current level of adoption, I think maybe that it has risen/sunk to it's own level, and will never be as ubiquitous as it could have been...
MFC is NOT Object Oriented, GTK isn't either (Score:3)
GTK isn't OO either - it's a C API.
MFC's strengths don't lie in its technical implementation, but the fact that there is a half-decent application generator that spits out this code. If you want an application with a window, view, document, serialisation support etc etc etc all you have to do is fire up VC++ and run AppWizard.
What Linux development sorely needs is some kind of framework (Inti's a nice start) plus a half decent open source appbuilder that wraps around gcc and gdb. Would you like a default MDI application in KDE? BAM there you go, and INSERT CODE HERE. Ditto GNOME.
Freeing up the developer from pointless busywork is the key. Right click on the class, type in the function signature, BAM, there's your code.
I can here the vi guys choking right now, and some EMACS type is going to chime up that you can actually do that with some custom LISP script, but if we're going to try to leverage MFC leveraging what it does well is important.
Performance Review (Score:3)
In recent work you've done for us, the quality has been slipping- oh, in spirit it's everything we could ask for, but if we may refresh your memory by this passage of 'Competitive Astroturfing':
Now, where do you get this 'kick in the teeth' language? Isn't that LITERALLY one of the examples you learned in training classes, almost a cliche? You know perfectly well that talk is for the management track, NOT undercover relations. So much of your post was in perfect form- the 'too busy hacking the Cue:Cat' (extra points for correctly spelling its name- elicits subconscious assumption of accuracy elsewhere), the '31337 H4X0R' (textbook assertion of the reality you're paid to present)... it's a shame you blew all this out of the water with your aggressive overtones. Please work harder at staying within the CA guidelines- it is important that this job be done RIGHT, as people are already beginning to not...Doh!
Re:MFC for what? (Score:5)
It isn't that bad... (MFC) (Score:2)
Overall, I thought it worked okay. But the MSDN doc is VERY VERY useful.
Peace out.
Re:No sir... (Score:2)
As other's have pointd out, MFC is a _horrible_ example of good OO design. Really, it is. I am an OO bigot. I don't write in C anymore because I find its lack of direct OO support constraining. I've written several different frameworks for things that I've used cross application and cross platform. MFC is one of the worst designed frameworks I have ever seen. Not only that, but half the people who code in it code like C++ is a particularily prickly and difficult to use form of VB. *shudder*
Also, those map editing tools and things often are designed to scratch an itch, not for mass consumption. Doom pioneered the idea that random people should have those tools, though some older games (like the ancient Wargame Construction Set) were designed with that idea in mind.
Re:MFC for what? (Score:2)
Re:MFC for what? (Score:2)
Re:Porting to Windows (Score:2)
That really depends on how you measure success. If it means a lot of people using and contributing to the software, then it's generally very successful. Iff it's under a free license, and you have sufficient people skills to manage a project. Otherwise it's like pissing in Niagra Falls.
I've noticed. It didn't used to be that way, though. I have the nagging feeling that Slashdot's done for the Free Software userbase what AOL has done for the Internet's userbase.
This sounds like a call for Java! (Score:5)
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.
how about a little abstraction.... (Score:2)
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:2)
Hrm, okay. I stand corrected on the MFC licensing issue, then. We're still at VC++5 at work for sundry reasons.
*Very* unimpressed by the article... (Score:2)
1) GCC 2.95.x... the only compiler that gets close to it in ISO compliance is the Borland 5.5 compiler. Getting confused over earlier errors... that happens... all the compilers have their areas that are bad. At least he could have complained about GCC being dog slow on C++ code.
2) MFC vs GTK... he's complaining that his joystick isn't a mouse. First... the frameworks are similar in their design at a basic level (they both let you write graphical applications with similar capabilities). His biggest complaint is that MFC is a message based framework and GTK is functional/callback based. Whatever... in the end both call functions based on "notifications"... they just have different ways of specifying it. If he can't comprehend that he has some other more serious issues.
But I would agree the porting is a bear but it ain't MFC's fault. And interstingly enough... I don't see where he says why he doesn't use GTK for Win32 if he finds MFC to be such a bare. I know why I wouldn't but you'd think that would be an obvious question.
Brian Macy
Re:This sounds like a call for Java! (Score:2)
This means I'd have to port the renderer to Java, as opposed to just throwing the classes into the new program. The difference is fairly significant.
I'm thinking a workaround would be to create a 'preview app' which could accept certain parameters over a socket, and the java program would communicate with the C++ program to get the realtime rendering done that way.
MFC *is* designed for Windows in the first place (Score:2)
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:3)
Then I guess gcc is broken also. People can't use compilers other than gcc to compile the linux kernel because the linux uses non standard extensions that gcc provides and other gcc quirks.
Re:Some g++ comments (Score:2)
I agree with you about C++. I think the problem isn't just programmers who don't fully understand some of the more complex features, but also incorrect and incomplete implementations of the lanuage.
Some perspective on MFC (Score:2)
Since then, Delphi and Visual BASIC and other GUI creation tools have become available. They're much, much nicer than dealing with MFC. That's what most Windows programmers use these days. It's silly to muck around with MFC when someone can bang-out a UI with C++ Builder in much less time. Very few people like MFC. It's still used at Microsoft for legacy reasons, and you'll find some die-hards who refuse to bow down to nicer tools, but for the most part GUIs and such are done with VB, Delphi, Builder, and so on. Heck, even Microsoft uses VB to write installers and such.
Complaints about MFC are valid, just as they were valid five years ago. This is nothing new, and nothing to get all worked up about. Heck, Xlib sucks too. We all know that.
Re:This sounds like a call for Java! (Score:2)
well well well (Score:2)
I have developed portable code in VC that compiles with GCC and such compilers (even Amiga ones like SAS/C) without any difficulty at all. Your claim VC makes code Windows only and Microsoft specific is garbage.
Congratulations, you beat up VC's defaults! It's can write code that compiles with GCC under notepad easier than I can under Visual Studio. By devault Visual C++ TM, Wizards TM you through creating a MFC piece of junk that might be able to run under WindBlows. If you spend a few hours working with it's poor interface you can make it work like a normal editor. I have used that piece of crap too.
My points were that MFC is not prortable and Visual studio is a pain to use.
Re:Hey, now - wait a second (Score:2)
I don't know why they didn't take a little more trouble with fonts but eye candy counts in computer games - look at Abrash's comments regarding lens flare in yesteday's article about the X-box. Gamers want stuff to look cool... and while Xterm fonts are not as jarring in a space sim as they might be in Mario Carts, they still look wrong in a game.
Windows, for all its faults, is the result of many years of focus groups and refinement. There is a lot to be learned from Windows. I don't believe that Linux developers should just wrap the Win32 API to port, but I don't believe in looking different just to look different than windows either. KDevelop is an example - it looks good, but so many little things are wrong that I can't use it. MS Dev Studio is GREAT. Trouble is, KDevelop only copies it some of the way. Multiple document windows are one big feature missing.
If you look at all the various systems around, like Windows, X, Mac, you see them all converging to a sort of standard. Even BeOS, starting from scratch, didn't come up with anything substantially different. Try and change it much (MacOS X dock, fr'example) and people complain. It may be that there is a Right Way to do a GUI and that all these systems are converging on it.
What is even more important is that the systems named, with the possible exception of vanilla X, all have common interfaces. This is why the split between KDE and Gnome is so tragic. To become adopted by large numbers of people systems need all their applications to work in the same way. It's OK allowing text editors like emacs to have their own command keys, because nobody is going to change a devoted emacs user, but at least applications should try to duplicate functions on familiar standards - like standardizing in crtl-X for cut and ctrl-V for paste. Right now some of my linux apps use crtl-X and some like alt-X and some like something else. This is bad.
Apple's holy User Interface Guidelines established a common interface standard that might not have been the best in every single situation but allowed people to learn how to efficiently drive one application, and therefore know all the rest too. Great stuff! Linux needs that. But how would this be done, since nobody controls Linux?
This, more than any other single thing, would remove a large barrier to adoption by cutting down on the retraining or loss of productivity experienced when leaving one familiar system for another.
(And if any demented freak should work out a way to wrap MFC and port that to Linux... well, I won't have to hunt them down, the market will ignore them.)
old experiences with MFC porting (Score:2)
My company was contracted out to port some Windoze based UPS monitoring and control software to various UNIXes. Won't tell you who, but their hardware and software both suck.
The project was planned at the outset to be cross platform, but they used MFC (mistake #1 of many). MFC is not much more than a wrapper around Win32. The greatest advantage you get is that they combine alot of calls. I don't have to call every kernel function, an MFC call will aggregate a few. So when commenting on MFC, comment on what it's designed for, aiding people using the Win32 API. It is not true OO, its a C++, class based abstraction layer on top of C and Win32 procedural calls and data types. Can debate whether it's a good abstraction layer (I personally think not) but at least critique it in the correct context.
Now, what we did is was rewrite non-GUI classes, and swap out the GUI classes with wxWindows, which seemed to be designed by someone very familiar with MFC, and had a lot of 1-1 mappings. Can't comment on wxWindows, I was using 1.4 which was bad (and yes I do realize it's open source, and I did contribute back) but haven't touched it since.
It wasn't hard, just time consuming. I'm thinking the game folks could do something similar for their old stuff (MFC lib on Freshmeat anyone?), and start Qt or V or whatever for their new stuff.
BTW: The only system clock we could find in Win32 for uptimes had something like a 14 day rollover. Hmm, even MS think s you need to reboot once a week.
Re:/* Commented out code? AHH! */ (Score:2)
Maybe "never comment out code" is a good rule of style for source once the original author lets it go, but it's just style. When doing a port or conversion, you'd be throwing away good information not to leave commented code.
--
Re:MFC is NOT Object Oriented, GTK isn't either (Score:2)
Re:This is why Linux needs a slap in the head. (Score:2)
Good lord I can't believe you have a +1 bonus. Someone should shoot the adminstrators for allowing this to happen.
First of all, there is no lack of graphical interfaces on Linux, there is a proliferation of them. Be more specific. There may be no good graphical interfaces(in your opinion), but that does not mean they don't exist. And there ARE nice graphical front-ends to smbclient. My favorite is LinNeighborhood [www.bnro.de], and an old stand-by is xSMBrowser [iastate.edu]. There. Not only have Linux programmers thougt of creating a GUI network browser, but they DID. Shut up please, I don't like your ignorance. And you want to push a Linux programmer into building a GUI into his work? Why the hell don't you pay him, smart-ass? Or, better yet, why don't you do it yourself you lazy bastard? Most of these programmers are doing it for FREE. You want something, you pay for it. I'm sorry, but I'm not going spend years of my life trying to please you because you TOLD me to(have you ever ASKED for a feature in a program, as opposed to demanding it?!?).
Contrary to what you may believe, Linux is for getting work done. That means that if your hard drive failed, and all but 8 Megs of memory has been destroyed, you still have a deadline. What are you going to do? Go out and buy a new computer, spend hours setting it up, etc., etc., or are you just going to pop in that rescue disk you made last week to finish off what you started? I'm sorry pal, Linux was not designed from the ground up to be what you want it to be. Go somewhere else.
[big sigh]
Ahhh... That felt gooood
Have a nice day
Dave
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
There's a challange... (Score:2)
Can we try porting my Ford F 150 engine to my Volkswagon Beetle next?
Re:This is why Linux needs a slap in the head. (Score:2)
That would make a Linux box completely useless remotely, or without an X server. The power of UNIX is in its command line. If you like a system whose functionality is inseparable from its GUI, Microsoft would love to sell you a copy of NT.
And there are lots of GUI frontends to SAMBA and the like. I don't feel like searching them out, you can do your own homework. But they're there.
--
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:3)
I am not joking. From the article:
Good Object Oriented User Interface (Score:5)
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...)
MFC Meaning... (Score:2)
Re:Some g++ comments (Score:2)
Are there any/many libraries that you're aware of that do operate on STL types?
Bah! (Score:3)
"...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."
Am I missing something here? My customers and I want an application to work. Period. I don't give a flying fig if it "looks" like a Windows application. The "look" isn't whay I run Linux at home. The "look" provided by either Gnome or KDE or whatever is NOT the reason I run Linux, that's for damn sure. The ability to have a decent GUI and at the same time run all kinds of other nifty programs at the same time is why I run Linux. I only WISH the latest Mozilla milestones "looked" like the old Navigator.
And the MSDN Library consists of 3 CDs, not 2. He'd know this if he actually followed his own advice and kept one handy and used it once in a while. This guy is full of crap, IMO.
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:2)
Perhaps you should read the quoted text and my reply. I was just pointing out the fact that gcc has proprietary extensions and that the linux kernel uses them. By the original poster's declaration, gcc is broken.
BTW, there are other free compilers out there, lcc is one.
Re:Some g++ comments (Score:2)
I don't know why you'd think my code has bugs or a hard to learn interface. I've been programming since probably before you were born, so I think I've got the hang of it by now!
Your other points are equally dubious...
Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's? Whichever you use? Them all? The fact is that aspects of the STL String class can be formally proved to be unimplementable without bugs, which is why the Rope class is preferred.
STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL.
AFAIK (certainly at companies I've worked at), STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either. Maybe I'm not the only one to find it of limited value...
Another approach... (Score:4)
I have seen this being done with a reasonably large project using the Qt 2.0 library. All development was done in Linux, and the project was later "ported" to Windows in the course of two days. Printing and some obscure font sizing problems required a bit of meddling, and several wrong assumptions and oversights were uncovered in the porting process, which turned out to be genuine errors in the original code. But all in all the project was easily converted from Linux to Windows with minimal effort.
The project (producing a 4 MB binary) is still being developed, in Linux, and regular compatibility testing is being done on the Windows platform mostly using vmware. All in all the money for the Windows Qt License and the vmware was well spent, as developing in the Linux environment still is much more comfortable, and debugging is easier, despite the shortcomings of the g++ compiler pointed out in the original article.
© Copyright 2000 Kristian Köhntopp
Re:Performance (Score:4)
Hey, there.
I saw your response to my article on Slashdot:
(http://slashdot.org/comments.pl?sid=00/10/01/1422 222&cid=16)
Just wanted to let you know what I think about performance:
1) GTK+ tends to use a lot more stack space for signal handling, mostly for making more function calls. You can get a good 13-20 stack frames deep in signal handling. This is, honestly, nothing, but it makes Windows a little faster in this case. This is partially due to the fact that GTK is a little more flexible, and partially due to the more-flexible design of X. To be fair, you probably aren't going to notice a difference even on a 386, unless you are passing a LOT of signals; and unless you are using some bogus message passing scheme to transfer a file via signals or some other insanity, it isn't going to matter.
2) Most of the programs that use MFC or GTK are NOT speed-dependent, at least not in their signal handling, so it's moot.
3) This leaves one area, and I cover it in the article; Bitmaps verses Pixmaps. Bitmaps are faster, but that's the tradeoff you get for being able to separate the X client from the X server. I tend to think that a bitmap will also be faster than a GdkImage (which is a wrapper over an XImage), especially over a network connection. If you were to do some serious animation in GDK using GdkImages, you'll probably find an equivalent program written to use Win32 bitmaps will be a little faster, but again, this is a contrived comparison, because for this, you'd really want to use DirectDraw and/or SDL or something else.
In short, if MFC is faster, it's not by much, and it's basically not a problem anyhow. :)
Hope that's helpful.
Re:Why even Windows programmers dislike MFC. (Score:2)
Re:What about wxWindows (Score:2)
Brian Macy
Re:Who uses MFC? And why did it win? (Score:2)
I have used both OWL and MFC, and in my opinion, OWL was better technology - it was entirely C++ and didn't rely on a "framework" consisting of classes, macros, and special "dependencies" that only the compiler knows about. OWL, on the other hand, used the C++ OO paradigm, and it was very easy for a C++ programmer new to windows programming to get a windows app developed in a short period of time. Unfortunately, though, OWL covered only the most basic of windows classes, so when Windows95 came out, it became pretty much obsolete. And then there was the AppWizard in MSVC++, which shortened application development times drastically for those familiar with MFC.
What really happened is that programmers gave up the ease of development with OWL for the features and shorter development times with MFC and MSVC++. MFC has a very complex and idiosyncratic interface - but, provided that the application programmer can handle the complexity, it is a much better RAD tool than OWL.
Unfortunately, the Linux community has been blind to all of this. What Linux needs is a standard graphical interface with a standard RAD tool. Face it - there are no GUI development tools that run in Linux that have even come close to offering the features that MSVC++ has - AppWizards, ClassBrowsers, integrated resource editors (AppStudio), syntax highlighting, and a standard application framework for rapid application development(MFC). Until the Linux community responds to the needs of the larger development community, it will ever be a niche OS.
Re:Fuck MFC. Fuck VC++. Fuck all proprietary langs (Score:3)
Where are my moderator points when I need them?
By that definition, most environments are broken. There are Win32 extensions to perl, so that's a broken development environment, to give a less exotic example than the kernel. Java has the microsoft packages.
There will always be local extensions to your development enviroments. The trick is to know when to use them and when not to use them.
Maybe of greater concern is that developers are not usually very careful to ensure portability. Do you use sysconf(3), [f]pathconf(3), et al. a lot in your code? No? Do you still use strcmp(3) instead of strcoll(3). Anybody still using signal over sigaction (shudder!)? How about alloca, mknod, or vfork from BSD or [dej]rand48, popen, or remque from SYSV? Even ioctl is not part of POSIX.1 -- ever used it? Then don't worry about the development environment: worry about your code first.
Re:Who uses MFC? And why did it win? (Score:2)
As for standard RAD tool, well, Borland Delphi for Linux will be available by the end of the year. Or, if you're not an Object Pascal fan (your loss), Borland C++ Builder for Linux will be out Q2 of 2001. And, of course, Borland JBuilder already runs on linux.
Re:MFC for what? (Score:2)
Re:/* Commented out code? AHH! */ (Score:2)
My feeling is that if you couldn't hand it in to your college professors in school, why should you do it in life? Just because you are not getting graded does not mean you should be lazy. Take the time to use a source repository and use check in comments. If you check in changes often with good comments, you can figure things out much easier then just leaving comments like
Yes, you are right aobut the syntax comment. I took it a bit farther than the author may have intended. But I really disagree with that even being the most important part. As I said, I like seeing all the different parts of the syntax colored differently. It makes the code easier to follow and look more structured. Comment highlighting is usefull but it is only a part of the whole.
Re:/* Commented out code? AHH! */ (Score:2)
If you really want to see both sets of code, try using something that could result in one set of super source that will compile anywhere. I work on software that builds unmodified on Linux, BSDi, FreeBSD, Solaris, Irix, AIX, and NT4/Win2k. There are various methods to handle bits of code that must be native. You could try general public view classes with native cat classes beneath. Or for a more c style solution try general api frontends to all native functions. The native functions are then implemented in special native only files. For example File.cpp is a general File API but FileWin32.cpp implents file handling for Windows while FilePosix.cpp implements File handling Unix style. Throw in configure script or make handling and your project will adjust to use the correct files for the correct platform.
By seperating the common from the native only code, you improve readability, establish a common API, and make future changes easier.
As I said, I wrote code like this everyday. It works with everything from back-end code to UI code. Trying to maintain commented out code in some sort of "port the original's changes" becomes very difficult. When the original changes you have to match his changes with your commented out changes and then rewrite again? ARG! I have seen places try to walk down that road too many times. It doesn't work well at all. Eventually, the constant porting effort becomes too expensive in money and/or time and it gets killed or key features get killed. One set of source that works everywhere automatically is the goal we should be going for, not a quick hack port.
What about wxWindows (Score:2)
Re:/* Commented out code? AHH! */ (Score:2)
I agree that in general writing things the correct way is not easy and nobody is perfect should expect perfection. The difference is that here you have a single decision where you know that one way you couldn't get away with on the job or in school. In this case you just know that by simply commenting out code you are taking the easy way out. What kind of grade/raise would you get for that? What would your coworkers think when they get a bug in this comment trail?
On your personal notes....
Actually, I gave free CS and math help in college and happily give directions when I know them. At work I write requirement and functional specifications and I write code. What is wrong with specifications? Should we just give up on documenting anything? I guess we could write even more unreadable, unmaintainable code and provide instant job security. Nah, I think I will stick to making my fellow programmers' lives easier so they will do the same for me.
Performance (Score:2)
You're going from very specific libraries for a particular OS to something a little more vague. Also, the widgets and window designs don't necessarily have a one-to-one ratio.
Re:Some g++ comments (Score:2)
Of course you can write your own version of the basic data structures and algorithms found in the STL! You could write your own GUI toolkit--but why would you want to, when their are dozens of quality, well-maintained efforts that do it for you?? You don't use the STL to get new functionality (necessarily)--you use it to achieve interoperability, modularity and reusability. If you're not using it, your code will be left behind.
Re:Visual C++ extensions to the language (Score:2)
Then of course there is the irritating "feature" where variables aren't scoped properly:
for (int i = 0; i < 4; i++)
{
}
// i should be out of scope, but this works in MSVC
i++;
Re: (Score:2)
wxWindows (Score:2)
Re:Some g++ comments (Score:2)
The STL specifies performance characteristics throughout. The STL can be implemented any way the developers' want, as long as it conforms to these performance metrics.
"Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's?"
I didn't make the original comment, so I can't speak for the poster, but I'd put my money on any one of the major STL implementations (rather than your homebrew classes) if I had to bet on quality of code. Nothing personal--I'm sure you're a very capable coder, but you still can't compete with a team of dedicated developers
"STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL."
But the STL is part of the standard. There are free, high-quality implementations available for nearly every platform that has a compiler. If a professional programmer doesn't understand the STL now, he/she better learn it soon, because it *is* the standard. Even Rogue Wave knows this--lately they've been marketing their libs as add-ons to the STL.
"STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either.
You were responding to me--so I'll reply here. Saying that STL adoption isn't widespread isn't an excuse for not using it. It's new. It isn't surprising that a lot of older code bases don't use it (yet). That doesn't matter--if new code is being written in C++ today, it should be using the STL. If you have specific interface conflicts that have to be resolved, that's one thing. If you are resistant to using it simply because no one else is--that's just dumb. Sooner or later, all those old libraries will be using the STL, and you'll have to change your code anyway--why not write to the STL today and save some trouble in the long run?
Re:This sounds like a call for Java! (Score:2)
JavaGL could do it. The tools exist in Java.
oh yeah, I forgot how easy it was! (Score:2)
I suppose you could say the same thing about Visual Basic. AAaaaH, HA-HA HA-HA HA-HA HA!
Brick wall it would be, and that's his point.
/* Commented out code? AHH! */ (Score:5)
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.
Re:Good Object Oriented User Interface (Score:2)
-Graham
Actually... (Score:2)
Incidentally, this will all be moot with the next Doom title as far as id engines go, as the rendering/level architecture will allow the editor to be built into the game executable.
Still, it'd be nice if GTK+, QT, or some other cross-platform widget lib gained acceptance among developers for home-grown utilities. Hell, it'd be even better if applications in general used cross-platform libs more often (how difficult are Win32-OSX ports now?), but that's probably years away at best.
Re:Who uses MFC again? (Score:2)
Also, MFC provides quite a good object-model that makes sense if you have experience with Win32. Most people complaining that MFC sucks don't know anything about Win32 and expect MFC to replace their knowledge. That's not true, it's just a framework for people that would rather write GUI apps with an OO approach (and IMHO, OO is extremely well-suited for GUIs.)
MFC does have some bad sides: lots of messy macros that are horrible when you're debugging and trying to understand what's happening and an Application Wizard that generates all kinds of garbage in the middle of your code like message maps. But you don't have to use the macros and it's even very simple to write an application without using the Wizard to generate the framework.
Re:Performance (Score:2)
MFC may be good for windows (Score:3)
Re:Scope (Score:2)
TWW
WINE's nice, but not the magic bullet people... (Score:2)
Which would I rather have? If I had a choice of no app or a WINE app? Dumb question. If I had the choice of a native Qt, Fltk, Wx, JX, GTK+, etc. app versus a WINE app? Dumb question, again- native is better than non-native.
MFC is *bad* OO, GTK+ isn't even close. (Score:2)
Right on, brother-man. =)
Too many people think that the well-defined use of data structures constitutes OO programming--GTK+ is a fine example of this, IMO.
Yes, GTK+ makes heavy use of structs and unions and function pointers to acheive a sort of object-oriented feel, but, in the end, it is still a collection of C functions that just happen to pass around lots of structs and unions and function pointers.
Writing true OO code requires a fundamental shift in the way one thinks about software. In OO, you can't fall back on functions and procedures--you have to figure out what object a given procedure should be attached to, or failing that, how you can implement the functionality as an object in itself. OO coding is a philosophy--so much so that I personally find it difficult to switch between C and C++ when I'm called upon to do so--even though the languages are syntactically very similar.
There's a lot to learn to write good OO code, which is why most programmers can't do it yet. And those who would say that GTK+ is OO programming fall into this category, IMNSHO.
However, MFC is OO--however badly designed it may be. Yes, MFC is littered with hacks and questionable design decisions (see Message Map discussions elsewhere), but the fact remains that you can create an MFC app without using a single C-style function You couldn't hope to do this in something like GTK+ (but maybe in GTK--).
Re:Hey, now - wait a second (Score:2)
MFC doesn't give speed. (Score:2)
odd little paper (Score:2)
Still enjoyable. I would have preferred something more along the lines of comparing media API's between the two platforms, and the workarounds the gaming community is implementing to get past platform differences.
I am often saddened that Andre LaMothe decided to "go windows" rather than move his gaming expertise into a more neutral OpenGL and Linux direction. I found his book exciting and style easy to read.
It would be so cool to see someone compare and contrast the methods in "Black Art of 3D Game Programming (LaMothe)", essentially a DOS book, into something modern and Linux-based.
Obviously, I'm fairly new at all this, because it looks like OpenGL makes a lot of the code in the "Black Art" book redundant. Nevertheless, it would be an interesting treatise on game programming to see all the 2D, 3D sound stuff in that book re-written for OGL/Linux.
gcc : Yes, we have problems, too...yet it does appear to be improving. Some of the templating and inlining seems really, really broken.
Re:Porting to Windows (Score:2)
It's still a little rough around the edges, but nice to program (a _lot_ nicer than MFC or the raw win32 API).
Re:MFC may be good for windows (Score:2)
Loki's SDL [libsdl.org] with Paragui [bms-austria.com] may be a good start, perhaps.