Slashdot Mirror

I also avoid GTK, but mainly just because it always feels "off" on Windows.

I have heard good things about the FOX toolkit (http://www.fox-toolkit.org/). The Goggles Music Manager was written using this. Looks very Windows-ish on Linux, so I would expect it to FOX based apps to be comfortable for Windows users.

Take a look at something like Acronis TrueImage (or any Norton program) before/after their transition from C++ to C++-with-C#-user-interface.

As someone who worked in Acronis, and wrote a bunch of code for True Image, I feel obliged to tell you that there's no C# code in it at all - it's all pure C++. Acronis SDK (which is a separate thing, and IIRC comes only with True Image Enterprise) has component that exposes .NET API, and that's written in C#, but it's separate from True Image proper, and those C# APIs are just sanitized wrappers on top of the original COM API (which is implemented in C++), and, in fact, most of C# code there is automatically generated from COM interfaces (I know that because I'm the guy who originally designed that part of it).

As for GUI in True Image (and pretty much all other Acronis products) - it's FOX Toolkit, or rather, forked and heavily-customized version of it (since it's LGPL'd, you can request the source code with customizations here).

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

• Qt: Until being bought out by Nokia, their core business was licensing Qt commercially so it would have been a sound enough bet for closed source development (a little expensive maybe). For open source, it's GPL so no issue there. At this stage though, I'd be a little nervous if I had bet the company on Qt.
• GTK+: The toolkit that underlies Gnome is licensed under LGPL. This means it's permitted to create/distribute closed source apps which use GTK so the only question is whether you like the toolkit. GTK is written in C and not everyone like the approach that it has taken.
• GTKMM is a C++ wrapper for GTK+, also licensed under LGPL so it's good for commercial and open source

Threading is bad. Don't use it. When you have to use code that uses it, refactor the code to use processes or a state machine. It can be done.

I'm sure that it *can* be done. But that doesn't help us get the MASSIVE chunk of UNIX software built for MINIX. For example, I'm trying to build FOX for a GUI since I can't get GTK+ built. It won't build without pthreads.

If Minix wants to remain compatible, it should implement green threads at a minimum. If it wasn't ever intended to be compatible, then it shouldn't have implemented the UNIX/POSIX design. Mr. Tanenbaum could have looked into a brand-new kernel design that was better suited to microkernel design than Unix. But he didn't. So, pthreads are a requirement.

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

wxWidgets is LGPL. You should be able to dynamically link to it while still licensing your software as you see fit. It may have a static linking clause, allowing you to link statically instead of only dynamically. You'll want to check on that, though.

What about using FOX? It's far lighter than wxWidgets or QT, while still offering a decent cross-platform GUI. And it's LGPL, with static linking exceptions.

Because QT IS NOT FREE.

Unless you pay TrollTech, you have to release the source code for your programs under the GPL. Not even MICROSOFT charges you to use their APIs - nor do they force a licence on you. If you write programs that you release under the GPL, let it be YOUR choice, not your toolkit's choice. If you ever want to close your codebase - you can't. Sorry, Trolltech won't let you. I honestly don't understand how insane someone would have to be to support Trolltech.

QT's restrictive licence is the REASON that libraries like GTK exist. Libraries like GTK are licenced under a variant of the GPL called L-GPL (library-GPL or lesser-GPL). This allows you to link your code with their libraries - and release your code under whatever licence you desire. You only have to release code if you modify the windowing library itself - which not many would do, but if you did - at least you wouldn't be providing free labor to Trolltech.

Read the headline of this press release from TrollTech's site:

Qt cross-platform development software will be available under the open source GPL license for open source development and a commercial license for commercial development

And their price for 2 platforms (the only reason you'd use a library in the first place is cross-platform development) - is $3000! PER SEAT!

Did you read that? Do you really want to pay HARD CASH to Trolltech for what is a WINDOWING LIBRARY. If you moved to Linux because of the cost of doing business on Microsoft Windows - re-examine the costs: Windows XP OEM is $149, has free downloadable development tools including the Visual C++ compiler, no royalties, no charge to use the API, release your code however you want. COME TO YOUR SENSES!

Please don't give me that "if you're a commercial software developer you can afford it" speech - it's untrue. I couldn't afford a new computer right now - and that would only set me back $1000 - let alone three times that for a library.

There are plenty of cross-platform alternatives that DO NOT require licencing fees to do whatever you want with your application. For example:

* wxWidgets
* Fox Toolkit

Please do yourselves a favor and avoid Qt like the obsolete plague that it is. Please, cross-platform developers - you really don't want to replace one Microsoft thorn in your side with the iron spike that is Trolltech.

I'd like to know where I could download Pathfinder. You can see Pathfinder in one of the screenshots.
Few minutes with Google revealed it uses Fox-Toolkit and it's being deleloped by Jeroen van der Zijp, but nothing else.

I believe you mean Fox Toolkit....

Now something not well thought out was my HTML hyperlinking skillz - D'oh!

FOX

(Geesh, I set myself up on that one...)

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.

Doesn't work on MacOS (maybe through the X11 layer but even that was sketchy last I looked).

There is also:

5. Fox toolkit. I haven't used it much, but I am using an application that does. The app is kind of nice, so I assume the toolkit is at least passable.

Then what do you call this ?

It's not libre free, but beer free. And it's old as hell. But the poster was correct that there is a "non-commercial" version for windows that's freely available. Be warned though that Trolltech's definition of "non-commercial" is rather peculiar.

I'm wondering if they'll make this new non-comm 3.2 edition similarly available.

In the meantime I continue to happily use FOX.

... don't forget about FOX, which is written in C++ but has bindings for other programming languages as well.

Quick, KILL IT! It had a damn retarded licencing scheme anyway. Now if only KDE will die as well, the world would be a better place.

You'll find that wxWindows, the Fox Toolkit and GTK provide vastly superior -AND FREE- alternatives to QT.

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.

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.

Microsoft Visual C++ .NET Standard 2003 - $109. (About $95 if you shop around.)

Trolltech's QT library for one platform - $480.

Win32 is not that terrible, especially compared to X. Yes, it's not quite click-and-play, but with a little experience Win32 is easy to find your way around. The documentation and examples are second-to-none.

For Christ's sake - if the API isn't free nobody will write anything commercial for it. It's that fucking simple. Forcing someone into a choice of licence for their end-product because of a choice of GUI API is retardedly counterproductive.

How much of a fuss would people be making if Microsoft Visual C's EULA dictates how you use, licence and distribute programs generated by the compiler? The sooner someone re-writes KDE to not use QT the better.

PS: Check out The Fox Toolkit if you haven't seen it. Cross-platform and quite unencumbered.

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.

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.

It should also be noted that there is an addendum to the LGPL licence covering FOX that clarifies several issues. Unmodified versions of the FOX library can be statically linked to applications without causing licensing headaches, however, any changes to the library must be made available.

This may be attractive to developers who wish to simplify the distribution of their software by statically linking in FOX, but without putting their work under the LGPL as well.

The author has spent a lot of time looking at existing UI libraries and tried to learn from them before writing his own.

See the website for more info.

You will probably need some toolkits. Basic things like multi-threading are generally non-portable.

For a GUI, FOX or wxWindows may help. For threads, you may want to consider JThreads/C++, especially if you intend to add a Java front-end to a client-server style system. Alternatively, there are packages like pth or various MPI products to fit the bill. The MPI products have slightly higher overhead/configuration, but open the door to Beowulf applications.

Since you have a functional Makefile system, I would recommend keeping it unless you get some big bang (e.g. current system is very badly written) by ditching it. You can help by using GNU's make instead of the platform's native make. This will remove the portability issues from Makefiles and adds "if then else" constructs to better handle portability. Remember that a Makefile is a set of AI inference rules and not a procedural language (though many try to use it as such).

1. FOX supports Open GL out of the box. It contains custom objects for controlling Open GL structures, and comes with a couple of example programs (GLviewer and GLtest).
2. FOX is cross platform. It runs on Windows and just about every Unix out there that has an X server. It was recently even built on MacOS X.
3. FOX is a C++ toolkit, but has bindings to use it with scripting languages such as Python(FXPy) and Ruby(FXRuby).
4. FOX implements things that make building a gui a snap, such as a unique target/message system and automatic gui updating.
5. FOX is licenensed under the LGPL, with addendums that make it friendly for use in commercial applications on all platforms. Qt has different restrictions based on the platform you are running on.

1. FOX supports Open GL out of the box. It contains custom objects for controlling Open GL structures, and comes with a couple of example programs (GLviewer and GLtest).
2. FOX is cross platform. It runs on Windows and just about every Unix out there that has an X server. It was recently even built on MacOS X.
3. FOX is a C++ toolkit, but has bindings to use it with scripting languages such as Python(FXPy) and Ruby(FXRuby).
4. FOX implements things that make building a gui a snap, such as a unique target/message system and automatic gui updating.
5. FOX is licenensed under the LGPL, with addendums that make it friendly for use in commercial applications on all platforms. Qt has different restrictions based on the platform you are running on.

1. FOX supports Open GL out of the box. It contains custom objects for controlling Open GL structures, and comes with a couple of example programs (GLviewer and GLtest).
2. FOX is cross platform. It runs on Windows and just about every Unix out there that has an X server. It was recently even built on MacOS X.
3. FOX is a C++ toolkit, but has bindings to use it with scripting languages such as Python(FXPy) and Ruby(FXRuby).
4. FOX implements things that make building a gui a snap, such as a unique target/message system and automatic gui updating.
5. FOX is licenensed under the LGPL, with addendums that make it friendly for use in commercial applications on all platforms. Qt has different restrictions based on the platform you are running on.

Huh? How is Troll Tech evil? People wanted QT under the GPL, and lo and behold, they released it under the GPL. Seems like a nice bunch of folks to me.

Not quite. People really wanted it under the LGPL or BSD licenses, just like GTK+, FLTK, FOX, wxWindows, etc.

One of the problems (unless you follow Stallman's manifesto) is that although the Free version is free for open-source, their commercial licenses are structured so that if at any point in time your software project is touched by a free (free, non-commercial, acedemic, etc) version of Qt, you may never at any later time buy a commercial license and release your software commercially.

I'd like to do a quick shout-out to FOX.

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.

GTK:
GTK

QT:
QT
Excellent QT Tutorial

wxWindows:
wxWindows
wxPython

Mozilla:
Mozilla
Cross-platform implementation of COM
develop your UI's in an XML dialect called XUL

Others:
FLTK
Fox Toolkit

Side-by-side comparison of GUI Toolkits:
The GUI Toolkit and Framework Page

I needed this list for my own use. Maybe it will be of interest to you.

Both libraries you mentioned have their disadvantages (one isn't always free and isn't normal C++, the other doesn't exactly have the best windoze support), but IMHO, FLTK and FOX both seem to avoid these pitfalls. Both support windoze and unixy platforms with X. FOX is capable of doing more things, but FLTK is as fast a heck.

Have you looked into the FOX Toolkit? It's written in C++, is available on many UNIX and Windows platforms and has many bindings to other languages (Ruby, Python, Eiffel). You can find it here.