Slashdot Mirror

This is not a troll post!

2003 is the year of Mozilla's dead.... at least of Mozilla's current form.
The reason? AOL Communicator! I downloaded a beta version from www.datakill.com and I think, it has a bright future.
The reasons:

1. It seems that AOL is finally going to push Gecko to the masses (It's branded as AOL product, not Netscape)
2. AOL Communicator is split up in single applications (ac_mail.exe, ac_im.exe,...) - no ''all in one'' like Mozilla or Netscape.
3. (And that's my peronal favourite, 'cause that's what I prayed for since ages) AOL Communictor is written using wxWindows!
   Yes it's true. Finally they got rid of the sluggish XUL interface and still being multi-plattform.
   Phoenix (or whatever the future name will be) has helped, but Phoenix' interface is still somewhat slow compared to native Windows apps. Phoenix' GUI toolkit is also not fully aware of Visual Styles (skins for WinXP) - the menus look ''old school'', while the other apps have flat/skinned menus.
   AOL Communicator (thanks to wxWindows) uses native widgets everywhere.
   Quote from the included copyright-notice.txt:

   AOL Communicator uses the following libraries and modules:
   
   wxWindows libraries Copyright (c) 1998 Julian Smart, Robert
   Roebling. The wxWindows source code, available under the
   wxWindows Library License, Version 3, can be found at
   http://www.wxwindows.org.

While the beta version does only consist of an eMail app and the Instant Messenger (compatible with AIM and ICQ), AOL is also developing a browser component.
If you have a look into the file ''AOL Communicator\locale\cat\ac_help.mo'', you can find the following strings (BTW, ''Photon'' is the codename for the Communicator):

About Photon Browser

Photon Browser is not currently your default browser.
Would you like to make it your default browser?

Oh yes, I can't wait for the final release. I hope there will be an open source version of it (without the AOL specific stuff like AOL Mail or the Instant Messenger - called Mozilla 2.0 or something like that), to allow porting it to other platforms.

Oh, BTW... I did an experiment and it worked: You can move the mail folder from Mozilla's profile directory to AOL Communicator's profile directory. All your mails stay intact.

Honestly, I don't know why the Mozilla/Netscape developers waste their time in creating a new toolkit (the one that Phoenix uses), if they should better convince their bosses from AOL to open the source of the Communicator.

PS: Thanks for reading this post and (hopefully) not modding me down as ''Troll'' :)

What you want is wxWindows.

Dave

I've been looking into cross platform toolkits myself recently. A major issue where the Mac is concerned is that it's not just the look, it's the feel; there are lots of nuances that will annoy Mac users if you don't get them right.

The screenshot shows a menu bar at the top of the Othello window, which breaks the most obvious rule of all - Mac app windows don't have a menu bar on them, instead there's a single menu bar up the top which changes depending upon the focus.

There's some specific gotchas in the wxWindows wiki, here.

Don't get me wrong, the GTK port is an achievement and I'm sure it will be very useful to a lot of people. But we'll never get to the point where someone can produce a decent Mac app by taking their Unix sources and recompiling.

IMHO wxWindows is a better solution for cross-platform GUI apps. wxWindows supports MacOS (9 and X), Windows and various Unices. The nice thing is, that wxWindows uses the native widgets (GTK in Unix/Linux) for the rendering.

IMHO wxWindows is a better solution for cross-platform GUI apps. wxWindows supports MacOS (9 and X), Windows and various Unices. The nice thing is, that wxWindows uses the native widgets (GTK in Unix/Linux) for the rendering.

IMHO wxWindows is a better solution for cross-platform GUI apps. wxWindows supports MacOS (9 and X), Windows and various Unices. The nice thing is, that wxWindows uses the native widgets (GTK in Unix/Linux) for the rendering.

I have to disagree with you there. I've been using wxWindows for a while now. It's the best "CPW" I've used before, commercial or OSS (of which, it is the latter.) It uses native widget sets, not its own like FLTK, nor an emulated one like Qt. The only problem with it right now is that the MacOS and MacOS X ports aren't stable yet.

Take a look at wxWindows. It should fit your needs well.

While this is true for cross-platform applications which operate identically in each environment, those that assume the look and feel of the target system can greatly reduce the problem. I highly recommend wxWindows as a candidate API for your project as it automatically will make adjustments for you. The documentation is also quite good and there is a solid community of developers from which to learn. (I used it this last semester on an assignment - it's awesome.)

If you absolutely need your widgets to be a part of the 3D environment... you're going to have to keep looking.

Good luck!

wxWindows
It does exactly what you describe. It provides a single API, that, when linked with the appropriate platform's libs, creates the GUI using that platforms GUI.

I would recommend against using widget sets with OpenGL as a graphics layer unless you really need it: OpenGL is less than ideal for that purpose.

You might want to look into wxWindows It's a cross-platform GUI library that works using platforms' native GUIs, so that your app will take on the look of the platform you build it on. It supports OpenGL nicely, and has what is, in my opinion at least, a beautiful, intuitive OO C++ interface.

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, others coming shortly) 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.

"Excellent, stable and intuitive API. Very straightforward to learn and easy to port Java, X11 and Win32 code to."
"Thanks heaps for the best piece of software I've ever come across."
"wxWindows 2 has been an absolute dream."
"I've never had an easier porting experience."
"I never thought that cross-platform development could be so easy and simply cool."
"I have used wxWindows in the past very successfully on multiple projects, and think it's the bee's knees. Thanks for everything!"
"wxWindows is jaw dropping amazing. Community support from the mailing list is extraordinary. Are you sure this is free?"
"wxWindows is one of the most magnificent development projects in existence.."

All you need to know is wxWindows. The wxWindows library is quite similar in terms of design and functionality to Win32, and once you have ported to it, you can compile your application for Win32, Linux/X11, OS X, and several other platforms.

Robin Dunn, founder & maintainer of wxPython, an excellent Python-Wrapper around wxWindows, anounced in the wxpython-mailinglist that he was contracted by OSAF.

And who ever has enjoyed wxPython and the excellent support of Robin in the mailinglist knows: he get's things done. Or dunn.
So... if they don't succeed in travelling to space, at least teflon will be available.

Well, not quite. An NSAutoReleasePool does not allocate a large region of memory and suballocate objects out of that. What an NSAutoReleasePool does is make it possible to avoid explicitly sending the release message for temporary objects.

For example, from Foo() I allocate an NSObject with [[NSObject alloc] init] and pass that as an argument to Bar() which takes ownership of it. However, I must then ensure that I release the object because Bar() is following good coding practices and retains it, so thus with alloc+retain it's reference count is now 2. So instead what I do is Bar([[[NSObject alloc] init] autorelease]) which allocates NSOjbect (with ref count one) initializes it, marks it for autorelease, and passes sends it to Bar() which retains it (ref count 2) and keeps a pointer to it (presumably it is a method of a class). Coming out of bar the ref count is now 2, and perhaps Foo() proceeds to do some other things. Presumably at some point higher up the call stack (or perhaps at the beginning of Foo()) an NSAutoReleasePool was allocated. At the corresponding exit point (either at the end of Foo() or the end of whatever higher up function) [whateverpool release] will be called. When the pool is released, it will call release on any objects it has been asked to take ownership of. At this point one of two things it true. Either the class that Bar() belongs to has already released the object and thus its reference count went back down to one, and now is going to zero (so bye-bye), or the class that Bar() belongs to has not released the object and doing this release merely brings the refcount back to one such that when the other owner releases the object, its refconut will be zero and it will be freed.

Sorry if that was confusing, but in reality it's really not. It also really helps out when you are coding functions that allocate ObjectA, then allocate ObjectB, then ObjectC, and then find out something is wrong and need to "roll back" to the begining. If you allocate an NSAutoReleasePool at the beginning, and autorelease everything you alloc then if you error out you can free the release pool and everything gets released. If you don't you can simply retain what you need and then free the autorelease pool.

Anyway.. what this guy is REALLY talking about is NSZone. NSZone allocates a chunk of memory which other objects will be allocated from. The caveat being that while the memory will be freed, the objects will not be properly destroyed. Now this guy was talking about holding C strings and the like, so this is not a problem. However, had he been holding some C++ or objective-C objects this would be a problem as none of the destructors/deallocators would ever be called.

I think what it all boils down to is that programmers need to read more code than they write and that we should really be getting Masters of Fine Arts in Programming. I completely agreed with what Dr. Gabriel said. Programming is about as much like building a bridge as writing poetry is. That is to say.. not much.

Going along with that thought, I think it should be pointed out that /EVERYONE/ here who programs in any language (but specifically C programmers, and ESPECIALLY C++ coders) needs to learn Cocoa and Objective-C. I imagine some of the C++ whiny bitches are going to continue to whine about how much easier and better C++ is, but for those of us who actually prefer to wrangle pointers, Objective-C is where it's at. It's like C with JUST enough object orientation, but not overdone in some committee like C++. Also, one should note that I do like C++ quite a bit, but sometimes there's too many provided ways to do things. With Objective-C, the provided ways are almost all good. In addition, like C or C++ you are not limited to doing it that way, it's just that Objective-C only makes it easy to do good things.

Think for example of wxWindows vs. Microsoft MFC. wxWindows is suprisingly similar to Cocoa (although wxWindows does not do ref counting so making sure that one and only one class ever owns an object can be problematic at times). MFC, on the other hand, is rather a bear to work with as Microsoft has written it such that an MFC programmer /can/ do things multiple ways, none of which work very well. Obviously this is a generalization, but I think the average MFC programmer will understand where I'm coming from here. That is, again, except for the whiny C++ and MFC bitches who can't figure pointers out. Go home!

The wxEiffel GUI library provides a comprehensive interface to the wxWindows GUI. Database interfaces to Firebird, sqlite, berkeley db, mysql, postgres.

There are even libraries for Regular Expressions and for those who like the perl way of doing things - see Perlish.

The 0.5 release announcement in comp.os.linux.announce gives more details. The ELJ project is undertaking the necessary work to move from SmallEiffel to SmartEiffel.

There are many other open source Eiffel projects:

• GOBO - lex, yacc, xml, data structures, date/time libraries and
• eposix which aims to provide a a 100% complete Eiffel binding to Standard C and POSIX.

Eiffel has come a long way over the years. Misconceptions still abound. You can now develop multiplatform applications using open source Eiffel tools and libraries. There are small hurdles to jump as there are with anything. Give it a try and become involved if there is something about Eiffel which you find appealing.

QT costs money for other platforms. GTK is free everywhere.

Qt works properly on other platforms. GTK+ is broken everywhere except X11 (doesn't work, or is very buggy, doesn't look like a native app).

If you are going to recommend an alternative to Qt for cross-platform GUI development, you do yourself a great disservice by suggesting GTK+. Try wxWindows instead - a much better alternative than GTK+, although it does still have issues.

If companies and individuals go out of business because of blocking ads, that will lead to fewer, higher-quality companies like google that can come up with ways to make ads *work*, or sites that actually .. wait for it .. CHARGE MONEY.

So you think that useful sites like http://www.libsdl.org/ or http://www.wxwindows.org/ should start charging, or disappear?

No thanks, I'd rather they used a few ads. For what I get in exchange from sites like that, its nothing.

It is sad, especially since these days it is not all that difficult to be cross-platform for most types of apps, but most software developers are too stupid/lazy/ignorant/uninformed/apathetic to bother to learn how. And the irony is that these days it is easier than ever to be cross-platform. For 3D, the OpenGL API has never enjoyed such broad support, from Macs to PCs to Linux. And cross-platform libs like SDL can help you forget about most of the rest of the crap too.

For "normal" applications, I recently tried out wxWindows, and I really enjoy using it. Even if you only care about the Win32 platform, I find that using wxWindows anyway is STILL much faster (development time) than using native Win32 or MFC, because the the latter two really suck as APIs. wxWindows doesn't automatically make your app cross-platform, but it can easily take you 90% of the way, especially since they have abstractions for tonnes of non-UI things as well, like files, sockets, threads, timers, and even have other cool lib functions like regular expression parsers.

With Mac and Linux both now being UNIX relatives, many other barriers to being cross-platform are disappearing too.

But people should code with an open, standard, portable GUI wrapper instead of writing directly to ANY API.

Case in point: http://www.wxwindows.org. Simply write in the wxwindows wrapper, then simply compile it for something like Pico instead.

However, X is so entrenched that it will take years, if ever, for pico to dethrone it. Until then, just use wrappers to keep the code portable.

You get all that with wx and it's GPL.

One thing I hate is the "skinning" of everything, particularly media players. It was popular for mainstream kids software, and it worked okay there; but for everything else, the standard GUI (preferrably written with something nice like WxWindows) should be the only thing that is used. If I see something with colorful, bubbly bitmaps on the gui, I probably won't use it.

What is intuitive to us is what is standard -- adding new buttons with new pictures, new dials, and other things in a single instance interface only confuses everyone. Even if some of the properties are inefficient, regular GUI standards are the way to go.

www.wxwindows.org You should check out wxWindows, its a pretty much fully functional opensource package that lets you compile your code on Linux / BSD / *nix / Mac / Mac OS X / Win. It's one hell of a good package I have used it to create many different applications, and the documentation is really helpful as well. Cheers

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).

