Slashdot Mirror

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.

The license it's under is acceptable (to me), and there are working large apps such as Audacity out there.

When I discovered all of this, I decided to look into the technology side of things. To throw more goodness at you, let me say reiterate that the toolkit looks native to your environment which is a big win. On top of that, it lets you do things which aren't lowest common denominator and exist in only one or more environments, such as toolbar icons in Windows.

I also like the class hierarchy. I had never done GUI programming before but everything came across rather clearly when I started reading the documentation.

Additional to all the "low level" GUI junk, it also contains some routines for networks and a portable wxString class which is a lot like stl::string with more methods added. I found myself using this almost immediately and I haven't looked back.

It's worth learning this stuff just to get away from MFC without taking the speed hit of learning Java/Swing and having to learn a whole new language and culture. There is even some boasting about how 'the Java honeymoon is over' on the page, stating that wxWindows is actually a more portable toolkit. :) ymmv.

There are both Python and Perl bindings for it. I haven't looked into either really, but at least the Python ones seem to be of high quality as a number of people on the mailing list are Python programmers.

Check it out before coming to a conclusion of what toolkit to use. It's worked for me.

wxWindows has a very rich feature set for building GUIs, plus many other benefits like portable classes for threads, networking, ipc, file i/o, serialization and much more. It is available for almost any kind of UNIX-like OS, for any Windows version, and some more platforms like VMS.

It is a shame that wxWindows doesn't yet get more attention.

wxWindows has a very rich feature set for building GUIs, plus many other benefits like portable classes for threads, networking, ipc, file i/o, serialization and much more. It is available for almost any kind of UNIX-like OS, for any Windows version, and some more platforms like VMS.

It is a shame that wxWindows doesn't yet get more attention.

wxWindows has a very rich feature set for building GUIs, plus many other benefits like portable classes for threads, networking, ipc, file i/o, serialization and much more. It is available for almost any kind of UNIX-like OS, for any Windows version, and some more platforms like VMS.

It is a shame that wxWindows doesn't yet get more attention.

If you want cross platform compatibilty with C++, then check out wxWindows. It has ports to Windows, MacOS (9 & X), UNIX + Motif, UNIX + GTK. It also has a very well developed Python binding -- so well developed that quite a few people want it adopted as the official Python GUI instead of TKinter.

