wxWidgets Discussion Forum

Hi.

I'm a full time C++ developer working for a big company. However, I belong to a somehow small (less than 20) and to some degree "independent" group, and we're responsible of developing several products, some of them in C++.

It's common practice in my company not to use 3rd party libraries with the sole exception of Microsoft-based ones (ATL, WTL, and MFC). I've started to work in yet another "small" project that has been "frozen" for 2 years that (surprise) implements the same set of "core" classes all over again. You get the idea.

We (another developer and myself) have to maintain and extend this product, and we've discovered that some of the wxWidgets classes would be of great help.

The problem we have at the moment is that our managers, none of which know C++ and that have an inclination to use Microsoft products most of the time (you know, "nobody gets sacked for choosing Microsoft products") are objecting the use of this library, because:

* they feel that it could be "yet another unsupported library" (I think I can handle that one sending them links to several projects that use this)

* the license would not be compatible with the "special" situtation of having to show some of our customers the source code. I'm planning to object saying that considering we are not allowed to show Microsoft's standard library code cos that's a "requirement", we can say the same thing about wxWidgets.

* now the tough one: they think that MFC is so similiar to wxWidgets that there is no compelling reason to be the "odd one out" within the company.

Some of my project characteristics:

* It's a stand-alone executable that connects with two specific servers (each of a different type) and n clients, has multiple threads, and needs improving the architecture (such as elliminating unnecessary threads, using resource locking for some resource access, etc.).

* It currently uses MFC for some well defined tasks: GUI mainly.

* It was originally (until the MFC was starting to get used) written to be deployed to some Unix flavours and Win32. Of course it's a Win32-only app now.

I'm tempted to go the "potentially easy to port" route to justify the use of wxWidgets over MFC, but I fear the rudest "We don't care about portability... It's a Windows-only world after all".

The other idea I've had is to say that a mature and well-designed (better than MFC in several aspects, for example event handling) library will make the life of developers easier and more enjoyable, but as we all know managers don't really care about those things, so that's another "no-no".

So I guess I need some help here from you, the more experienced wxWidgets users and developers, to stress business-related benefits to use wxWidgets over MFC, even for a project where portability was once regarded as a bonus, but that now the portability aspect of it might be (I don't know for sure yet, as I didn't play my next "card" in this game) seen as a problem or obstacle instead of valuable for the project and ultimately for the company and their customers.

It's hard for me to answer to that kind of mentality without bashing at Microsoft...
Not to mean insulting (I hope), but your boss should open his eyes, it's not a "Windows-only world" anymore. Ask him if he wants to waste one whole year porting most of his applications to Linux whithin 2 or 3 years, because the share will probably be 80% Win - 20% *nix by then.
Besides, if the APIs are so similar (although wxWidgets is a tad simpler), then, put simply, "why not"? The effort of porting is not THAT big.
Regarding the license, I think I already found in a few places wxWidgets-based software available only in binary format.

OT - Monopolies are a Bad Thing, except for those ignorant VB programmers who are hardly able to learn C#, let alone C++ - the majority of today's .NET "developers"

Sorry, just had to let it out

AkiraDev wrote:It's hard for me to answer to that kind of mentality without bashing at Microsoft...
Not to mean insulting (I hope), but your boss should open his eyes, it's not a "Windows-only world" anymore. Ask him if he wants to waste one whole year porting most of his applications to Linux whithin 2 or 3 years, because the share will probably be 80% Win - 20% *nix by then.
Besides, if the APIs are so similar (although wxWidgets is a tad simpler), then, put simply, "why not"? The effort of porting is not THAT big.
Regarding the license, I think I already found in a few places wxWidgets-based software available only in binary format.

OT - Monopolies are a Bad Thing, except for those ignorant VB programmers who are hardly able to learn C#, let alone C++ - the majority of today's .NET "developers"

Sorry, just had to let it out

I have to agree with your personal views, but unfortunately I need compelling reasons, from the business perspective, to justify the use of wxWidgets over MFC.

Just assume my managers won't open their eyes, just assume they're prepared to say in 2-3 years... "we did not know the company planned to port some applications, so we need more time now to do things all over again". It's just sad. As a developer that cares, this is bad news. As a developer that wants to "secure" his job doing the same thing 300 times, and that cries for recognition when he discovered that hidden article about how to make some feature of some M$ product actually work as expected (example, "just call these functions in these specific order, send this message here, and then... voila! it works. why? hell... I don't know... but it works!") this is great news.