http://www.wxwindows.org/ - mature crossplatform C++ library, and not only for GUI, either.

I don't know what you need, but WxWindows and GCC cross-compiling (see mingw32 faq, for instance) might be what you need?

WxWindows also have good bindings to python and perl etc. for more rapid crossplatform development.

I assume that most of your problems are in the GUI end of the equation - why not break the application into two bits? Put the numerical stuff on a grunty 8 way box, and cook up the UI with whatever language best suits the available (and hireable) skills and platform?

Communication between the two is probably best through SOAP, although to be honest I've not looked into this area for a long time. The GUI can still be built from Java (I believe Java has some reasonably fast OpenGL wrappers now), or look into wxWindows using the existing C++ resource.

Dave

I would not be scared of learning Objective-C--it is a very simple language and easy to learn, and its object model is very convenient. But in other ways, Cocoa using Objective-C is a somewhat outdated programming environment: the GUI design tools were great in the 1980's, but they are pretty dated by today's standards. And resource management in Objective-C and Cocoa is a lot more work and a lot more error prone than in Java or C++. On the plus side, Cocoa is what Apple really wants you to use, and that's where they seem to be putting a lot of their efforts.

Cocoa using Java is probably in a certain sense "the best" programming environment for the Mac: it's modern, easy to develop in, and mostly safe. It's also pretty well supported. But it retains many of the warts of the Cocoa APIs and, as you observed, is not all that well documented.

