First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.
When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.
Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).
FOXAfter all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.
FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.
Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).
wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.
JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).
So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.
I don't know the particulars of the situation, but it sounds like your organization (like most others) focuses on people and not on process. Basically, you assume that when something fails or someone doesn't "work out", it's the fault of the person ("Stupid Peasants") and not the processes, policies, and management ("Flawed Government") that dictate much of their everyday routine.
I've seen many companies like yours where you focus on insanse quizzes (which are most likely illegal in some states of the U.S.) and questionaires to hire people. Then, when the person gets the job, they are forced to wander around the building begging people to help them get started. There is no documentation on your processes. You have no way of initiating new developers. There is no software quality assurance group responsible for the quality of the process and the code. Projects only succeede if the grandmaster coder or super project manager are on the team. And, you insist that all developers perform as well as your current "uber-geek-god-coder" rather than accepting that people work at different levels. Worst of all, you have no way of empirically measuring what the uber-geek does different, let alone what "perform as well" even means.
What you need to do is move away from your people focus, and start adopting a process focus. This way of running things assumes that people are intelligent, and that if they don't perform well, then there's something wrong with the processes and policies. In other words, rather than firing people, find a way to improve things for them. If you do this, then you can spend less effort trying to find uber-geeks as regular folks should be able to work efficiently.
The best thing I've seen for this (and what I currently follow) is the Capability Maturity Models at CMU's SEI. It is a very good process which focuses on measurement and doesn't require any particular development method. We use a mix of XP and other stuff for our processes. The primary thing CMU tries to emphasize is that you should always try to improve your process (something the manufacturing industry has known for about 20 years). This continuous improvement is what is needed to stay ahead of the competition, and has worked well for many other industries. The trick is improving process without stifling creativity (although, most coding I do isn't that creative).
The downside to CMM is that people assume it will cause all their projects to instantly succeed. This would be a matter for another discussion, but let's just say that I can't think of any other industry that tries so hard to make so much crap "succeed". CMM will only help you produce the best crap you can, it doesn't turn crap into gold.
Finally, it seems that your managers tend to blame the workers when things go wrong, even though managers setup nearly everything in the environment. This way of running things will probably need to be the first to go since CMM (and any process improvement) forces management to admit that they are responsible for failure since they are in control. Once that psychological hump is rolled over, things get easier.
Enjoy! And I hope you start looking at your management practices, not your hiring practices.
Slashdot Mirror
Ooops, I screwed up the link to SILC, it's actually http://www.silcnet.org. I hope Pekka isn't mad :-)
First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.
When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.
Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).
FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.
FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.
Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).
wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.
JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).
So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.
I don't know the particulars of the situation, but it sounds like your organization (like most others) focuses on people and not on process. Basically, you assume that when something fails or someone doesn't "work out", it's the fault of the person ("Stupid Peasants") and not the processes, policies, and management ("Flawed Government") that dictate much of their everyday routine.
I've seen many companies like yours where you focus on insanse quizzes (which are most likely illegal in some states of the U.S.) and questionaires to hire people. Then, when the person gets the job, they are forced to wander around the building begging people to help them get started. There is no documentation on your processes. You have no way of initiating new developers. There is no software quality assurance group responsible for the quality of the process and the code. Projects only succeede if the grandmaster coder or super project manager are on the team. And, you insist that all developers perform as well as your current "uber-geek-god-coder" rather than accepting that people work at different levels. Worst of all, you have no way of empirically measuring what the uber-geek does different, let alone what "perform as well" even means.
What you need to do is move away from your people focus, and start adopting a process focus. This way of running things assumes that people are intelligent, and that if they don't perform well, then there's something wrong with the processes and policies. In other words, rather than firing people, find a way to improve things for them. If you do this, then you can spend less effort trying to find uber-geeks as regular folks should be able to work efficiently.
The best thing I've seen for this (and what I currently follow) is the Capability Maturity Models at CMU's SEI. It is a very good process which focuses on measurement and doesn't require any particular development method. We use a mix of XP and other stuff for our processes. The primary thing CMU tries to emphasize is that you should always try to improve your process (something the manufacturing industry has known for about 20 years). This continuous improvement is what is needed to stay ahead of the competition, and has worked well for many other industries. The trick is improving process without stifling creativity (although, most coding I do isn't that creative).
The downside to CMM is that people assume it will cause all their projects to instantly succeed. This would be a matter for another discussion, but let's just say that I can't think of any other industry that tries so hard to make so much crap "succeed". CMM will only help you produce the best crap you can, it doesn't turn crap into gold.
Finally, it seems that your managers tend to blame the workers when things go wrong, even though managers setup nearly everything in the environment. This way of running things will probably need to be the first to go since CMM (and any process improvement) forces management to admit that they are responsible for failure since they are in control. Once that psychological hump is rolled over, things get easier.
Enjoy! And I hope you start looking at your management practices, not your hiring practices.