I need, as I say, some technical-ish reasons to say "see? we should use wxWidgets over MFC just because of this!".

Ideas, anyone?

they feel that it could be "yet another unsupported library"

Point them out that wxWidgets was started in 1992. Point them out that open source makes lack of support unrelated because code is "yours" forever

the license would not be compatible with the "special" situtation of having to show some of our customers the source code

The source code of wxWidgets is open. I can hardly understand why somebody would be not allowed to see it.

now the tough one: they think that MFC is so similiar to wxWidgets that there is no compelling reason to be the "odd one out" within the company

Tell them that functionality of MFC is only subset of wxWidgets functionality. Does MFC contain all the ways wxWidgets can do zip streams, PDF printing, console applications etc. etc. ? Are MFC applications ready for use on other platforms ?

"We don't care about portability... It's a Windows-only world after all"

WinCE is windows but needs different programming sometimes (thought I did not know MFC of WinCE). What if your clients will be working on some portable devices like driven by WinCE, Linux or others mobile OSes which have ports of wxWidgets currently developed? Will MFC work on so popular portable devices?

ABX

ABX wrote:

they feel that it could be "yet another unsupported library"

Point them out that wxWidgets was started in 1992. Point them out that open source makes lack of support unrelated because code is "yours" forever

Yes, you'd think that's a good thing. And although we do have bought Visual C++ 6 (several copies), I'm not aware of people here actually contacting M$ support. And I'm convinced that one of the greatest things about Open Source is the people itself, developers and users.

But still, it looks to me as if they'll object anyway. Some people feel safer when there's a company behind support. I guess we can search for one if they insist on this point.

ABX wrote:

the license would not be compatible with the "special" situtation of having to show some of our customers the source code

The source code of wxWidgets is open. I can hardly understand why somebody would be not allowed to see it.

Me neither. And as I said, I'd use the argument of comparing wxWidgets to MFC, or even the standard library. I don't think you can distribute the source code as if it were yours, along with yours. I think the best way to go is to tell customers "just download the library from the website. the required version is xx.xx.xx".

ABX wrote:

now the tough one: they think that MFC is so similiar to wxWidgets that there is no compelling reason to be the "odd one out" within the company

Tell them that functionality of MFC is only subset of wxWidgets functionality. Does MFC contain all the ways wxWidgets can do zip streams, PDF printing, console applications etc. etc. ? Are MFC applications ready for use on other platforms ?

According to the the wiki, not all of the MFC classes have an equivalent in wxWidgets. I know that doesn't mean that wxW is smaller or that it doesn't cover all of the functionality, but under the untrained eye that might give the wrong impression.

In that same topic page there is a list of reasons on why not use wxW instead of MFC. I guess that people that don't know the language (C++) and the library (wxW) can read that list and think "well, it's not quite ready yet".

ABX wrote:

"We don't care about portability... It's a Windows-only world after all"

WinCE is windows but needs different programming sometimes (thought I did not know MFC of WinCE). What if your clients will be working on some portable devices like driven by WinCE, Linux or others mobile OSes which have ports of wxWidgets currently developed? Will MFC work on so popular portable devices?

ABX

I know there's an MFC version for WinCE, so I guess they'd say "let's use MFC instead".

All in all, it's tough. My teammate told me about the article CSocket Considered Harmful, so I guess I'll use that and more information I hope to find about the problems MFC has. Once MFC looks weak, it's time to propose the "better solution".

I need compelling reasons, from the business perspective

wx makes programming a much more enjoyable experience. And happy programmers keeps productivity up.

But still, it looks to me as if they'll object anyway. Some people feel safer when there's a company behind support. I guess we can search for one if they insist on this point.

http://wxwidgets.org/support.htm

Note that many of the wxWidgets core developers offer commercial support. These are some of the most highly qualified developers in the world, which is a lot better than you'll get from a lot of companies (what's the chance for your company of getting someone at MS who has the knowledge and time to modify the MFC codebase if it is required to do so? Better yet what's the chance of getting one of the core MFC developers at all (considering MFC is becoming depreciated)?).

According to the the wiki, not all of the MFC classes have an equivalent in wxWidgets. I know that doesn't mean that wxW is smaller or that it doesn't cover all of the functionality, but under the untrained eye that might give the wrong impression.

Oh, come on - its the wiki . You should have seen what the class chart looked like before the wiki supported tables . Its also quite incomplete...

Anyway, in nearly every case there's an easy workaround....