With either Cocoa-based solution, you also have to ask yourself whether you believe that Cocoa has a future and whether it's worth learning it. I don't see much of a future for Cocoa, at least in its current form. Apple has made no moves to standardize it or open it up, so it is Mac only. Even if Apple pushed for more widespread adoption, they'd have to make big changes to make it palatable to industry, like adding precise garbage collection and better error checking to Objective-C, with the resulting changes to the APIs. An example of work in that direction can be found here (yes, that is "gerbil.org", but it's a site about programming, really).

Swing Java is probably the least hassle: it's well documented, it works very well on Macintosh, and you still get the native look-and-feel. It has modern resource management and modern layout management. Knowing Swing is useful and helps you on other platforms as well. And its object system is fairly similar to that of Objective-C. But some of the more advanced features have been buggy in the past (e.g., audio input, etc.). You can, however, combine Swing and Cocoa APIs, using Swing for the GUI and dropping down into native APIs only when Sun's cross-platform APIs fail you.

If you use one of the Java-based solutions but find the Java type system too constraining, you can use Jython, a Java-based implementation of Python. You can choose to run it interactively or compiled. It's great for exploring the Cocoa APIs (or the Swing APIs).

Another choice you may want to consider is wxWindows. Recent versions run very well on MacOSX and look native. If you want to see an example of an application written in wxWindows, take a look at Audacity.

