Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

wxWindows vs. MFC

Cliff posted more than 12 years ago | from the comparing-the-advantages-and-disadvantages dept.

Programming 103

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

cancel ×

103 comments

Sorry! There are no comments related to the filter you selected.

FREAK POST (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3889125)

freak my ass baby

Qt (1)

Geek Boy (15178) | more than 12 years ago | (#3889130)

Why not just use Qt? It's free, it works on all those platforms (well not OS/2 that I know of...). It's not free on Windows or MacOS however. I think Qt has a nicer API anyways.

Re:Qt (2)

jkujawa (56195) | more than 12 years ago | (#3889358)

Qt does require a strange precompiler. This is the biggest reason I avoid it. I'd rather my programs remain standard C++.

Re:Qt (2)

dimator (71399) | more than 12 years ago | (#3889435)

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.

Re:Qt (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3889382)

qt is ugly as shit.

Re:Qt (2, Insightful)

VZ (143926) | more than 12 years ago | (#3890887)

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

Re:Qt (2)

jmccay (70985) | more than 12 years ago | (#3895377)

I thought wzWindows also was more encompassing than QT.

Re:Qt (0)

Anonymous Coward | about 12 years ago | (#3935859)

> Try running your Qt program under Windows XP and compare it with a wxWindows one

Have you tried ? Yes, Qt emulates the look of the OS. But you know what ? It does that very well. You don't even noticed it is emulated. A Qt program under Windows XP looks just like any Windows XP Program.

> Why not rather ask "why use a proprietary and closed
I did not know the GPL was a close and proprietary license. Have you told RMS about this ?

> library instead of completely free, open and at least in some ways superior one"?

I haven't tried WxWindows myself. But what I have heard about it is that it uses events for the communication. The signal/slot mechanism of Qt and Gtk are far superior because they allow to carry more information in an easy to use fasion.

What is astonishing with Qt is how you can make two module (or classes or component) interact with each other without any of them depending on the other. It promotes code reuse to a new level. Many design patterns are simplified.

> at least in some ways superior one"?
In which way is WxWindows superior ? I was told the opposite.

> Qt apps will never use your current GTK+ theme, but wxGTK ones will.

Yes, but wxGtk won't use my KDE theme. This is a wider problem which you can not simply blame on Qt. Besides, KDE apps are able to use your Gtk theme.

So apart from your weak theme argument, I don't see much content in your post on why WxWindow is superior.

Re:Qt (0)

Anonymous Coward | more than 12 years ago | (#3891262)

Qt may be free, but it is not Free. And that is what caused your "well it's free, except on the platform you want to develop on" two sentences...

Mozilla (1)

JohnFluxx (413620) | more than 12 years ago | (#3903146)

What about using XUL mozilla stuff?

time (1)

xirus (584691) | more than 12 years ago | (#3889137)

I guesse it's up to you to see how much time you want to put into it...

fp (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3889174)

fo fucking happy ninjas and gayness.

CLITCLITCLITCLIT

you aer gay, hehehe

wxWindows definately (2, Informative)

jpt.d (444929) | more than 12 years ago | (#3889183)

wxWindows provides a nice api that renders using a native method (windows uses windows controls, unlike qt which draws its own).

MFC is not going to be supported by microsoft now because of .Net (which also means platform lockin).

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

Develop in Python, using wxWindows (5, Informative)

tdelaney (458893) | more than 12 years ago | (#3889206)

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:

Re:Develop in Python, using wxWindows (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3889366)

python is crappo.

Re:Develop in Python, using wxWindows (0)

Anonymous Coward | more than 12 years ago | (#3893846)

Python looks like a great language but...
1. It will not be quicker to learn Python than to use a language you already know for one project. If you plan on doing many projects then it might be a good solution.
2. There is something to be said for a nice exe file. Get this cool program but first load python and wxwindows for python.

Python and wxwindows seems like a great idea for internal programs. In fact I may start using it myself for internal company programs. If I want people to use my program and to download it from the net then I would write it in c++ and wxwindows.
To be honest I am a Big java fan. I wish that Microsoft would support the latest and greatest without having to download the Sun Jre.

Re:Develop in Python, using wxWindows (1)

LarryTheGeek (546580) | more than 12 years ago | (#3894002)

py2exe will compile a python app into an exe, including it's dependancies (like wxPython).

Re:Develop in Python, using wxWindows (1)

tdelaney (458893) | more than 12 years ago | (#3907433)

Actually, every programmer I know who has tried using Python has been productive within a week. I mean productive on real-world projects.

Mind you, the guys I work with are a pretty impressive bunch ...

Python is a very pragmatic language. Once you get the "oh - that's how it works" bit about names and binding, it's pretty much plain sailing (a few idioms to learn, but fewer than in most languages).

Re:Develop in Python, using wxWindows (0)

Anonymous Coward | about 12 years ago | (#3935869)

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.

I agree halfway with you.

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 Qt

Lots more information at:
PyQt [riverbankcomputing.co.uk]

A typical slashdot day by poopbot (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3889207)

Credits: anonymous

"Mmmm... this feels good..." I sighed.
"Shhh!" hissed Hemos. "We don't want Mark to come in here!"

True. Having Hemos's 16 year-old brother walk in on us at that moment would not be good. I didn't think he'd be too cool with finding his 12 year-old brother lying naked with me, holding my 11 year-old dick in his hands. But, in all fairness, my hands were eagerly playing with Hemos's dick and balls at that moment, too.

Hemos's mom and dad had gone to the drive-in, leaving his big brother in charge. In our favor, leaving Mark in charge pretty much guaranteed that we weren't to bother him, and in turn, he'd leave us alone unless we were making too much noise or breaking something. Well, we were being careful to keep quiet because we very much wanted to be left alone.

We were in Hemos's twin bed, snuggled under the covers with our underwear pushed down to the foot of the bed. The only illumination in the room came from the faint sliver of light that crept in under his bedroom door. Even in the shadows I could make out the shape of my friend; about my height, but heavier. (Hell, I was such a skinny runt that everyone was heavier than me.) Hemos had a crew-cut of white-blonde hair, and was only starting to sprout some pubic hair. But, you had to feel for it because what little pubic hair he possessed was as blonde as the short hair on his hea and could not yet be seen by even a minimal distance.

And, I was happily feeling for it, running my hands all over Hemos's slightly larger erection and fondling his larger testicles while he courteously stroked my dick. I could tell that he didn't possess the same enthusiasm for cockplay as I did, unless you count his appreciation for the attention devoted to his member. And I knew that my willingness to satisfy his sexual urges was one of the few reasons he even had me sleep over at his place. But, I didn't let that stop me from finding pleasure in the handling of his meat.

I'd recently had an "introduction", of sorts, to seeing what someone could do with a man's dick with their mouth. While spending the night with my Uncle Jerry a couple weeks before, while I watched in secret, I was treated to a visual display of the intensity and unabashed pleasure that my uncle had obviously enjoyed having another man suck on his cock. From that moment on, I had a yearning that I needed to satisfy. With who was my only question.

I guess it was time to find out.

"I... heard that sucking on it feels even better than playing with it." I ventured.

In the darkness, I could feel a slight jerk of revulsion in Hemos's body.

"Put a dick in your mouth?" he croaked.

"Well, " I countered, my heart pounding with anxiety, "I think adults do it all the time."

"Well, I'm not gonna do it!" Hemos hissed. "That's homo stuff!"

"Yeah." I sighed disappointedly, while still playing with Hemos's dick. "I guess it is."

As I stroked his shaft in a steadier, milking rhythm, I could sense Hemos's breaths getting quicker. His manipulations of my dick began to falter as I could feel his body tense beside me. His hips rocked slightly in time with my pumping of his cock, and I cradled his balls tenderly in my other hand. When any attentions to my own dick has completely ebbed, I knew what was about to happen, so I picked up the pace just a bit more while lending a touch more pressure in my grip. Finally, Hemos's breath caught in his throat, and he turned his face fully into his pillow to stifle the moans that broke free as his cock pulsed and throbbed in a dry orgasm within my hands. I continued to massage him and didn't release him from my grasp until his member had gone fully soft.

"Man," sighed Hemos dreamily after finally catching his breath. "You are so good at that, CmdrTaco."

At least I had something to be proud of, I guess, as my friend gently withdrew himself from me and rolled onto his back.

Even though I was only eleven, the irony of Hemos's words and actions were not lost on me. My sucking on him would have been a "homo" thing, but beating him off was okay. Go figure. Within the few moments I had spent mulling over the irony of the thoughts, Hemos had drifted off to sleep. I slipped out from under the covers and down to the cool floor so I could masturbate without shaking the bed. As I toyed with my own dick, I imagined Hemos's cock in my mouth, wondering if the chance would ever really come. Finally, my own climax washed over me, and I got back into the bed.

I don't sleep real well to begin with, and even worse when I'm not in my own bed. And now, with the thoughts of a dick so close to me, as well as the vivid memories of secretly seeing man-to-man cocksucking pleasure floating through my prepubescent, sex-filled brain, I was not about to fall asleep anytime soon. Lying awake until around 11:30, I finally decided that I needed to do something to satisfy my hungers, or I'd never be able to let it rest. The trick was in finding the guts to follow through.

I knew that whenever Hemos fell asleep, he pretty much stayed asleep. So, since he was sleeping soundly, lying on his back, I took a deep breath and gingerly ducked my head under the covers and scooted down as much as I could to the foot of the bed. That put my head right at Hemos's hip level. I raised my head and upper body to help create a tent over his crotch. Sniffing around, I found the faint scent of young penis flesh. I inhaled deeply, both in the love of the scent, and in an attempt to slow my pounding heart. I opened my mouth wide over the area where I sensed Hemos's dick to be, and lowered my mouth squarely over his soft cock and balls until I could feel his sparse pubic hairs tickling my cheek. I finally had a dick in my mouth! I just wasn't sure what I'd do if Hemos woke to find his "homo" friend in this situation.

I remained like that for a long moment, partially in fear of trying anything more, and partly to savor the moment. I carefully let my tongue start to explore his tender penile flesh, enjoying the texture. Then came the excitement that welled within me as his cock began to respond to my attentions and harden in my warm and wet mouth! Butterflies seemed to explode in my stomach and drown out my heartbeat as I felt his dick get to its full size in my mouth. Concentrating in that dark environment, I found myself beginning to identify the shape of his member by taste. The shaft actually seemed to taste different than the head, and the thin skin of his scrotum seemed to harbor another distinct flavor.

I started to softly suck on Hemos's dick, becoming fascinated at how it just seemed to, well, 'fit' in my mouth... how the head lent itself to the back of my tongue, and how the shaft rested between my tongue and the roof of my mouth. My excitement was so great that my own recently satisfied dick was responding again, inviting me to play. I was sucking a cock, and I was in heaven!

However, within seconds, Hemos seemed to get restless. In fear, I quickly pulled my mouth away from Hemos's candy stick and held still. The covers rustled, and pulled back.

"Whatcha doin'?" mumbled Hemos.

"I... uh... was trying to find my shorts down here," I lied, starting to fumble near our feet. Well, partial lie, because it was a good idea to do so, anyway, and now was as good a time as any.

"Oh, yeah," said Hemos. "Get mine, too, willya?"

"S-sure" I stammered, relieved.

I located the two items of clothing and scooted back up towards the head of the bed. Thankfully, our underwear were pretty easy to distinguish since Hemos wore boxers, and I wore briefs. We both fumbled to put them on in the dark, and then settled back into the bed. I lay stiffly on my back, still harboring some fear that my friend discovered more than he let on, but Hemos simply rolled onto his side, facing away from me, and promptly went back to sleep.

And, here I was again, so close to my fantasies, yet still so far.

And very much awake.

After hearing the clock in the hallway chime midnight, I finally got up to go to the bathroom. Figuring it was late enough not to be an issue, and since even if Hemos's parents were home that they would be in their own bedroom downstairs, I didn't bother to slip on my pants for the short trip down the hall. I walked softly to the bedroom door, and then stepped out into the hallway, illuminated dimly by a bare-bulb night light. I walked past big brother Mark's door to the bathroom at the end of the hall and turned on the light as I shut the door.

Peeing into the toilet, I looked up at my reflection in the large mirror and smiled slyly to myself. I actually sucked on a dick, even if for only a moment! At that moment I was Rob Maldo, secret agent double-O-seven, who could sneak in and suck a dick, and sneak away without being caught!

I flushed the toilet and switched out the light as I headed back down the hall. Slipping past Mark's door once again, the door flew open, and a hand covered my mouth while a muscular arm snapped around my waist and drew me into the room. Squirming in the arms of Hemos's athletic older brother was a waste of effort, and he only squeezed harder until I settled down.

"You'll keep quiet if you know what's good for you,' growled Mark into my ear. "You gonna be quiet?"

I nodded. Mark let go of my mouth and reached over to close his bedroom door, the other hand and arm still holding me firmly with my feet off the ground. I heard something click, and recalled, and not without a certain amount of childish fear, that Mark had a lock on his door.

The room had a yellowish glow from the large lava lamp next to Mark's bed. He took me over to the bed and tossed me face down onto it, kneeling next to me. I thought briefly about trying to get up and run, but to where?

When I felt Mark's hands on me again, I was determined to fight him off, but I was no match for him as he flipped me onto my back and straddled me, sitting squarely on my upper chest, his knees pinning my shoulders and my arms locked between his legs. I gazed up at his lean, muscled torso, his stern blue eyes under a tussled mane of reddish-blonde hair. I could feel the soft fabric of his boxers against my chin.

"Can't get up, can ya?" he said, grinning down at me, all snide and victorious.

I struggled a bit, more out of obligation, but knew it was no use. Mark was just too big for me.

"Whatsamatter?" huffed Mark. "You too weak to fight? Or, maybe you just like laying there, sniffing dicks?"

I started squirming a bit harder, but Mark's legs only clamped tighter. At least he had scooted down a bit, and was no longer suffocating me with his weight on my chest.

"Yeah! Maybe you're a homo-boy who just likes sniffing dicks. Maybe you wanna sniff my big dick?"

I didn't care for where this was going, and I wasn't too comfortable with the tone of Mark's voice. But, I was also not being given much of a choice in the matter. Especially when Mark reached into the fly of his boxers and pulled out his cock.

"Here you are, homo-boy... a nice, fresh big-man dick!" grinned Mark fiendishly. "Ain't it a beaut?"

He held it out for me, then leaned forward and started to rub his cock on my face, tracing my cheeks and nose with the bulbous head. His testicles soon followed his dick through the opening, until they were dangling on my chin, the coarse pubes tickling my lips. Their faint musky scent began to fill my nostrils.

"CmdrTaco's just a little dick-faced homo-boy, ain't he?" sneered Mark, sliding his cock across my face. "I saw you in there, your head under the covers. What were you doing? Giving my little brother a blow job?"

I didn't answer. I was at once shocked at the thought of having been discovered, and confused by Mark's remark. I then guessed that he meant sucking a dick was called a 'blow job'. But... you're not blowing, you're sucking, and-

"You were, weren't you, you little homo!"

It was obvious what had happened; that Mark had looked in on us to find my head under the blankets. I thought I had sensed a miniscule change in the light, but assumed that to be part of my excitement. That must have been what woke Hemos up so suddenly.

"So, maybe you aren't just dick-faced, " he said, rubbing his cock on my face again. "Maybe you're a dick sucker!" He leaned forward, mashing his hairy ball sack into my nose, then pulling back to trace my features again with his member. But, even as Mark taunted me, treating his cock as a threatening weapon, there was something else happening.

He was getting a boner.

And as I closed my eyes, I could feel his cock thickening against my face. I could sense the heat of his hardening dick directly on my flesh. And, I found I was enjoying the sensations of this older cock against my face. There would soon be no way of hiding the fact that I was getting excited, too.

"So, dick-sucker-CmdrTaco... you're gonna suck my dick, now."

My eyes sprung open to see Mark's fully erect cock pointing at my face. While it wasn't huge (I had already seen 'huge' with my Uncle Jerry), it was still big enough to scare me.

And excite me to no end.

"Open wide, homo-boy."

Without another moment of hesitation, or taking my eyes off of Mark's sleek tool, I opened my mouth as wide as I could and watched as he leaned down and slid that beautiful cock into my waiting mouth. I then settled my tongue against the bottom half of his shaft while I could feel the upper half press against the roof of my mouth. Its texture was soft, yet hard; smooth, yet distinct.

"There," he sighed. "Now, you have a real dick to suck on. Now, get started, suck-boy!"

It was so much bigger than Hemos's young dick, I wasn't sure if I could get enough suction worked up to suck on it. It was then that I found out what sucking a cock is really all about: friction.

Mark held the base of his dick to guide himself and started to pump into my mouth, sliding his dick in and out of my salivating lips. He would slip in precariously between my teeth until he was near to choke me, then pull back out until the base of the bulbous head was just close to popping free from my lips, held in place by the suction of my mouth. Then he... we... would do it all over again... over and over... and gloriously over again.

"Oh, you are good, CmdrTaco," he moaned softly. "You suck cock real good."

I don't know about that; it seemed he was doing all the real work. But, I wanted it to be good. I wanted to have this dick in my mouth. And I wanted it again and again. I was definitely enjoying the oral sensations as his near-adult dick worked back and forth in my hungry mouth, and I wanted so much to please him so he would want my mouth again.

Mark placed his other hand on the top of my head to steady me as his thrusts became a little more erratic. His breath quickened, and I could sense that he was trying hard not to ram himself all the way down my throat and choke me. He was making little grunts with each thrust, and I could feel his dick turn to stone in my mouth when, in a mix of fear and excitement, I suddenly recalled what would happen next.

"Oh, baby... oh, fuck..."

Mark's movements got all quick and jerky. I was almost afraid to breathe.

"OHHHH!!!" he moaned, pulling out of my mouth and letting loose with a burst of white goo that seemed to splatter all over as he pumped his dick with his fist. My head still held firmly in his other hand, the warm liquid flew partly into my still open mouth, and all over my nose and eyebrows. I swallowed briefly, not sure whether to gag or hope for more, tasting fully the salty and musky liquid, then opened my mouth once more as Mark stuck his creaming cock back in and worked the thick fluid throughout my young mouth.

I sucked until Mark went soft and withdrew his spent dick. He smiled down at me, obviously proud of what he had done. He finally got off of me (good thing since I thought my arms were going to fall off) and stood there for a moment, an interesting picture with his hands on his hips, and his drained cock and balls hanging out of the fly of his plaid boxers. I just lay there with his juices clinging to my skin, wanting to do it all over again.

Mark bent down and picked up a t-shirt, and proceeded to wipe the remainder of his goo off my face. Finished with that, he tossed the shirt into a hamper and walked over to his bedroom door to unlock it as he tucked his manhood back into his underwear.

"You better get back into Hemos's bed before mom and dad find you here," he said softly.

I reluctantly got off Mark's bed and walked to the door. As I was about to exit, he reached out to stop me briefly.

"You liked that, didn't you, homo-boy?"

I nodded, not sure where he was going with this inquiry.

"Your first taste of cum?"

I shrugged, then nodded again.

"If you're good, maybe I'll let you suck my dick again some time, CmdrTaco. Now, get your ass out of here before I kick it."

I stepped out of the room and felt the door close harshly behind me. I could still taste traces of Mark's cum in my mouth, could still sense the friction of his cock on my tongue. I smiled in remembrance.

I was hooked.

- posted by poopbot: providing truth in a deceitful world

aTeE6H5MGD

Re:A typical slashdot day by poopbot (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3889593)

you can describe the taste of cum? TMI, man.

Cross-platform is worth it. (2)

pmz (462998) | more than 12 years ago | (#3889249)

Look into Qt [trolltech.com] 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.

But development on wxWindows can die off... (2, Funny)

argel (83930) | more than 12 years ago | (#3889407)

... leaving you effectively in the same situation as having your vendor die off or stop supporting the product. The only difference is you could continue development on your own. But how many people are really going to do that?

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.

Absolutely, cross-platform is worth a lot. (3, Interesting)

Futurepower(R) (558542) | more than 12 years ago | (#3890091)


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:Absolutely, cross-platform is worth a lot. (0, Offtopic)

ClosedSource (238333) | more than 12 years ago | (#3892191)

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

Given the government's history of making poor decisions about software (ADA and JTRS come to mind), this sounds almost plausible. But I think they realize that the average government worker is not ready for Linux or BSD in its present form.

Re:Absolutely, cross-platform is worth a lot. (0)

Anonymous Coward | more than 12 years ago | (#3893887)

yeah just look at the thief in chief of the US. Is he going to say "ok let's give the market to our open source people because they know what they are doing" or is he going to say nothing and just let things roll? Maybe Nader should have been president. Then you would have seen open source used as much as it should.

Other governments (2)

Futurepower(R) (558542) | more than 12 years ago | (#3894544)


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 [pivx.com] 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? [hevanet.com]

Re:Absolutely, cross-platform is worth a lot. (0)

Anonymous Coward | more than 12 years ago | (#3906103)

It is safe to believe that ALL Gov't are trying to gain advantage through both physical and software means. Electronic interception is now a "given". Deal with it! Accept it. Of course, unique languages will slow them down, but not stop them. They're gaining access through chips, the net, and the air. Hey, life goes on!

FOX (1)

SnapShot (171582) | more than 12 years ago | (#3894082)

I'd like to do a quick shout-out to FOX [fox-toolkit.org] .

Like wxWindows it is cross platform and open. Unlike wxWindows the GUI is part of the library and not a wrapper around the OS user interface. This may be an advantage or a disadvantage. Anyway, FOX is another mature alternative and I like it.

Write it in MFC, then port to wxWindows (3, Informative)

LoveMe2Times (416048) | more than 12 years ago | (#3889349)

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.

pragmatic answers (5, Insightful)

Pauly (382) | more than 12 years ago | (#3889356)

Do the benefits of supposed cross-platformness outweigh the drawbacks of having to learn a new system...

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.

...and not having all the (incredibly wonderful) automatic code generation features Visual C++ provides for MFC programs?

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.

Or would it perhaps be better to write it in MFC since I am reasonably familiar with it then port it to wxWindows?
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 [trolltech.com] .

Re:pragmatic answers (3, Interesting)

Jerf (17166) | more than 12 years ago | (#3890463)

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.

Re:pragmatic answers (1)

LoveMe2Times (416048) | more than 12 years ago | (#3890600)

I think that this is a troll, although I can't tell for sure. Seems a little misinformed, at least.

wxWindows is no silver bullet, but it is very functional. All of my experience has been, "it just works." The main extra work for me in getting code to be cross platform when working with wxWindows is the different build environments. If you're a VC++ developer, then the whole Makefile thing can be confusing for a while.

You go on to rip on the autogenerated code, which suggests to me that you were having some trouble grasping the MFC framework. It takes a little getting used to if you've never done event based programming before, but apparently this guy has done MFC before, so this shouldn't be a hurdle. The stuff that AppWizard and ClassWizard generate are there for a reason, and very rarely do you have mess with any of it. On the occasions that you do have this need, then yes, you need to read the comments, and should probably get a book. MFC has its shortcomings, sure, but usually people struggle more because they don't understand the windows API programming going on in the background. If you want to do fancy stuff, then you have to know what events to handle, what the creation sequences are, and occasionally there are subtle interactions between MFC and the API. But this guy just wants to write YACP (Yet Another Chess Program), so I doubt he's going to do anything fancy. So VC++ will save him a bunch of time and not cause much in the way of headaches.

You sum up by suggesting that porting from MFC to wxWindows would be the most work and that QT would be the "least pain." I must humbly disagree. If he already knows MFC, then porting to wxWindows is quite trivial. I have not used QT, so it may also be easy, but QT has licensing issues if you want to distribute a commercial application, whereas wxWindows does not. I realize that he just wants to do YACP, not likely a commercial endeavor, but wxWindows seems like the better skill investment to me. And since you greatly misrepresent the case for wxWindows at least, so I'm dubious of your claim that QT is better.

Re:pragmatic answers (2, Insightful)

Pauly (382) | more than 12 years ago | (#3890919)

I think that this is a troll, although I can't tell for sure. Seems a little misinformed, at least.

I will admit it's been a while since I've used MFC. However, my experience predates Windows by a fair amount, so my appraisal of MFC isn't based so much on an ignorance of the windows API but on knowledge of many GUI api's in general. Having used Iris, OpenStep and others before Win32, I can look at the MFC code generated by the wizards (and by myself) and conclude it's garbage. I've created comparable apps, in other frameworks, and MFC has for me always been the most painful to use. Borland OWL comes in a close second. Motif gets third.

If you want to do fancy stuff, then you have to know what events to handle, what the creation sequences are, and occasionally there are subtle interactions between MFC and the API.

The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks. I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about. I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.

If he already knows MFC, then porting to wxWindows is quite trivial.

Finally, porting fromanything to anything is by definition more work that simply writing that one thing once. If you mean for your code to run on multiple platforms, start from scratch coding using tools intended to work on multiple platforms. If you want to write windows apps, use .NET, cuz' MFC is dead don't ya' know.

I have not used QT, so it may also be easy, but QT has licensing issues if you want to distribute a commercial application, whereas wxWindows does not.

This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.

Re:pragmatic answers (1)

LoveMe2Times (416048) | more than 12 years ago | (#3895950)

First, thanks for replying. Seems like we'll probably agree to disagree, though :)

The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks.

Mostly, the subtleties I have worked hard to learn are subtleties of GUI programming in a WIMP environment. There's pretty much no way around knowing what events are generated for various things and what data comes along for the ride. Whatever your environment is, you will occasionally need to know what the construction order is of your windows and other frustrating items. And I won't believe for a minute that there exists a toolkit worth using without subtleties.

I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about.

I find that newbs tend to get confused/frustrated because it's so easy to get started with appwizard that they get misled into thinking that you don't have to know anything to make it work. A lot of them, being fresh out of school, have never done event driven programming, and are just overwhelmed by the whole model ("where's the f*#@ing main() function?!?"). These people should do some windows programming straight to the API before trying MFC or some other toolkit, because they will find any machinery peculiar and has to be read about.

I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.

Let me clarify that I do not like MFC. It has the same problem as pretty much every toolkit that I've worked with: it bundles a GUI toolkit with an application framework with a bunch of utility classes. The GUI toolkit is pretty reasonable given the windows API it has to work with. The app framwork kinda sucks, and I don't like the utility classes much. Now, while people like boost.org [boost.org] are working on utility classes that will rock, they're not ready yet, and nobody that I know of really cares much about app frameworks.

Finally, porting fromanything to anything is by definition more work that simply writing that one thing once.

On the surface, this seems like a truism. However, lets say that you have a tool that will save 10% of your development time if you use A instead of B, and that you already know A but not B, and you can port from A to B without really having to know a lot about B, and so you can port in about 1% of the development time. In other words, I think that given this guy's situation, it is very reasonable to expect that appwizard and classwizard will save him more time than he spends porting to wxWindows.

This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.

Consider the possibility that he's using this as a learning experience for a future commercial project. Not necessarily a deciding factor, but you do want to keep in mind how your skillsets will help you in the future :)

Re:pragmatic answers (2)

Pauly (382) | more than 12 years ago | (#3896696)

I just read this and nodded my head a lot. Your point about frameworks is excellent -- it brought up memories of A.C.E. and made me shudder. MFC might be no worse than the other do-too-much-frameworks. FLTK [fltk.org] anyone?

Re:pragmatic answers (0)

Anonymous Coward | more than 12 years ago | (#3909061)

__int64, __int32, __int16, and __int8 are only provided if you need to have a certian number of bits in your integer, and MS recommends that you not use them, or if you do use them, only in typedefed code. It's no worse than gcc using long long for a 64-bit integer, and I would argue better, as it explicitly guarantees integer size.

No comment on MFC. Except to say the auto-generated code is ugly, and the MFC design is ugly. And I don't like the way it tries to play tricks behind your back. I code with the C API so I know what is happening.

Cocoa (1)

norwoodites (226775) | more than 12 years ago | (#3889418)

Get a Mac and try using Objective-C with PBX and IB. woops, Chess is already done and been opensourced because it depends on GNU Chess. Which is the best chess program out there. It even beats the world leader in chess.

You might want to try to port it to GNUStep.
Here is the link to it http://developer.apple.com/darwin/projects/misc/

Re:Cocoa (2)

Gogo Dodo (129808) | more than 12 years ago | (#3890763)

Which is the best chess program out there. It even beats the world leader in chess.

Uhhh... no. See the SSDF Rating List [telia.com] .

Have you thought about CLX? (2, Informative)

xagon7 (530399) | more than 12 years ago | (#3889445)

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.

Re:Have you thought about CLX? (1)

Mr D. Logan (521004) | more than 12 years ago | (#3890723)

As I understood it, a later version or Kylix (one this fall, maybe?) is supposed to support coding in C++. Also, the CLX is sort of based on Qt -- from what I am seeing at the moment, it looks like the CLX is made up of Pascal bindings around Qt.

Re:Have you thought about CLX? (0)

xagon7 (530399) | more than 12 years ago | (#3891420)

Yes, I think you are correct on all accounts.

Re:Have you thought about CLX? (2)

uradu (10768) | more than 12 years ago | (#3891671)

> As I understood it, a later version or Kylix (one this fall, maybe?) is
> supposed to support coding in C++.

Yes, Kylix 3, which is expected sometime this summer supposedly. And the CLX is indeed based on Qt, so on Windows you'd essentially end up with a run-time DLL a la MFC42.DLL for Qt. Not a major thing really, but as an alternative you could stick to plain VCL on Windows and try to isolate (and keep to a minimum) any necessary win32 code such that you could rewrite that code in Kylix using available Linux libraries. VCL code tends to port over to CLX code pretty easily (often verbatim if I remember correctly, at least for many GUI elements), so on Windows you can still have Qt-free code and still have a pretty portable project. This tends to be harder for database apps, since I believe the CLX introduces a new db abstraction model, but for GUI and networking code (use Indy) it's pretty straight forward.

Porting to/from MFC (1)

nvrrobx (71970) | more than 12 years ago | (#3889497)

Porting to/from MFC is a total pain - I don't reccommend it.

wxWindows is a great product. One of it's best features, IMHO, are all the language bindings. It's very easy to prototype your app in wxPython, then convert to a C/C++ app later.

Plus, if you ever want to run your app on anything other than Windows, MFC is defintely not the right choice.

Re:Porting to/from MFC (1)

LoveMe2Times (416048) | more than 12 years ago | (#3890348)

Sounds to me like you haven't done much porting between MFC and wxWindows. I've never had an easier porting experience. wxWindows was intentially built to work like MFC to make it easy to port, and they most certainly succeeded, with the notable exception of OLE support. I ported a several man month project in a day or two, and none of it was hard or confusing, it just amounted to looking up the equivalent functions in the help. I could do the conversion much faster now because I wouldn't have to keep glancing at the web page.

do it in .Net with GTK# (3, Interesting)

tongue (30814) | more than 12 years ago | (#3889531)

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.

Re:do it in .Net with GTK# (0)

Anonymous Coward | more than 12 years ago | (#3921267)

Yes, when this # thingy close to usable at the end in 5 year, this Miguel thingy will start another project to replace this # thingy. We all know Miguel does this frog leap thinking thingy. Never trust him.

Why are you writing a Chess program? (1)

argel (83930) | more than 12 years ago | (#3889557)

Do you want to make it cross-platform for philosophical reasons? Do you wan to do it for the challenge (maybe Tk would be a better choice MUHHAHAH)? Do you want to sell it as shareware (MFC, duh)?. Are you writing it to learn more about computer Chess AI (MC since you know it)? Or are you writing it to learn more about manipulating on-screen graphics and learn GUI design? Then you should go with Qt, wxWindows, MFC, Tk, etc. And then write a book about your experience. Mind you, the technical aspects, not the nervous breakdown! :-)

Clarifications on VC++, Qt (2)

hawkstone (233083) | more than 12 years ago | (#3889638)

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 [trolltech.com] . 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 [trolltech.com] with some nice code generation features, and excellent documentation [trolltech.com] .

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.

Re:Clarifications on VC++, Qt (2)

cmowire (254489) | more than 12 years ago | (#3889970)

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.

MFC and language extensions (2)

Anonymous Brave Guy (457657) | more than 12 years ago | (#3890294)

VC++ does not require language extensions.

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.

Re:MFC and language extensions (1)

hawkstone (233083) | more than 12 years ago | (#3890397)

VC++ does not require language extensions.
No, but MFC does.

Thank you, yes, I misspoke. I meant to say MFC.

Slightly tangential, but the biggest offender IMO of MS non-standards compliance is their use of the old for-scoping rules that have been "wrong" since at least the '96 C++ draft standard IIRC. You have two options to fix it -- force full ANSI compliance which will prevent almost any windows app from compiling, or use (get this -- this is their idea, not mine):
#define for if (true) for
This is true for all Visual Studio compilers, including the latest and greatest .NET, or so sayeth the MSDN Knowledge Base.

Re:MFC and language extensions (2)

Anonymous Brave Guy (457657) | more than 12 years ago | (#3890598)

You have two options to fix it -- force full ANSI compliance which will prevent almost any windows app from compiling, or use (get this -- this is their idea, not mine):

#define for if (true) for

Full ANSI compliance will cause almost any Microsoft-based Windows app not to compile. Almost everyone else manages quite happily, though Borland's C++ Builder does make extensive use of a few proprietary extensions as well. :-(

The for-loop hack has been around for quite a while, of course (sorry, just realised how that reads...) but while that problem is the biggest one, it's not the only offender (or at least, it never used to be).

Re:MFC and language extensions (3, Informative)

Chris Hall (5155) | more than 12 years ago | (#3892230)

#define for if (true) for

This is a very dangerous definition, as it invites a following else to be misunderstood. For example, it breaks the following:

if(foo) for(int i=0;i<42;++i){...}
else cout<<"Oops!\n";

A better fix is therefore

#define for if(0);else for

(Or use false instead of 0 if you prefer, but there are probably still compilers out there that don't understand bools.)

Re:Clarifications on VC++, Qt (3, Insightful)

uradu (10768) | more than 12 years ago | (#3891706)

> VC++ and wxWindows both require lots of macros, however.

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, .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.

Qt does have major "costs" (2)

mughi (32874) | more than 12 years ago | (#3904460)

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

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 [trolltech.com] , Free Edition [trolltech.com] , Academic [trolltech.com] , etc. ) you can never at any later time [trolltech.com] buy a commercial Qt license and use your project commercially. As Trolltech says:

A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense.

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.

Visual Studio... (3, Interesting)

ConceptJunkie (24823) | more than 12 years ago | (#3889899)

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

Re:Visual Studio... (2)

uradu (10768) | more than 12 years ago | (#3891752)

> 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

Yeah, automatic code generation is great if you know exactly what you want from the beginning. It'll spit out megabytes of code for you, which even compiles. But start fleshing out this code a bit, and then change your mind about GUI layout or program structure, and you're in one-way-wizard hell. Basically, duplicating the type of code the wizards generate by hand is a massive amount of very tedious work. Rather than delegating (and hiding) tedious setup code to base classes that your code inherits from, the MFC instead relies on wizards to take the tedium away. According to Microsoft, Inheritance + Polymorphism = Wizards (essentially).

Re:Visual Studio... (2)

ConceptJunkie (24823) | more than 12 years ago | (#3896471)

For about the 1000th time I wish I could mod up a response to one of my comments.

Automatic code generation just replaces one set of tedium with another... the difference being is once you learn to do it the proper way, it's a lot easier and faster, but if you rely on Microsoft's crappy pseudo-CASE tool, nothing ever gets easier or faster... and in fact, when you want to modify the generated code, you just opened up a big can of trouble.

Re:Visual Studio... (2)

uradu (10768) | more than 12 years ago | (#3897517)

There's one type of code generation that I appreciate, and that's auto-generated event handlers (such as when double-clicking on a button on a form in design mode). But even there I prefer Borland's way of doing things: smart enough to keep element and event handler names synchronized, and to know that when an event handler isn't used anymore to delete it at compile time. VS.NET seems to have better two-way synchronization, but I haven't used it that much yet.

Java (2)

isorox (205688) | more than 12 years ago | (#3890325)

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?

Re:Java (0)

Anonymous Coward | more than 12 years ago | (#3890515)

Your job.

Re:Java (1)

makapuf (412290) | more than 12 years ago | (#3892499)

your soul

Re:Java (1)

damiam (409504) | more than 12 years ago | (#3893474)

About 90% of your CPU cycles.

Re:Java (1)

isorox (205688) | more than 12 years ago | (#3894150)

get a decent computer then

Re:Java (1)

damiam (409504) | more than 12 years ago | (#3895051)

You can't reasonably expect all your users to get quad Athlons with gigs of RAM, just to run your simple program.

Re:Java (1)

xutopia (469129) | more than 12 years ago | (#3893816)

three people answered obnoxiously.

Re:Java (2)

joshuac (53492) | more than 12 years ago | (#3904090)

---snip
What will you lose?
---snip

the chess match, unless there are no time limits :)

Re:Java (1)

THEbwana (42694) | more than 12 years ago | (#3907144)

I like Java as a serverside language but as soon as you need to build a gui its useless. Its just too slow - the user experience is similar to a long and painful visit to the dentist. What I would like would be to be able to use Qt or Wxwin with java. Anything like that out there? - I dont like SWT - it may be fast but I dont like the motif downsides when running on linux (irritating to have to use imwheel for mouse wheel support + the poor documentation of SWT).
- Any suggestions for a way to build a decent GUI with java but without awt/swing?
PS. If you're thinking of responding to this with one of those "use c - java is crap" responses, dont bother. Just accept that Java is big in some sectors - especially the finance industry. Continuous derading of Java actually hurts the free os'es (as in beer/speech) since this - the support for Java - many times is the main requirement for companies in the finance industry. I've seen FreeBSD/OpenBSD/NetBSD fall on this hurdle so many times - please dont kill Linux this way. Just accept that usefulness of Java varies depending on the specific needs for that user. /m

Re:Java (2)

isorox (205688) | more than 12 years ago | (#3908441)

quick google search:
Java-GTK [informatik.uos.de]
QTJava [sourceforge.net]

Re:Java (0)

Anonymous Coward | more than 12 years ago | (#3908328)

Your mind?!

(working on a cross platform project utilizing java/awt/swing/xml right now)

Porting from MFC (2)

Anonymous Brave Guy (457657) | more than 12 years ago | (#3890417)

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.

Cross Platform GUI - Tk (1)

midh (33638) | more than 12 years ago | (#3890635)

A year ago, we were writing a Checkers program for a Software Engineering class and we considered several toolkits before choosing TkInter + Python. Our requirement stated that we use ncurses + C or Python + *. wxWindows was not really stable then. But it is a lot nicer than Tk.

Although our requirement was that we only need to get it working on Linux/KDE we were actually running this program on Solaris, Linux and Windows. We did not have to do any additional work (Except for the path seperator) because Python + TkInter ran on all these platforms. It is nice to see that.

"Write once - Run Anywhere*"
*Anywhere A, B, C and D work

On the other hand if I had to distribute this same program to Windows users, I would have to ask them to download and install Python. You
want to download something named after a snake?

I do have to ask why one needs a new Chess program when there are multitudes already out there. I do not know of any cross platform ones. So it might be a good thing to make that a requirement - just to differentiate.

Re:Cross Platform GUI - Tk (1)

dilbert (7000) | more than 12 years ago | (#3891549)

On the other hand if I had to distribute this same program to Windows users, I would have to ask them to download and install Python. You want to download something named after a snake?

Not true. The py2exe tool lets you make a bundle of files that include the Python runtime and any extension modules required by your app, and it works very well with wxPython. Your users never need know that they are using Python.

From what I can tell, I'd say go with wxWindows (3, Informative)

Chuck Messenger (320443) | more than 12 years ago | (#3891104)

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

The only solution (0)

Anonymous Coward | more than 12 years ago | (#3891143)

Is to develop your program using C# and the Microsoft .NET framework, using Visual Studio .NET. As soon as computers have proper Digital Rights Management (DRM) systems installed at the hardware level it will not be possible to run anything else anyhow, so you want to make sure your software is "future-proof".

The paralyzing FEAR of wrong choices (2, Insightful)

Jouni (178730) | more than 12 years ago | (#3891230)

Ever notice how programmers write UI libraries, system libraries and libraries to network with the coffee machine for "portability purposes" before getting their hands dirty with the real job at hand? How they avoid writing application code to the last moment, rather writing libraries to make it "possible" to write the application in "zero time"?

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.

Re:The paralyzing FEAR of wrong choices (1)

Chuck Messenger (320443) | more than 12 years ago | (#3906286)

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.
It's important to make wise choices about development platforms, because it takes a significant amount of time to master a development platform. For example, little that you learn in mastering MFC will carry over to a different GUI system (say, Qt, Java, etc.). So, it's wise to think strategically up front. A single person developing alone has only so much bandwidth -- you don't want to squander it uselessly. Once you've mastered your development platform, you can pour your efforts into your unique creation, and be highly effective. But mastering the platform can be very time consuming, and frustrating.

So, think alot about your development platform, and think strategically.

Just a thought (0)

Anonymous Coward | more than 12 years ago | (#3891639)

Do it in Java.

swing? (0)

Anonymous Coward | more than 12 years ago | (#3891717)

Have you considered writing the chess program in Java and use Swing for the widgets?

Seriously, there is nothing like writing an app on Redhat and then running it on os/2 without recompiling.

Or maybe that's just me....

http://www.python.org (0)

Anonymous Coward | more than 12 years ago | (#3891778)

'nuff said

zerg (3, Interesting)

Lord Omlette (124579) | more than 12 years ago | (#3891793)

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!

use ATL/WTL (2)

mrm677 (456727) | more than 12 years ago | (#3891800)

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.

Delphi and Kylix (2)

uradu (10768) | more than 12 years ago | (#3891811)

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.

Software Development for the World (5, Insightful)

yancey (136972) | more than 12 years ago | (#3892133)


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 .. or two.

Re:Software Development for the World (1)

fryguybob (443423) | more than 12 years ago | (#3895207)

I agree a whole lot with what you said, but I think you missed the origional question a little. There is still the problem of Cross-Platform development even with a good program design. Clearly it is good design to make a fully encapsulated back-end to a program, but the question still remains, what librarys are going to be used to make it. MFC and wxWindows are more then just a GUI (which very well could be a bad design). In order to make the back-end easy to program and cross platform, people look to tools like wx to simplify things. Unfortunaly in my experience wx simply wasn't stable enought to work and on top of that it didn't look right.

My advice, write the back end in a more portable langauge then c/c++ or use standard (stable) librarys that work and enought platforms. Write the back-end in Scheme, C#, or even (heaven forbid) Java. Then the backend will run on any system and the only code that can really reliably be cross platform is.

In my opinion, the UI of a program ends up better if the details are worked out for each specific platform. Lets face it users of different systems expect different behavior, wx cannot encode that, so you end up with junk on both platforms.

Re:Software Development for the World (3, Informative)

bruckie (217355) | more than 12 years ago | (#3895239)

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.

There's already a very good solution for doing this: XWT [xwt.org] .

XWT allows you to write the interface in XML and JavaScript, and the XWT viewer then downloads and displays that interface. When computation needs to be done, the XWT interface makes an XML-RPC call to a server.

In fact, there's even a demo chess program on the XWT site, now that I think about it. :)

--Bruce

Cross-platform from a UI standpoint (1)

kantok (49820) | more than 12 years ago | (#3893868)

Writing with a cross-platform GUI is a good idea from the coding standpoint, because it allows you to write the software only once and it will work the same everywhere. But working the same everywhere isn't always what you want...

Consider that when you write a GUI any given platform, you want it to "feel" like it belongs there. Every OS has its own defining characteristics and expected behaviors, and those are an important aspect from the user's standpoint and greatly help the overall consistency of the user's desktop.

For example in your cross-platform GUI, do you use standard Windows key bindings? Mac key bindings? Emacs key bindings? It doesn't matter what you choose, it will be foreign to some percentage of users because it doesn't match their expectations (the OS defaults). The same thing applies to a number of other behaviors (like menu organization, right-mouse-button actions, etc.).

So even if your cross-platform GUI toolkit renders using the native widgets of the platform, it's still not going to "feel" the same as a UI designed specifically for that platform. You may be excited because your app works the same on all platforms, but users won't be excited when it doesn't work quite right on *their* platform.

Whatever you use, don't use MFC (1)

NDSalerno (465736) | more than 12 years ago | (#3894601)

I have job experience using MFC. I will not describe it in detail. I will just sum it up and say that it is truly the most un-productive horrid framework I have ever used. Also, Microsoft's new WTL is no better. In short, the class wizard helps you half the time (if it aint broke when you modify some code) and the message maps are a nightmare. This automatic code generation you speak of is not all that glamorous. All that code generation gives you is a cryptic program that comiles to be Notepad. You're on your own after that. The Document/View architecuture is bad and seems to be a perversion of the Model/View/Controller architecture. Doc/View can be good for small scale, but will break down and give you nightmares on large scale projects.

I started using two pieces of technology, Delphi and Qt, and I have never looked back. At work I use Visual C++ to program DLL's (using STL and no MFC classes at all) and I use Delphi to front end, as well as write the back end stuff too! If I had my choice I would ditch Visual C++ altogether, I think it gives C++ a bad name. I wish most companies would not buy Microsoft Visual C++.

I have never used wxWindows, but I can assume that it is better than MFC. As for cross platform needs MFC still is the worst choice. At one of my previous jobs they had a person that programmed a project for both Windows and Mac OS. There is MFC for the Mac platform. However, this programmer was frustrated by the details because what worked on MFC for Windows worked differently (or not at all) for MFC on Mac OS.

For cross platform I would say check out Qt [trolltech.com] and check out Delphi / C++ Builder [borland.com] . Qt was one of the best C++ libraries I have ever used and I wish I could use it on Windows at work. Delphi kicks ass in all aspects. IMHO Delphi is the only technology I know that can truly claim the title of being a RAD tool. Kylix is Delphi for Linux. C++ Builder should be ported to Linux by Borland soon enough.

I recommend Qt (0)

Anonymous Coward | more than 12 years ago | (#3894630)

from experience. One code base. Win & Unix. It's just a matter of

(Unix)

qmake MyProject.pro; make;

or

(Windows)

oqmake -t vcapp MyProject.pro; VC++ open project and rebuild all.

and it works.

wxWindows Fails at Cross Platform (1)

fryguybob (443423) | more than 12 years ago | (#3894810)

I used wxWindows for a cross platform project simply because cross platform was a requirement of the project. It ended up with different bugs and querks on each platform that I used. I had to toss multithreading because it completely failed on one platform. It was not a problem to program in wx as it is clearly a copy of the MFC's design. Which makes you ask one question, why would anyone copy the MFC? It makes it easy to program in for an MFC programmer, but really it just gives a delusional sense to a windows programmer that they can do cross platform programming without any work.

Bottomline, MFC can work in Windows without bugs. Use something other the wx if you want stable cross platform support.

FLTK (2)

spitzak (4019) | more than 12 years ago | (#3895719)

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.

Re:FLTK (2)

captaineo (87164) | more than 12 years ago | (#3898689)

FLTK is an excellent toolkit. I have used many over the years (Gtk, Qt, TK, and Win32 all quite extensively), and FLTK is my current favorite. It is dead simple (in a good way), clean, fast, and doesn't constrain your code as much as other toolkits do...

BTW Am I correct in assuming that the upcoming public release of Nuke is going to be FLTK-based?

WxWindows is Disappointing (0)

Anonymous Coward | more than 12 years ago | (#3897844)

I've tried WxWindows on a few platforms using various toolkits and I've been disappointed. It seems to have a few gotchas that limit its use and quality. FOX and FLTK seem better than WxWindows. There are many more toolkits than just WxWindows that are portable. This is an excellent page about them:
http://www.geocities.com/SiliconValley/Vist a/7184/ guitool.html

FLTK is best for you (1)

Circuit Breaker (114482) | more than 12 years ago | (#3897945)

It's much simpler to program than ANY other toolkit (yes, Qt included); It doesn't cover as much but it tends to be sufficient for 99% of the programs. It works on Win32, X, MacOS and easy to port to other systems. Did I mention it's open source? It also has an extremely well written manual, and tens of concise, useful example programs.

And ... there's an included checkers program with full source that you can consult, as the GUI for chess and checkers is similar. Go on, download, compile and check it out; then look at the "possible moves" and "rank moves" display, and tell me if you can do it elegantly with that simplicity and without flickering in any other toolkit.

FLTK website [fltk.org]

Chose Qt over wxWindows during my internship (1)

motown (178312) | more than 12 years ago | (#3901866)

During my internship, my task was to compare all available low-cost (preferably but not necessarily Free Software) GUI toolkits. The main criteria was availability for and portability between both Linux and win32 platforms. I started with a large list (including some quite obscure toolkits), and after scratching them while comparing to certain criteria, I finally ended up with Qt and wxWindows as the two finalists.

The reason why FOX was not chosen was due to its lack of Unicode support.

Gtk+ would have been very nice, if it wasn't for the fact that the Windows port is quite neglected and only seems to be maintained sporadically, apparently solely for the purpose of porting Gimp to win32.

At first, wxWindows actually looked better than Qt, because it didn't need a preprocessor, didn't require license fees for commercial development, and provided a native look&feel on each supported OS. Furthermore, the project was about 10 years old, and therefore we expected the sourcecode to be quite mature. Finally, the vast selection of bindings for numerous programming and scripting languages was a major plus.

If I remember correctly, another really neat feature of wxWindows was the apparent possibility of (cross?)compiling wxWindows-based win32 binaries on Linux (and vice versa?). Someone here please correct me if that's not the case.

Unfortunately, as soon as we started playing with wxWindows, we noticed some flaws: first of all, the documentation currently available for wxWindows is limited and incomplete.

Second, part of the API turned out to be OS-dependent, and no warnings or errors whatsoever were issued when compiling code, which contained win32-only wxWindows functions. Under Linux, binaries would just generate a run-time segmentation fault. When the win32-specific functionality was removed and the code recompiled, the remaining product would run without problems. This was a major disappointment for us, since we were definately expecting more on this field from a project that was over 10 years old!

This serious lack of actual platform-independence, coupled with the fact that the documentation didn't specifically document whether if a certain function was available on every platform or not, would have made cross-platform development with wxWindows really troublesome. Therefore, we ultimately decided to go for Qt instead.

Let's face it: when it comes to a clear API, platform independence/portability (between X11, win32, and now also the Mac), stability, but especially documentation, Qt is currently unmatched. Given the quality of Qt, we decided that the licensing fees (which really aren't that high compared to some other GUI development products) would definately be worth it, especially considering the company support we would be receiving, as well as community support.

Another aspect which made Qt more attractive is of course the quality of the available development tools, specifically the excellent Qt Designer.

So to sum it all up: wxWindows is a promising toolkit, but still needs serious work in the following areas:

*) complete, accurate and up-to-date documentation (complete documentation of the entire API, including any platform limitations per function)

*) complete implementation of the entire API across all supported platforms (of course, platform-specific extentions should be allowed, but a definition must first be made of a so-called largest common denominator API for all platforms)

*) high quality development tools. I know many of you prefer not to use a GUI builder, but many other developers actually need it, or at least find it very convenient.

During my internship, I found mainly two GUI design tools for wxWindows, one free and one commercial/shareware, but none of them were even close in quality and ease of use to Qt Designer.

Even better would be a fully-featured develompent suite, integrating an editor, debugger and GUI builder in one. All (L)GPL Of course. :) Something like Delphi/C++builder, but then based on the wxWindows toolkit. That would definately be the ultimate development environment.

Re:Chose Qt over wxWindows during my internship (0)

Anonymous Coward | more than 12 years ago | (#3902057)

Just a note that afaik gtk2 on windows is taken a lot more seriously than its predessor.

Best tools for the job at hand (1)

Joe U (443617) | more than 12 years ago | (#3904160)

Use what you think is the best tool for the job at hand.

One of the worst things you can do is to waste weeks on cross-platform compatiblity when your project doesn't require cross-platform compatability. There are too many programmers who do this. You wind up with GREAT code that works on several platforms, but the company lays off half the staff due to the loss from delays.

When I want to write a small simple program, I use MFC every time. Why? Because I need it done yesterday and I need it to work.

Down with MFC (1)

NeuroMorphus (463324) | more than 12 years ago | (#3908851)

Drop MFC and learn wxWindows immediately!
You won't regret it.

Chris

MFC Automatic Code generation (0)

Anonymous Coward | more than 12 years ago | (#3914929)

One thing: automatic code generation ( as does VC++/MFC ) is not an advantage at all. It`s a disadvantage, but beginner programmers don`t realize this. They just like it because they think that they`ll write less code this way: FALSE. ( headaches included trying to change what`s been automatically generated.).Just take a look at the real visual development tools like Borland C++ Builder or even Visual Studio.NET (WindowsForms, not MFC)...
In my oppinion MFC is obsolete. ( it has features that compare to at most OWL, which was a long time ago around, and also a bad architecture and many many bugs). So stick to anything else...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>