You may also want to take a look at the wxWindows toolkit. It's a wrapper over what's available on a given platform (the native API in Win32, GTK in the Unix world, and there's a Mac port in progress, I believe). Good stuff, definitely, especially if what you want is C++ and portability. Note that your apps will look totally windowsy on win32, so your users will not be confused by their look.

Perhaps the Mozilla UI users could be imported by a tool that translates them to a plaform-specific format. It doesn't even have to do a perfect job, it just has to do a good enough job so that a developer can tweak the final results to look native on the target platform.

I think the API you're looking for is wxWindows. If you don't know what wxWindows is here is an explanation from the web site.

"What is wxWindows? wxWindows gives you a single, easy-to-use API for writing GUI applications on multiple platforms. Link with the appropriate library for your platform (Windows/Unix/Mac)and compiler (almost any popular C++ compiler), and your application will adopt the look and feel appropriate to that platform. On top of great GUI functionality, wxWindows gives you: online help, network programming, streams, clipboard and drag and drop, multithreading, image loading and saving in a variety of popular formats, database support, HTML viewing and printing, and much much more."

A wxWindows version wrapping Gecko would kick some serious butt and make a slim standards compliant browser available for all platforms. I'm not sure how easy this would be since I don't know a lot about Moz's guts but it would still be ripping.

Wxwindows is a set of cross platform GUI, DB, Networking, IO classes and sound. It runs under windows, Unix, Linux and many others. Look at http://www.wxwindows.org. I have used it in many different applications.

I was going to use Common C++ for something, but never got around to it.

here is a link: http://www.gnu.org/software/commonc++/CommonC++.ht ml

here is another: http://sourceforge.net/projects/cplusplus/

I have used wxWindows for simple cross-platform GUI stuff, and it works pretty well. wx is basically an abstract GUI toolkit, which wraps around various native toolkits like GTK, Windows, Mac, (even Motif).

It's pretty cool, though QT might have some more advanced features or be faster.

And it has the IMO great advantage over Qt in that it uses native widgets where possible. Qt draws its own widgets afaik.

Also the Qt-license is very restrictive. wxWindows has a license explicitly allowing the library to be used for commercial purposes.

wxWindows runs on Windows, MacOS (9 and X), GTK(+). Work is underway to implement a universal version of the library to be run on embedded platforms.

wxWindows is open-source. Patches and contributions are highly encouraged. Also the mailing-lists are very active with several of the main developers taking part in the discussion.

And it has the IMO great advantage over Qt in that it uses native widgets where possible. Qt draws its own widgets afaik.

Also the Qt-license is very restrictive. wxWindows has a license explicitly allowing the library to be used for commercial purposes.

wxWindows runs on Windows, MacOS (9 and X), GTK(+). Work is underway to implement a universal version of the library to be run on embedded platforms.

wxWindows is open-source. Patches and contributions are highly encouraged. Also the mailing-lists are very active with several of the main developers taking part in the discussion.

wxWindows has Networking support (socket I/O, ipc,... whatever you want), thread support, a rich feature set for GUIs and much more (unfortunately there is no support for Serial I/O).

You might even consider to drop QT in favor of wxWindows.

It is availabe for Windows, XWindows (GTK based), Mac and some other platforms. It is released under the LGPL.

I am rapidly becoming a wxWindows fan. I've spent the last week or so learning this toolkit and implementing something like Gamespy or The All Seeing Eye.

I admit this is the first GUI toolkit that I've used (for the desktop), but it seems to be very clear to use. I've got most of the standard functionality down now - events, windows/frames, window sizing, encapsulated string handling, etc, and I've only had to consult the mailing list for a single issue.

I'm using it with C++, but there are some rather popular bindings for Python called wxPython, as well as Perl and an assortment of other languages.

And the thing that gives me wood is that it looks native in each environment. GTK+ with themes under Linux, and Win32 GUI widgets under windows. And yes, it manages to do this without taking the lowest common denominator route: Sometime features like traybar iconifing under Win32 get plainly ignored under other OSes.

Learned a new API this year? (If you are a coder...) If you have not, you're due.

So what about wxWindows? It uses GTK on Linux and native widgets on Windows and Mac. It also has bindings for Python, Perl, and wxBasic, along with its native C++.

The wxWindows folks also have a Macintosh port that I believe also uses CARBON. From what I understand they are doing a great job. For python people, wxPython is just fantastic.

The wxWindows folks also have a Macintosh port that I believe also uses CARBON. From what I understand they are doing a great job. For python people, wxPython is just fantastic.

Grumble, Grumble... wxWindows.org is slashdotted. Just as I'm trying to convince others to try it.

While I understand your point, please don't try to group all open source authors into one big group. People write open source software for lots of different reasons.

There are lots tools available now that make it easy for open-source (and non open-source) developers to target both Windows _and_ Linux. My favorite is wxWindows, a cross-platform C++ toolkit that lets you write one program and recompile it for Windows, Linux/GTK (and any other Unix where you can get GTK to compile), Mac OS 9, Mac OS X, and OS/2 (!). Ports for embedded devices and the Linux framebuffer are under development. wxWindows is open-source (LGPL) of course. Unlike other similar toolkits, it uses native widgets, so their scrollbars are real Windows scrollbars on Windows, and real GTK scrollbars on Linux.

I've been working on Audacity using wxWindows for the past two years, and I've never regretted choosing to make it multi-platform. I really wanted to support MacOS, since that's what a lot of my friends and family use, but I also wanted to support Linux because that was my favorite environment, and of course by supporting Windows I could make my program available to the greatest number of people.

Many people have written to me and the other developers thanking us for giving them an open-source alternative on Windows. Some of them want to transition from Windows to Linux, and like that there will be a familiar audio software package available on both. Others prefer to stick with Windows because of special hardware that's not supported on Linux yet (i.e. digital sound cards) or because they're not hackers and actually don't mind using Windows.

Remember, to the non-programmer, one of the biggest advantages of open-source is that it's more likely to be around five years from now than a commercial or a shareware program. Programmers lose interest, companies lose interest, but when a project is open-source, somebody else can pick up where the original developer(s) left off. So I think that open-source on Windows makes a lot of sense, and I'd like to see a lot more of it.

It also makes porting to a new platform dead easy, you can simply use whatever graphical toolkit is already existent on that platfrom, and just write a compatibility layer.

This wheel has already been invented quite nicely by wxWindows. wxWindows is a common API for GUI programming that wraps itself around the native OS' widget set for Win32, GTK, Mac and Motif. In my experience wxWindows is far less resource hungry than what I've seen from XUL and with wxWindows you get the crossplatform goodness as well as your native OS' look and feel. wxWindows began in '92 and really started growing up about '95 so I'm not sure why the NS devs made the comment they did about not having a *nix Moz port were it not for XUL. wxWindows was around at that time. Perhaps wx doesn't do something that they needed or they just weren't aware of it's existence. Perhaps someone can elighten me.

And as for the responsiveness issue, personally I find no difference between native windows apps and mozilla and native linux apps and mozilla.

That must be some system you have there. Myself and everyone I know says the same thing: XUL is heavier than it ought to be.

Disclaimer: I am by no means a GPL fanatic. But nonetheless I think I can help to answer your question.

The biggest component of the GPL that RMS and the fans of GPL like is the same thing that made Microsoft incorrectly call it a "cancer". The GPL basically says that if you take the source code to a GPL program, make changes, and then distribute the binary, you are obligated to release the source to whomever you released the binary. In addition, you must release your new source under the GPL license, which gives the new users of the source the ability to distribute the code for free, even if you do not. This does NOT mean you can't sell it, or that you have to give away your program free at all. It just means that the first person you sell code to has the ability to give it away.

People misunderstand the GPL because they see companies like Red Hat and Mandrake giving away almost all of their products off of FTP sites. They could, if they chose, only sell their CDs. The CDs, though, must have the source code for every GPL program on them. If they don't, they need to make that source code publicly available (like on a web site). If someone were to buy these CDs though, they have every right to take the GPL programs off the CD and redistribute them, for whatever price they want.

Some of the other licenses you mentioned do not require that the source code be released when code is used in another program (called a "derivative" work). This appeals more to closed-source companies that want to take advantage of open-source products without releasing their source code. I'm not as familiar with the specifics of each license, but I'm fairly sure that the ability to keep source closed applies to BSD, Apache, and Artistic licenses.

One more note about the GPL. One can distribute closed source programs that use GPL code, but the code must be seperated. A good example of this might be a program like the GIMP (image editor) with proprietary plugins. You can ship both together, since the GIMP is self-contained, and your plugins can still be closed-source.

In addition to the GPL, the LGPL (Lesser General Public License) exists but is not recommended by RMS and the gang. It's used primarily for libraries and allows closed-source products to fully contain the LGPL code. Library designers use this because they want their programming code to be used with commercial products. An example of this is wxWindows, a cross-platform C++ GUI library.

So basically the main reason that some people like GPL programs is that it does somewhat "promote" open-source, by requiring programs that use it to remain open-source for everyone. It's among the most restrictive and wordy licenses, you are correct, but I'm not familiar with any open-source license being completely challenged in court.

Hope this helps.

The version of Qt that is licensed under the GPL is only the Unix/X11 portion. If you want the Windows version you have to pay for it.

From Trolltech's website (http://www.trolltech.com/developer/faq/free.html) :

The Free Edition is the Qt for Unix/X11 toolkit, licensed for development of free/Open Source software.

..and...

Qt/Windows is only available as Professional/Enterprise Edition, not as Free Edition.

Sure, you could port it, but what's the point? There's other freely available toolkits that you could port without pissing off the original developers... or you could just use one that's free and cross-platform already.

Question 2: Have you ever read GPL?

Question 3: How many times does GPL mention Linux (or GNU/Linux)?

Yes and none =P.

But there's a few points of yours that I think are debatable...

Mozilla is slow on an Athlon 900 machine with 384MB RAM, and this is at a 0.91 stage

I think either your machine must have some problems hardware-wise or your configuration must suck, because since Mozilla hit 0.9, it's been kicking the crap out of Netscape 4.x on any box I run it on, Windows or Linux... it runs great on my P2 266 with 128meg and Windows, on my K6 300 with 192meg on either Windows or Linux, and on my lowly P233mmx/64meg laptop on Linux. I happily ditched Communicator on everything the week 0.9 came out and haven't looked back...

Although GTK will be around for a while, QTs cross platform (X,Framebuffer,Win32,Quartz) capabilities make it very popular for anyone writing cross platform apps.

I think you're wrong here... as I understand it, Qt costs money if you want to use it on anything but Linux... people are likely just to hop on the native toolkit and re-do the front end.

Dunno why wxWindows doesn't get more attention... I was going to wrap that around Gecko and call it a cross-platform browser, until Mozilla stopped sucking.

AFAIK there's no GNOME application design guidelines similar to the Windows / MacOS / KDE ones

Yeah, well, with the latest Windows Media Player and Quicktime Players, Apple and MS have seemed to toss those docs in the incinerator anyway. Bitch about them before you bitch about the GNOME folks, most of them are doing this stuff for free... anyway, with a properly designed widget set and a few common dialogs, you shouldn't have to deal with design docs, the toolkit should just grant common UI principles as a side-effect of using it (which, in my experience, GNOME/GTK seems to do a pretty good job of).

Outside the Unix world (which is the world Linux needs to win over for the World Domination)

Er, why? If Linux succeeds at world domination, then there won't be any "outside the Unix world" anymore =).

Which is quite nice and platform-independent, find it at : http://www.wxpython.org ( it's based on the good olde wxWindows project)..

Ironically enough, we already have exactly this situation with respect to KDE and GNOME, except that the relationships are reversed. KDE and GNOME are both under GPL; however, Qt is only avaiable for Win32 (native) under a proprietary, commercial license; the GPL applies only to the X11 version of Qt. Meanwhile, GTK+ for Win32 is available under the GPL. A theoretical port of KDE to Windows (using Qt) is not possible at this point, but a theoretical port of GNOME to Windows (using GTK+) might be, depending on the quality of the port.

However, Qt is still able to grab more mindshare than GTK+ or wxWindows for Windows development, despite the fact that it's not free. This is because Qt has a reputation as superior (easier-to-use, more goodies) toolkit for Linux development than the C++ port of GTK+, and because Trolltech is pushing Qt for educational use.

Meanwhile, wxWindows (which is LGPL except that you can distribute derived works any way you like) has almost no mindshare (relatively speaking), even though it's an equivalent toolkit to Qt and is more portable than GTK or Qt.

End result: developers are more likely to sell their employers on Qt for Windows than on wxWindows or GTK+, even though it's a commercial package. Corolary: Trolltech makes some (IMO) well-deserved money.

ObJectBridge (GPL'd Java ODMG) needs volunteers.

I'm leading the development of Audacity, a cross-platform audio editor, for Linux, Windows, and MacOS (both 8/9 and X), using wxWindows. MacOS is a very important platform for me - I love Linux, and I've advertised Audacity on a number of Linux sites, but we still get more MacOS downloads than Linux (and far more Windows downloads than either of those). A year ago, when I started this project, Qt wasn't an option. I think I'd still choose wxWindows, but Qt is definitely looking better.

I'd also disagree with the statement that cross-platform apps have to target the LCD. In Audacity, all of the audio I/O code is written natively for each platform and supports some special features on each one. wxWindows fills in a lot of features that are missing on one or more platforms, for example providing a tree control and file dialog on Linux, but allowing you to use the native ones on Windows. Also, the Linux version of Audacity supports a lot of command-line options that just aren't available for Windows and MacOS, but the MacOS version lets you drag and drop files onto the application, for example.

Also, there are plenty of other cross-platform apps that target MacOS, both 9 and X. How about Mozilla?

wxWindows, along with its various bindings (wxPython, wxPerl, etc...) is actually a very good cross-platform system. It's an entirely abstracted system for developing GUI applications using an OS'es native framework.

I honestly love writing all the apps I need for a windows system under FreeBSD, and only rebooting for debugging. There are a huge number of Device Contexts, Managed Windows, all the widgets you'll ever need... wxWindows is a dream. I swear by wxPython for GUI building.

They are not the same. In fact, they are not even close. You might want to try something like wxWindows or zoolib. These toolkits "wrap" other toolkits for ease in portability.

Beware that when you wrap like this, you generally lose the extra features of each toolkit in order to remain portable.

Now I have to ask: why? Why would you want to do this? All this would do is change the look and feel of the application. This is not important. wxWindows and friends were made for crossplatform. Linux Qt -> Linux Gtk is not crossplatform, and isn't even worth talking about.

Do you really want to use the widgets of the opposite toolkit that badly? Why not just use Qt? It is much more complete and proven than its competitors and has all you need.
-Justin

When I use QT based environments, I feel like I am using a windows95 machine. The simple fact is that QT was designed to be used by windows converts, and was designed to work on a variety of platforms. It is not designed specifically for linux like gnome is, and so does not have a soul.

Many innovations found in GNOME are direct attempts to "ape" Microsoft, from compound documents to an implementation of Visual Basic for GNOME. Not that this is (all) bad; MS came up with some pretty good software design strategies, and GNOME is smart to follow the good ones.

That having been said, I use both KDE (on my home desktop) and GNOME (at work). They're basically the same as far as I can tell, from a UI point of view. There's a couple of minor differences (it's easier to use workspaces in GNOME; it's easier to set fonts in KDE; I like Konsole better; I like GTK's look-and-feel better), but they basically do the same things as each other, and both better than Windows. Which I think is the point.

GNOME is no longer designed specifically for Linux, as GNOME now must be working on Solaris and FreeBSD before it can be released.

If QT3 is to have any chance against gnome, it must become specific - it must become a pure linux environment.

Not bloody likely. In fact, one could argue that using a cross-platform environment such as Qt or wxWindows is closer to the hacker ethic of "solve the problem once." In fact, part of Python's success as a GUI building language is wxPython. I've also heard of cases where Qt/Python is used to build GUIs for software that's meant to run on Windows and UNIX, although that involves some expense...Qt is NOT GPL'd for Windows!!

OK, that's my two cents.

ObJectBridge (GPL'd Java ODMG) needs volunteers.

Seriously, right now there are only two major candidates for GUI building in Java: AWT and Swing. AWT is clunky and Swing produces the most incredibly bloated code you've ever seen. We need alternatives. Qt is one good alternative, but it has problems (read on). wxWindows is another alternative, not quite as extensive as Qt, but not with the same problems either.

Qt does have the most developed GUI tools I've seen short of those evil MFCs, in addition to some other cool stuff with sockets and XML. The problem is that your code is only portable to Win32 if you use Trolltech's commercial license. (I'm not slamming Trolltech's decision here...there is some delicious irony behind Trolltech contributing to an atmosphere where free software is easier to write for X than for Win32. I'm just saying that this violates Java's "write once run anywhere" philosophy.) Qt also won't work for Mac, at least not as far as I know. wxWindows has ports for Win32, GTK, Mac and Motif, and is distributed under the LGPL for all platforms. While you don't get all the goodies of Qt, you do retain all the flexibility of Java.

ObJectBridge (GPL'd Java ODMG) needs volunteers.

Well, my project is using OpenGL and OpenAL as the 3D library and audio library, respectively. For a 2D library, OpenPTC is always nice, but you can also try faking some 2D under OpenGL. That is the first step on getting your software cross-platform.

Input is not as problematic as you'd think and is relitively easy to port across platforms. Especially for joystick, mouse, and keys.

Right now I'm using GLUT to handle input and windowing for the actual game executable and wxWindows for the other tools. I'm tempted to switch entirely over to wxWindows, although it doesn't have an up-to-date Mac port. The problem with GLUT is that it isn't fast and isn't powerful, but it's great for getting things up and running quickly.

But as long as you just have to rewrite the program that popps up a window and sets up the OpenGL/OpenAL contexts, it's not as big as starting in DirectX and porting to GL. Just carefully architect the basic framework and there won't be any problems.

Also note that Mozilla's C++ Portability guide may prove to be useful. The goal is to think about portability from the beginning.

Don't forget the POVLAB development effort, which is beginning to pick up the pace. POVLAB has been around for years as a modeller for POV-Ray, and is just now being rewritten in C++ and made cross-platform with wxWindows.

See the POVLAB development site for details and to find out if you would like to help.

Gah! I got the link wrong. Should have been, www.wxWindows.org (wxwindows.com is a squatter's site).

---
James Crawford

That's fundamentally different from using GPL'ed software like gcc. If you start developing using gcc, your software doesn't automatically become GPL'ed and you can always switch to any of a number of other vendors.

With KDE/Qt, if you start developing for it, you are for practical purposes tied to the library and the company. If you ever want to make a commercial version of your software, you must license from that vendor and pay whatever they ask.

Choosing a complex library that falls under the GPL is a big step that you need to consider very carefully, since it closes off most of your options later on. My recommendation would be to stay away from KDE/Qt development, as well as from any library portions of Gnome/GTK that are covered by the GPL. Of course, there is no problem with using GPL'ed software as applications or tools.

It's also unnecessary to make that kind of commitment to a GPL'ed library when it comes to GUI libraries. wxWindows is a very complete C++ interface to several different toolkits, including Win32 and GTK, and if anybody cares to, it could be adapted to a Qt backend as well. And FLTK is a nice, simple cross-platform GUI library, good for many applications and much easier to deploy than either GTK or Qt.

A few I've seen (but never used myself, mind you) are wxWindows, V and FLTK.

wxWindows still has some rough spots, but then so do almost all other toolkits. If you don't need quite as much functionality and can do without native LAF, FLTK is also pretty good and much smaller.

Well - I've been programming with wxWindows (available at http://www.wxwindows.org) - And i think of it as a perfect replacement for MFC, if you think about serious cross-platform coding. The technology is still quite new, but there is virtually nothing that cannot be done with it at the moment.

For those wishing to develop cross-platform applications, wxWindows and wxPython have been around for a long time. Much better than trying to use GTK on Windows (wxWindows uses GTK on Linux but the MS common controls on Windows).

Have you tried WxWindows??

No, use wxWindows.

These portable libs are free libs too. So portability should be a strong argument for free software to convince mac geeks.

• Java 1.2. Technically, I think this is by far the best choice: easy to program, robust, extensive built-in APIs, etc. But you need to somehow get a Java 1.2 runtime onto your clients machines, and it still isn't efficient enough for number crunching (if that's part of your application).
• FLTK Small, cross-platform (Linux, Windows, ...), straightforward C++ GUI toolkit. You can link your applications statically and they are still small enough to distribute. It includes a GUI builder. Good OpenGL support. Has its on look-and-feel. Versions 1.x still lack drag-and-drop and dynamic widget layout support.
• wxWindows Very complete C++ GUI toolkit, cross platform between Linux, Windows, MacOS. Lots of widgets. Drag-and-drop support and dynamic layout. Uses platform look-and-feel. Very MFC-like, including the use of event tables for event routing. Steeper learning curve. GUI builder doesn't seem to be quite ready yet.
• Qt Commercial toolkit. Pretty good quality. But you need an expensive, per-developer license unless you do open source. I don't think it's worth the money or hassle compared to wxWindows.
• Willows Supoprts genuine Windows programming on Linux, in an open source environment. (I haven't looked much into how complete it is because I don't actually like genuine Windows programming :-)
• GTK There is a Windows port as well as C++ bindings. I don't think the Windows port is far enough along yet for deployment, though.
• Tcl/Tk The Tk toolkit comes with a scripting language you may not want, and, out of the box, it has a fairly limited widget set by modern standards. No drag-and-drop support. Multiple GUI builders. Great canvas class. Exceptionally easy to get started with, great for prototyping.
• Fox Toolkit In may ways like FLTK. Has drag-and-drop support, but cross platform is still a promise.

Altogether, if you can deploy Java 1.2 and it's efficient enough for your needs (for most applications, it is), I'd go with that. If you need something in C++, I'd stick with wxWindows, FLTK, or Tcl/Tk, depending on your specific needs and preferences. I think you may also want to reconsider whether you really want an IDE and GUI builder; I find writing GUIs by hand in toolkits that are set up for it is ultimately faster and easier.

vdkBuilder uses VDK and GTK, and there are win32 ports of both of those. The RAD IDE is similar to C++Builder, and is GPL'd.

VDK Builder

WX Windows

WX GTK

VDK Builder is maturing rapidly, is on source forge, and has a responsive developer mailling list.

It's fair to say that WX leans towards inheritance, while VDK leans toward composition. After that, it's up to you.

Beyond that, you might consider the following approach to development, which I have found to work quite well:

• Use Python. If you don't know the language, you can pick it up very quickly. It scales well to large projects. And since it's interactive, you save a lot of development time by skipping the compile and link steps.
• Use a cross-platform GUI library. wxWindows is a good one. There are others that have Python bindings -- see this list for a few.
• Once you get something working, you can optimize the hot spots, and then rewrite the performance critical parts in C, C++, or Java, all of which interface nicely with Python.

There are also cross-platform GUI environments like WxWindows, V, etc. See the MinGW FAQ for more information as well!

JimD

I would check out WxWindows if you haven't already. I have had a good bit of luck developing software under it. It allows you to write once, then re-compile for each platform. The resulting programs use graphics native to the system (gtk/motif for unixes), and so seem to fit nicely with the other applications on the system.

The distribution comes with a bunch of examples, so learning the classes isn't terribly difficult. The only downside I have seen is that I haven't found a nice IDE that uses it...But since I like emacs and vi, it doesn't much matter to me. =)

"I like both desktop environments, personally, but I don't like the separation like that. Is there anything we could do like that, other than have window manager/desktop environment/tk wars?"

0] help the GNOME/KDE/etc. teams make the environments' component tools all play nicely together, or...

1] help the wxWindows group improve/finish their ports.

You might also consider adding a copyleft term of some sort to the MIT (BSD without advert clause) license.

http://www.wxwindows.org

This actually redirects you to some faster url in the UK i think.