I tried all these different approaches, and I ended up doing most of my Mac programming in Java/Swing and wxWindows.

There is already a port of wxWindows to the Mac, and quite sure to OSX soon enough.

...I'd also suggest taking a look at wxWindows. They're open source, the results look very mac native (they have screenshots), and it seems to be very portable....having libraries for windows, most *nux (using GTK, Xt, or Motif), and macs, and maybe a few others. Oh, and it's c++ for those with an objective-c phobia, like me :)

I honestly don't know why more isn't done with this framework outside of those crazy python people. It looks good, and is completely free (both as in beer and speech), unlike Qt (not trolling, just stating a fact!)

wxWindows is a cross-platform GUI toolkit which emulates the native look n feel of the platform it is running on. It's written in C/C++ and runs on Windows, Mac, and Linux. The url is http://www.wxwindows.org. It gives you the cross-platform benefits of Java, as well as access to the underlying BSD layer.

I have started using wxPython (Python bindings for wxWindows) as my primary development platform, and am quite happy with it. It enables me to develop my application on OS X, even though my primary target audience is using Windows. =)

On a side note, I've used wxWindows in Python and I must say I was definitely impressed how one wxWindows Python script can display identical windows on Mac OS, Linux, and Win32s. We need more of this cross-platform compatibility.