In that same topic page there is a list of reasons on why not use wxW instead of MFC. I guess that people that don't know the language (C++) and the library (wxW) can read that list and think "well, it's not quite ready yet".

Yes - take a look at
http://wiki.wxwidgets.org/wiki.pl?WxWid ... r_Toolkits

It's a very unbiased comparison - compare and contrast carefully (note that a lot of the pro-MFC stuff [mayby most] was written by me).

All in all, it's tough. My teammate told me about the article CSocket Considered Harmful, so I guess I'll use that and more information I hope to find about the problems MFC has. Once MFC looks weak, it's time to propose the "better solution".

In your situation, I'd ask you and/or your company to contact Julian Smart ([email protected]) - not only is he our "publicity manager" and a core developer of wxWidgets, he's also the founder of wxWidgets and a generally nice guy .

Ryan Norton wrote:http://wxwidgets.org/support.htm

Note that many of the wxWidgets core developers offer commercial support. These are some of the most highly qualified developers in the world, which is a lot better than you'll get from a lot of companies (what's the chance for your company of getting someone at MS who has the knowledge and time to modify the MFC codebase if it is required to do so? Better yet what's the chance of getting one of the core MFC developers at all (considering MFC is becoming depreciated)?).

Yes, I "knew" support was available, it's just a matter of selecting the right one for our company. Personally, I see this as a plus, but I've been surprised on manager's points of view before, so I'm not sure that'll cut it. All in all, I think it's very close to ideal having the library author(s) supporting the product (close to ideal because some would say that's keeping the authors from improving the library).

Ryan Norton wrote:

According to the the wiki, not all of the MFC classes have an equivalent in wxWidgets. I know that doesn't mean that wxW is smaller or that it doesn't cover all of the functionality, but under the untrained eye that might give the wrong impression.

Oh, come on - its the wiki . You should have seen what the class chart looked like before the wiki supported tables . Its also quite incomplete...

Anyway, in nearly every case there's an easy workaround....

That's good to know. Yes, I know the wiki is not deffinitive nor authoritative, but I guess if the content's there for some time, people tend to "believe" or give some credit to it, especially people evaluating the product.

Ryan Norton wrote:

In that same topic page there is a list of reasons on why not use wxW instead of MFC. I guess that people that don't know the language (C++) and the library (wxW) can read that list and think "well, it's not quite ready yet".

Yes - take a look at
http://wiki.wxwidgets.org/wiki.pl?WxWid ... r_Toolkits

It's a very unbiased comparison - compare and contrast carefully (note that a lot of the pro-MFC stuff [mayby most] was written by me).

I've read that one too, but to be honest it does not look very well for wxWidgets. You see, for my company's mindset saying "MFC has greater range of good quality commercial components", "wx provides a far greater abundance of convenience classes, while MFC provides more windows-specific classes", "MFC has a smaller executable size than wx", "MFC has a broader range of components available, especially data-bound controls", "Some things are easier with wxWidgets, such as certain types of windows (always on top, etc.), while other things are easier with MFC, such as detachable toolbars", "Probably the strongest point to use MFC is MSVC, the IDE, itself" are all ways to say "MFC is better for us than wxW". As I stated before, they don't care about portability, so providing "better" windows-only functionality wrappers is a good thing for them, and they don't care about making ("silly") things like "always on top windows" easier, cos that's "up to good programmers to resolve".

I guess I need something like "there is no need of hacking the code to make wxWidgets work properly, whereas MFC requires a lot of hacking and/or workarounds" (it is suggested otherwise in the wiki, too), or "MFC has proved problems that are down to its design, whereas wxWidgets have proved itself valuable and well-designed", "wxWidgets allow the developer to use complex controls that are not available in MFC, unless using extra (commercial) components made by 3rd party vendors", etc.

So basically the idea is to make MFC look bad, while at the same time make wxW look good. The idea of having MFC unsupported in the future, at least not without buying Visual Studio upgrades, or MFC stand-alone versions for MSVC6, are all tempting. However, I have no proof of that. I'll have to search for that.

Ryan Norton wrote:

All in all, it's tough. My teammate told me about the article CSocket Considered Harmful, so I guess I'll use that and more information I hope to find about the problems MFC has. Once MFC looks weak, it's time to propose the "better solution".

In your situation, I'd ask you and/or your company to contact Julian Smart ([email protected]) - not only is he our "publicity manager" and a core developer of wxWidgets, he's also the founder of wxWidgets and a generally nice guy .

I probably will. He should have a good idea on why "his" library is better than MFC, or at least on what aspects it's better than MFC.

Wish me luck!

I don't think that there is really a "1 size fits all" answer to this one. One person may value cross-platform support while another may value the 3rd party support. That being said, here are my reasons for advocating wxWidgets:

* You have the source code. If there is a problem, you have a way to fix it.
* Very active development community. If there is a problem, you can talk directly with the library's coders to get the problem fixed.
* Very reasonable support costs. (Koan, tt-solutions, Anthemion)
* XML resources provide for better separation of code and GUI.
* Developing solely for Win32 is developing short-term and frankly short-sighted.
* Very active 3rd party contributors list. While many managers only see 3rd party vendors like RogueWave, there is an active wxWidgets 3rd party vendor list that just doesn't have price tags.
* Some 3rd party tools have 'C' interfaces and are easy to use with either MFC or wxWidgets
* Since you've already invested in VC, Lit Window (http://www.litwindow.com/index.html) can help you leverage that with wxWidgets.
* wxWidgets has wrappers for many different languages (C++, C#, Python, Basic, Lua, Perl).
* MFC is being phased out in support of .NET and the resulting support packages will most likely be expensive (if they're offered at all).
* wxWidgets developers haven't been found guilty of manipulating the software development ecosystem for their own selfish ends in a court of law.
* wxWidgets sizers adds for automatic dialog resizing and better control positioning that requires manual coding in MFC.


Botton line, the people that you talk to will only hear what they want to hear. I used to rewrite some of our MFC utilities in wxWidgets to show the ease of use and a completely native feeling interface. The response was "Why would we trust this utility that you wrote over the weekend when we have this utility that we've already been using and we know works?" My reasoning was that the department that used the utility was also using Macs, but that wasn't a big enough selling point.
Another area where I "snuck in" wxWidgets was for our easter egg. wxWidgets' zip handling was a life saver and provided a way to zip up the resource images and access the archive at runtime. MFC doesn't have functionality like this. Since .NET is just a rip-off of Java, it may have been added to C# though.
The end answer is that with MFC and .NET you are limited by the tools. They dictate what platforms you can support and the customers to whom you can market. With wxWidgets, you are only limited by your own programming skills. With one codebase, you can support Win32, Mac, Linux, OS2, WinCE, and now even Palm.
I wouldn't be surprised if a lot of us previous MFC coders, have forgotten all the features that we didn't have in MFC. I had to think for a long time on that list above before I remembered that sizers are a huge bonus not present in MFC. There are probably a lot more that we have put far behind us.

Here's a link that Novell put up a few months ago on porting your applications from MFC that might be relevant:
http://www.novell.com/coolsolutions/coo ... _cdev.html

jb_coder wrote:Botton line, the people that you talk to will only hear what they want to hear. I used to rewrite some of our MFC utilities in wxWidgets to show the ease of use and a completely native feeling interface. The response was "Why would we trust this utility that you wrote over the weekend when we have this utility that we've already been using and we know works?"

Thank you very much for your post. It has been very useful.

I do feel that at the end of the day what you describe in this quote might happen to me, too. It's hard when suggestions are resited more than taken into account.

Thanks again.

One page that I just noticed that might help enumerate some of the benefits of wxWidgets is located at http://www.tt-solutions.com/en/wxwindows/

Julian Smart's presentations on wxWidgets also demonstrate many aspects of the wxWidgets framework.
Presentation: http://www.wxwidgets.org/fosdem2003/html/talk/talk.html
Tutorial: http://www.wxwidgets.org/fosdem2003/htm ... orial.html

jb_coder wrote:One page that I just noticed that might help enumerate some of the benefits of wxWidgets is located at ...

Thanks for the information. I was aware of Julian's presentations

Sadly, my company does not want to go with wxWidgets for now, and the next best thing would be to wait until we have to start another project for us to consider it. My claims and suggestions were not heard, and finally I changed my suggestion to: "I don't think it's right for us. I realized I'm alone in this and it would be pointless to spend more energy trying to convince everybody to use something that I believe it's better than what we have, something that nobody is taking the time to evaluate seriously".

Let's see what the future brings. I'll be proposing wxWidgets next time I can, though

Just to remind people that in case it helps, I offer a free CD-ROM containing a consumer application built with wxWidgets running on Windows and Linux (and a beta for Mac OS X), for people trying to persuade their company or department to adopt wxWidgets. It's packaged professionally (and shrink-wrapped) which is a psychological advantage compared with pointing people at a download.

Please see the front page of the wxWidgets web site for more details.

Julian