Slashdot Mirror

It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense. This occurs mostly via GTK, which seems to pull in a significant chunk of GNOME.

I run a minimalist Gentoo desktop, and I notice when additional dependancies are dragged in. The past year or 2 has seen goffice, ghostscript, harfbuzz, dbus, and various other crap become hard-coded dependancies for gnumeric. It was not necessary a couple of years ago. If I had several million dollars, I'd hire a bunch of progragrammers to port gnumeric from being dependant on GTK to being dependant on FLTK (Fast Light ToolKit) http://www.fltk.org/ Some of the money would go to ongoing maintenance.

Another few million dollars, and I'd like to hire a team to hack and slash away at Firefox. I was around when "Phoenix" was forked as a lightweight alternative to the Mozilla web-browser. I savoured that promise. That promise has been dashed into the ground, with a Firefox that's bigger, heavier, and slower than the original Mozilla ever was. Time for a new fork.

I want GNU-Linu-x, not GNOME-Lenna-x

Bill Spitzak is a well-known developer, particularly in the film industry. Among other things he created FLTK. Here's to you, Bill.

For small use FLTK
Or more options here

Show me their standardized network...

http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio.html

...threading...

http://www.boost.org/doc/libs/1_40_0/doc/html/thread.html

...GUI...

*shrug* There's not a *standard* GUI, but there are a few high-quality ones:
http://qt.nokia.com/
http://www.wxwidgets.org/
http://www.fltk.org/

oh yeah i just wrote a FLTK http://www.fltk.org/doc-1.3/main.html app that is 241 kilobytes in size for you. its a friggin text box too. (compiled for windows) http://d01.megashares.com/?d01=7fa4fa1 if you are interested. yea most developers think like you, just add more & more crap until the app is so slow its totally unusable. how many people actually use the regional encodings of apps anyway? i have heard that most of the common commands dont translate well anyway. it seems to me that a lot of apps include all the unicode bloat without actually including any localization.