"Apple should open up the interface for a bit more customization, expose the API's and maybe work in some kind of X11/Aqua hybrid feature so X11 applications can run on Aqua without extensive modification to the Aqua look and feel."

You should definitely have a look at wxWindows. A C++ environment that makes calls to the X11 architecture on almost every platform out there. Also, we all know about Qt, so I'm not sure about your statement. These development environments couldn't have been implemented without at least some documentation of the API...

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.

Exactly. Adboce, for instance, will keep shipping their ugly Motif-baed Reader, in the absence of a standard.

In the case of adobe, it's all about 'history'. once upon a time they bought some kit which allowed them to develop apps simultaneously for Win16/Unix. That kit used Motif. ATM, company which made the kit, is probably dead. If They would switch over to something like wxWindows, they could use any kit on unix side. AFAIK adobe apps always come statically compiled anyways.

I can pretty much guarantee that you will be more productive and have your product out the door faster, event if you need to ramp up on both Python and wxWindows.

Lots more information at:

• Python web site
• wxWindows web site
• wxPython web site

"a plethora of proprietary libraries " ?

Open source crossplatform GUI (and threads and some other things) Library for C++:

wxWindows

That's entirely missing the point. It's as if asked "I wish perl had a unified database handling module", somebody had answered: "well, you've got the oracle module, the sybase module and the mysql module. They don't have the same API, but they all allow you to connect to the database you're using.".

You haven't checked out Wx. It's a Perl module for using wxWindows:

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, others coming shortly) 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.

See the wxWindows supported platforms.

That's entirely missing the point. It's as if asked "I wish perl had a unified database handling module", somebody had answered: "well, you've got the oracle module, the sybase module and the mysql module. They don't have the same API, but they all allow you to connect to the database you're using.".

You haven't checked out Wx. It's a Perl module for using wxWindows:

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, others coming shortly) 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.

See the wxWindows supported platforms.

>Simple - it's largely because they're cross platform.

You hit it right on the money. It's extremely difficult to write complicated programs so that they're efficient on multiple platforms. Differences in the windowing system are only part of it - another big part is how the different OS's deal with multiple threads, file I/O, etc. - what's very fast and efficient on one platform might be quite slow on another.