Alternatively, you could stick with "standard" Linux (like DSL on your SBC and then run another GUI than X11 + Gnome/KDE/etc. I played five years ago with an Agenda PDA (remember those??), which was running a tiny Linux with FLTK (Fast Light ToolKit, pronounced "fulltick") on top. Developing in FLTK was very straightforward, which is probably important for your Industrial Contol application. And it is pretty portable, I ran the same applications on my Agenda PDA, a Linux Desktop or on my Windows PC.

Now you could also argue that Android on your SBC would give you a better choice of GUI-ed apps on your device like a browser and email. I guess that that's what finally will drive your decision, do you prefer "standard Linux" with all its tools, as long as they are non-GUI, or are the GUI-ed tools that come with Android the right ones for you.

an open source image editor Cinepaint is in the middle of a rewrite to convert from GTK to FLTL, Fast Light Toolkit to free up some memory and CPU cycles by using a more spartan interface. The pro's want they work to be pretty, not their software.

Though I do little Windows programming, I do want to back up the above about GDI+, which was an incredible waste of time and effort on my part. I thought just a little bit of rewriting of fltk and we would get antialiasing lines and polygons and filtered arbitrary image transforms, just like it looked like you could get with Quartz on OSX and the (still rather rudimentary) Cairo on Linux. Though writing a cross-platform API I was very interesting in locating the common functions between these, and in the case of Cairo, trying to encourage them to not be incompatable with GDI+ for no good reason as I (mistakenly) assumed it would have huge influence (mostly I want them to remove the effect of changing the CTM on an already-selected pen or font).

It was incredibly frustrating to discover after a good deal of research and attempts to compile it that it was never going to work unless you had the right driver (ie it was an *option*) and that code was expected to support the old api as well. And then to find out that Silverlight had nothing to do with it. Currently we are getting better graphics on X (with XRender) than on Windows (ie images filter when resized) and on no platforms are we using the more modern api, and all the blame can be put on the mistaken impression that Microsoft was going to deliver what I expected in GDI+.

That using the foxes thing is pretty weird.. don't know what that's all about.

Seriously. There are already libraries such as FLTK and QT for the graphic front end. For the back end, you could use XySSL, OpenSSL, or even GNU GPG.

I'm about 20 hours into an encryption client, and I've already got people using it. I initially wanted to use GPG, but realized that most technophobes won't go for a command line application. So I pulled out FLUID (the FLTK design utility) and had a prototype working within hours.

Today, there's no excuse for not encrypting your email. I realize that you may think you have Constitutional rights in this regard, but GW & Co. have the guns, the taxpayer financing, and even the (unsolicited!) cooperation of the major network carriers. It doesn't matter what you think the Constitution says if you can't even get a trial. You're on your own from here on out.

So why encrypt, even if you've nothing to hide? Well, simple, really. Why let the government violate the 4th ammendment with impunity? If you encrypt your email, the government can't perform secret, mass surveillance. Sure, they can pound on your door, and even demand the key. You might even have to give it to them. But in them doing so, you've achieved three key goals:

1. In order to get the key from you, they'll have to contact you. So they can't secretly eavesdrop on your communications.
2. Should you refuse the key, they will have to convince a judge to order you to divulge it - thus, your 4th ammendment rights are preserved - the judge will require probable cause before issuing the order.
3. In demanding the key, the issue will move from the administrative branch to the judicial branch. You want to force the government into the courtroom so that your other rights are not trampled as well.

Encryption is highly Constitutional (TM) software. It keeps terrorists from eavesdropping on our conversations, knowing our whereabouts, and stealing our valuable intellectual property. If the government can't read my email, neither can the terrorists.

Be patriotic. Support the Constitution. Encrypt everything.

the Linux platform needs ... A set of standardized GUI libraries that are free for both commercial and open-source applications.

You mispelled "proprietary" there. It's cool though, lots of people do it.

Also I'm not really sure why you think the Linux kernel needs widget toolkits.

Anyway, yeah there's totally no toolkits that allow proprietary apps.

Each to their own. Personally I prefer http://www.fltk.org/

You might want to take a look at pyFLTK, based on the excellent FLTK (Fast Light Toolkit). FLTK's got very good OpenGL support, and from the pyFLTK Examples page it looks as though pyFLTK supports it as well.

Yes, exactly.

As an illustration, I avoid using my very own application if I can help it under OS/X, because it so doesn't fit with the rest of the desktop. I wrote it with a portable toolkit (FLTK) that doesn't require X11, but still looks like one. It doesn't work well with all the rest of OS/X. I painfully got D&D working, I think I can get the menus sort-of worked out, but this is not good enough.

I know some clients use it, I never had negative feedback, but based on my own opinion they can't possibly love it. If the author doesn't like his own creation, what hope is there ?

Last month the DSL developers released DSL-Not, a.k.a. DSL-N 0.1 RC1. It's 83.5MB of DSL coated with GTK sugar. Yummy!

Do you consider FLTK (http://www.fltk.org/) too bloated or not decent?

[This is not a troll, it's a serious question from someone who's about to start a major db-driven web app.]

OK, everyone knows Java's a nonstarter these days. Ack, why did they kill it with Swing instead of a decent lightweight GUI (like wxWidgets or FLTK or something)? And they never got the memory usage under control.

But why Ruby and not python? What sort of errors is python prone to that ruby avoids? We have a bunch of python code here (scons and other stuff) and a bunch of older perl, and I'm reluctant to start a big web app in Yet Another Language. We all know python pretty well now. Is ruby going to be that much more maintainable? What about TurboGears for instance?

Also there seems to be a wider variety of libs available for python than ruby. And the python docs are very good. So I'm very interested to hear about the error-prone nature of large web-app development in python.

-- SilentTristero

Fortunately, there's MinGW, various IDE's, and a bunch of
Open source
libraries available online.

Or if you don't want any bullshit, and just want to get work done with smallest possible foot print, FLTK. If you're on Win32, download Dev-Cpp and use fltk2.

http://fltk.org/

http://www.bloodshed.net/devcpp.html

I have migrated from my legally bought Visual Studio to this bare-bones platform, and I am an order of magnitude more productive.

With FLTK, I wrote a 3D voice signal visualization and analysis software in three weeks. With native OpenGL. This stuff is what wet dreams are made of. Highly recommended.

I'm speaking as/for a commercial developer which already has a working port on Linux of a very large and powerful app but can't release because of the license mess the linux GUI/OS is in.

Licence mess? Hmmm...

Have you looked at projects like FLTK, wxWindows, Tk from Tcl/Tk, TIX, the Adobe Source Libraries, or Mozilla's XUL and XPFE etc? It's definitely possible to develop closed-source GUI software on X11 with a range of widget sets without violating licences.

And really, if you're developing closed-source software and want the KDE look-and-feel, you can always purchase a Qt developer licence instead of opensourcing your code.

There is no one-true-widget-set which forces you to open-source your code. The closest thing to a "one-true-widget-set-for-X11", it would be Motif - and even that is free if you're developing for Linux - see OpenMotif...

I suggest not using the term "free" to describe anything you have to pay for. This whole "free as in speech" software was a scam right from the beginning. Imagine you're in a store and you ask the clerk how much something costs, and he says "that's free". So you put one in your pocket and when you leave the store, he says "hey, you didn't pay for that." "When I said it was free, I meant you could change it once you bought it." Sounds pretty stupid, right.

Now, this "free as in lunch" is just as confusing, because, as you mentioned, "there's no such thing as a free lunch." But, for example, I've used FLTK on several personal and comercial applications, and I never had to pay any money, and I never will. It's "free as in no cost".

As I understand it (which, admittedly, is rather naively), the biggest danger in using a WYSIWYG gui designer (which, unless I'm mistaken, describes dreamweaver? I've never used it, so tell me so, if I am mistaken) is cross-platform-ness. You might align several forms with each other and put a graphic above them, and suchlike things, but then if someone else looks at the page using a different browser, on a different system, with a different screen resolution, it could very well be all screwed up. Unless you do significant testing in many different environments, you run that very serious risk. Of course, this also applies to guis you handcode, but I would venture to suggest that a gui you have handcoded is a little bit easier to tweak, simply because you already know the code.

That said, IANA gui designer. I have done a minute amount of gui work on a program which ran solely on one system, and I did use a graphical tool, fluid (http://www.fltk.org/), to do it. However, one of the things that I liked about fluid was that it kept you a lot closer to the code than the only other gui designer I've played with, glade. You got the benefits of laying out the gui graphically, as well as the benefits of knowing the code (at least somewhat).

The real problem with OSS apps for graphic artists is that programmers do not understand how artists work. This has always been the dichotomy between programs with good GUIs and programs that don't.

Actually, you're making a fairly wide-ranging and erroroneous generalization there. For example, one of the key people and admins for Inkscape is a professional artist, not programmer. Several other artists are also involved (including those with MFA's, etc). I myself am a programmer, but cut my teeth in charge of engineering for a small multimedia company, and even have formal art training. I can say with certainty that how artists work is well known and considered by most involved in the project (and man, some of those artists can be quite vocal).

The Gimp also has been fairly well used by art professionals. The Film Gimp (aka CinePaint) being one of the more intereting branches. That one is used by serious professional artists, and is worked on by many engineers who are paid to support those artists and give them what they need...

However, have you seen how they're taking their branch in regards to UI? They're switching it to FLTK. Personally I think it's one of the oooooogliest UI toolkits around (and very un-photoshop-ish). However, it is highly functional, and helping the artists get their work done is what the programmers at Rythm & Hues, Sony Imageworks, ILM, Dreamworks and such are paid to do. Trust me, they know art workflow.

You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model.

Under Linux XFree, you can use GTK+, fltk, wxWidgets, Java, C# w/Mono, or even straight xlib. Again, the only environment that has any type of stupid restrictions is KDE/QT, so stay away from KDE/QT if you don't want to pay a fee. Under Linux, GTK+ applications run just fine under any other desktop environment, including KDE/QT. I personally think the KDE team made a _huge_ mistake when they pick QT. To require a commercial license for native desktop tools is just stupid IMO. However, there are _plenty_ of other great toolkits like GTK+ that have none of those restrictions. With GTK+ you can develop OSS or closed, the choice is yours.

Under Windows, you also have the option of using an older, very much less expensive version of Visual Studio -- those are still 100% functional and produce fully functional applications under XP (and 95, 98, 2000, and NT) and I see no reason they won't remain so.

I think that if Linux ever matures enough to "come with" a standard, always-there, reasonably modern GUI-API such that software can be directly written to and for it

There is no single "utopia" OS or development environment. Trying to single out just Linux makes you sound naive, especially when the MS windows development environment has just as many quirks.

FLTK 2.0 http://fltk.org/ is able to draw using Cairo too, by defining "USE_CAIRO" variable (--enable-cairo).

[Sorry, hit post before I was ready. Here's the rest]

It also has to do with firefox's cross platform XUL interface, IE has a much lighter interface that just calls OS functions, firefox can't do this so easily as it would become far less portable..

I've seen plenty of lightweight, platform independent user interfaces. For instance, applications written using FLTK frequently have memory usages of less than 2Mb on my system, and are capable of being built without modification on Windows, UNIX/X11 and OSX. Admittedly I don't think FLTK is mature enough yet to support an app as complicated as Firefox, but it exemplifies an approach which I believe the firefox authors should have taken.

XUL is interesting, but I'm not sure it was a wise idea.

Also, firefox has a far more complete rendering engine, including proper support for png and much better css/css2 support,

I've added proper PNG support to one of my applications lately. It added about 400K to the code size, which wasn't loaded into memory unless a PNG image was loaded. Runtime memory usage did not increase at all, except in the case where an image that was previously 24 bits per pixel became 32 due to the presence of an alpha layer. Which hardly accounts for such a large difference.

The better CSS support is interesting, but comparing current firefox memory usage to that of older versions of mozilla before this support was added, I'm pretty sure most of the memory usage is going on XUL.

Which is a waste. It provides features that most of us don't need.

You forgot about Fltk http://www.fltk.org/ for your interfaces needs (free and portable) and Dev-C++ from Bloodshed software http://www.bloodshed.net/devcpp.html which is a great IDE for windows (which is also free!). Of course, you don't get all the fonctionnality of Visual C++ in one package, but it does the job without problems (at least for me :)

Or, if you don't want to make your Win users install the proprietary QT Windows trial, you could try FLTK.

I have worked on commercial software for three different commercial companies, including a very large one (three letters, starts with S), and also on a "smaller" open-source project (fltk).

Even this small open source project gets me far more "code review" than anything at any commercial place. Nobody looks at commercial code, they do not have the time. EVERY single fix and improvement is suggested, located, and coded by me. All I get are bug reports, almost all of those are "I ran it for 3 hours, I forget what I did, and it crashed!"

In fltk, certainly there are bugs reported, and just like the commercial stuff the same bug is reported dozens of times, by people too lazy to even check if the bug is already in the database. But I also get many patches where people actually found out about the bugs. The number of patches I have received for the commercial software (where many of the users have access to the source code)? ZERO!

The other comment about accepting blocks of unknown code is bogus. The submitted patches are all about 1 line long and I can easily tell if they really fix the problem. Same is true for the commercial software, incidentally. Any contributed code is always read over and analyzed.

I can catagorically state that my OSS software is higher quality than my commercial software. Now I spend about 10x or more time on the commercial software, and it is probably 20-30x more complicated than the OSS stuff. Therefore it is more valuable, but that does not mean it is better.

Unfortunately the real difference I am talking about is the difference between commercial development and a hobby. Unfortunately for your argument, it is obvious to me that "hobby" software is much higher quality than commercial. The difference is in the motivation of the authors, and the fact that they know their work is visible to the world.

Seriously not trolling.

Care to point out a tiny sample of "most" Open Source that follows this norm?

In the interest of being taken seriously I will point out a few that I know of that seem rather well thought out:
fltk
FOX
gcc
Oh yeah, here
and others

You were modded informative yet I see nothing informative in your post. Perhaps because I have contributed to some of these projects and I am jaded? Perhaps because more work gets done in these projects than the corporate arena of closed source that I used to work in and I might be close minded and missing your point? It's a possiblity but I will try to become openminded in case I missed the informative part of your post.

The "new feature that you're never going to use" marketing potential aside:

QT isn't even free software. It's GPL'ed on X11 and the Mac - but not the most popular development platform: Windows. Expect to pay $1550 per seat for the privilege of developing there. Because no GPL version is available for Windows. Don't expect to port to Windows without paying the Trolls.

The price instantly puts the toolkit out of reach for smaller development houses - and merely makes it insanely bad value for money for larger shops. For that price you can get an entire high-end computer AND a bunch of Microsoft software development tools (although if you were paying attention to Slashdot yesterday, they just released their compiler for free). It's bad value for money on all fronts.

For those who want actual freedom with the SDK they use, I would recommend that you try wxWidgets.

If that's not suitable, try one of: GTK, Fast-Light Toolkit or even the Fox Toolkit.

But please, for the sake of your code - anything but QT.

All of the above have LGPL or LGPL style licenses, and at least FLTK and wxWidgets have exceptions for static linking, so there should be very few licensing issues with them. There's probably more, but these the ones I know off the top of my head.

A lot of FLTK apps are available here. There are quite a few. A good demo of the usefulness of the toolkit is this application.

Another little FLTK applet which I like a lot is xpp.

The FLTK toolkit (Here) worked pretty well for me. I don't know how it compares with QT, but if you're doing basic GUI stuff, there really isn't anything missing. It is GPL for Win/Mac/Unix.

Fltk is what you want. Qt's pricing sucks ass anyway.

that the new file chooser will be replaced in the next GTK+ release because even after lots of review, etc. people will start bitching after it is released.

We went through this two years ago with the FLTK file chooser, resulting in this. We did a design context, voted on the results among the developer community, and then released the new chooser in 1.1. We started getting suggestions for a new file chooser about a month later...

We're dealing with this in a simple way - all of the change requests are essentially cosmetic, so if someone wants a different looking file chooser, they can code it themselves...

FLTK's file chooser uses the best of all worlds... GTK should probably just adopt it and be done with it.

I don't know why you think that GTK is the only cross platform toolkit, because it's about the crappiest one (no, GTK on Windows isn't any less horrible), but good ones make cross platform programming a breeze. C++ rather than C tends to be the language of choice. I prefer wxWindows, but theres a number of others, including Qt, FLTK, and FOX.

Try fltk

A more practical response is that all theoretical damage of the GPL is well known and is avoided in the real world. All code of any value for developing new and innovate programs is released using licenses like the LGPL, LGPL with exceptions to make it even more like public-domain, or BSD or public-domain licenses.

I write LGPL+exceptions code (the exceptions are the typical ones where you can use the library as though it was a public-domain closed source library, but if you modify any of the source code to the library you must release all the changes if you redistribute it). I know for a fact that my code would not be used if it was GPL so I am strongly encouraged to not do that. This is true of almost any writer of open-source code that is designed to be a service, and thus completely defuses any argument that it somehow harms advancement and use by anybody. I also write GPL code but that is because it is an end application, that code is useless to anybody except to make a very similar program, which I would consider the theft of my ideas and IP. Also I know that the fact that it is GPL has zero impact on the popularity of this code, because it has zero impact on the ability to run it, which is the main use.

Vertical scrolling is currently done by moving the entire menu window, not it's contents. This happens when the mouse is moved to the edge of the screen where the menu goes off the screen. This does have some problems, for instance to stop the scrolling the user must move the mouse at least 1 pixel away from the edge. Horizontal scrolling is not implemented yet. I think the scrolling behavior I have needs work and testing, also X is not really all that hot at moving windows, for instance I only move one window, not the whole hierarchy, because it won't move them nicely.

I have not figured out any way to handle the popup menu whereever the mouse is without placing some of them off-screen. Moving the mouse pointer is bad UI, I tried it, and tried moving it back after release. This was not very user-friendly.

Hey, Easy Package Manager looks great. It's comparative table of existing installer/packager formats is a good answer to this topic. And it even has a FLTK graphical frontend (I love FLTK for its speed, lack of bloat and beautul API). However, it does not support Windows, which is raher logical from the design point of view.

But I found a nice list of existing packaging tools at the A-A-P which "makes it easy to locate, download, build and install software. It also supports browsing source code, developing programs, managing different versions and distribution of software and documentation." Definitely worth a look!

IMHO, the problem with Swing is mostly that it is horribly overengineered and, frankly, that the implementation sucks. It's all in src.jar - read it and tell me if you would hire someone who would present that piece of crap as their prior experience.

FLTK provides these benefits as well, is C++ based, and it smaller too!

If you really want C++, you can also go for Carbon. It's possible to use Carbon Events and nibs for a semi-current development approach which utilizes Mac OS X's full capabilities.

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've tried out Fltk. It worked alright for simple tasks, but I couldn't figure out how to make more complex programs.

For instance, I wanted my program to use TCP/IP (regular bsd calls: socket, accept, recv). I used Fl::add_timeout and Fl::repeat_timeout to check the incoming buffer every few seconds (no need for high data rate).

That worked great- unless I made some call like fl_file_chooser, which blocks until it returns. Then the timeout function won't happen until the dialog box is done- a fact completely ommitted from the documention.

I suppose I could dig into the source code (it is LGPL after all) and try to fix it, but things like this don't inspire confidence.

I've tried out Fltk. It worked alright for simple tasks, but I couldn't figure out how to make more complex programs.

For instance, I wanted my program to use TCP/IP (regular bsd calls: socket, accept, recv). I used Fl::add_timeout and Fl::repeat_timeout to check the incoming buffer every few seconds (no need for high data rate).

That worked great- unless I made some call like fl_file_chooser, which blocks until it returns. Then the timeout function won't happen until the dialog box is done- a fact completely ommitted from the documention.

I suppose I could dig into the source code (it is LGPL after all) and try to fix it, but things like this don't inspire confidence.

I've tried out Fltk. It worked alright for simple tasks, but I couldn't figure out how to make more complex programs.

For instance, I wanted my program to use TCP/IP (regular bsd calls: socket, accept, recv). I used Fl::add_timeout and Fl::repeat_timeout to check the incoming buffer every few seconds (no need for high data rate).

That worked great- unless I made some call like fl_file_chooser, which blocks until it returns. Then the timeout function won't happen until the dialog box is done- a fact completely ommitted from the documention.

I suppose I could dig into the source code (it is LGPL after all) and try to fix it, but things like this don't inspire confidence.

http://www.fltk.org