If anyone's thinking of starting development on a cross-platform program now, you should seriously look at wxWindows - it abstracts the GUI, file I/O, networking, and many other things and runs on Windows, Unix/GTK, and all MacOS's...and unlike Mozilla and Qt, it uses native widgets on all platforms! Unfortunately wxWindows wasn't mature and stable enough a few years ago when Mozilla was getting started, or even longer ago when StarOffice was getting started, so they had to invent the wheel themselves.

take a look at WxWindows. It's also been ported to work with other languages such as Perl and Python. IMHO it's prettier-looking than Tk and nicer-feeling to code in (more OO).

How about a wxWindows book? There are a bunch of little tutorials on the web, but no dead tree tutorial book or API reference. There are a bunch of people interested in contributing here.

I want a comphresive WxWindows book styled like Harbison and Steele's 'C: A Reference Manual'. It might be hard to picture but stick with it a moment.

I want an Introduction to Computers book that works from each of the widgets and keystroke combinations to teach newbies how to use their computers effectively by focusing on teaching from the building blocks of applications on up.

I want a book covering libtiff though I am uncertain how I would want it layed out or if anyone else would care.

I want a book modeled after OpenBSD styled code reviews for security, technique, and coding practices.

I want someone to reprint all three of Marc Behm's stories in one volume. Ok, so that one wasn't a computer book. Sue me.

Now if you pay me an advance, I'd even start writing some of them...

Most people probably don't even know what the plusses of wxWindows are. It might be interesting to title the book "Writing cross platform GUI apps with WxWindows". Have it be very obvious to the user that the apps look native in their environments, and that it's a very sane way of writing C++ GUI code.

Oh yeah, the URL is here

So what is Microsoft aiming for? Probably two things:

- Kill Java. They need to kill it before it becomes too wide-spread. They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here] and C#'s advanced features like better encapsulation (you don't need to call set() and get() methods, you can map them to the = operator, for example).

- "Write once, run on Microsoft". In order to run .NET apps on another platform you would have to virtually re-implement (or substitute) the entire Win32 API, which will probably be modified at an ever-increasing pace. No company can keep up -- only open source may be able to do that, but Microsoft's opinion might be that open source is no real threat for the platforms where they want to deploy .NET. (After all, even the average Slashdotter seems to think that Linux will never be ready for the desktop -- quite idiotic, IMHO, but the more people believe that, the better.)

Insofar Ximian's Mono project may be a good thing as it offers a migration path where previously none existed (from Windows to Linux), even if .NET apps don't run properly on Mono (think about all the GUI stuff that can go wrong, for example). Besides, Java has never really been a mature technology IMHO and it's about time to replace it with something better, even if superficially less cross-platform.

Now the advantages of having a modular architecture become clear. Mono cannot break Linux, it cannot break X, it can probably not even break GNOME. There are more alternatives than you can throw a kernel image at if something goes wrong. Let's just wait and see what the Mono guys come up with. The only people who should worry about this are Sun and their followers. And maybe RMS.

license

"The wxWindows 2 licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWindows, and also those producing proprietary software."

See Mahogany for a fairly large cross platform project implemented with wxWindows.

You want corporate stable now? Try WxWindows. Granted the IDE choices are limited more or less to WxDesigner and it's not cross platform GTK but it's close.

I'd recommend this over the BSD license because it removes the opportinity for certain crooked companies to "embrace and extend" your CODEC. You still retain control of the CODEC design.

Another possibility you may want to explore, is having two licenses: GPL for free download, and closed-source proprietary for closed-source, commercial projects. Trolltech does this and they're apparently quite successful.

Just my two cents.

FLTK is very lightweight and easy to use. It is used extensively on handheld Linux devices. FLTK1 lacks some functionality that you may need, but FLTK2 is shaping up to be quite complete.

Also, Qt is not the only game in town for commercial toolkits. If you want something commercial, look around. In the past, other commercial toolkits had much better tool support than Qt.