Related
I am looking for tools and techniques for prototyping (virtual prototyping), simulation, and testing of deeply embedded C code on desktop Windows, including building realistic embedded front panels consisting of buttons, LEDs, and LCD displays (both segmented and graphic).
I'm specifically interested in a possibly low-level approach, using pure C code and raw Win32 API rather than MFC, .NET/C#, vxWidgets or Qt. I'd also like to use free development tools, such as Visual C++ Express with Platform SDK and ResEdit for editing resources.
I'm looking for code examples to render graphic LCDs (from monochrome to 24-bit color) with efficient pixel-level interface, multi-segment LCDs, and owner-drawn buttons that respond both to "depressed" and "released" events.
I am surprised that my original question triggered so many misunderstandings and adverse comments. The strategy of developing deeply embedded C code on one machine (e.g., a PC) and running it on another (the embedded microcontroller) is called "dual targeting" and is really quite common. For example, developing and testing deeply embedded code on the PC is the cornerstone of the recent book "Test-Driven Development for Embedded C" by James Grenning.
Avoiding Target Hardware Bottleneck with Dual Targeting
Please note that dual targeting does not mean that the embedded device has anything to do with the PC. Neither it means that the simulation must be cycle-exact with the embedded target CPU.
Dual targeting simply means that from day one, your embedded code (typically in C) is designed to run on at least two platforms: the final target hardware and your PC. All you really need for this is two C compilers: one for the PC and another for the embedded device.
However, the dual targeting strategy does require a specific way of designing the embedded software such that any target hardware dependencies are handled through a well-defined interface often called the Board Support Package (BSP). This interface has at least two implementations: one for the actual target and one for the PC, for example running Windows. With such interface in place, the bulk of the embedded code can remain completely unaware which BSP implementation it is linked to and so it can be developed quickly on the PC, but can also run on the target hardware without any changes.
While some embedded programmers can view dual targeting as a self-inflicted burden, the more experienced developers generally agree that paying attention to the boundaries between software and hardware is actually beneficial, because it results in more modular, more portable, and more maintainable software with much longer useful lifetime. The investment in dual targeting has also an immediate payback in the vastly accelerated compile-run-debug cycle, which is much faster and more productive on the powerful PC compared to much slower, recourse-constrained deeply embedded target with limited visibility into the running code.
Front Panel Win32 GUI Toolkit
When developing embedded code for devices with non-trivial user interfaces, one often runs into the problem of representing the embedded front panels as GUI elements on the PC. The problem is so common, that I'm really surprised that nobody here could recommend an existing library or an open source project, which would provide a simple C-only interface to the basic elements, such as LCDs, buttons, and LEDs. This is really not that complicated, yet it seems that every embedded developer has to re-invent this wheel over and over again.
So, to help embedded developers interested in prototyping embedded devices on Windows, I have created a "Front Panel Win32 GUI Toolkit" and have posted it online under the GPL open source license (see http://www.state-machine.com/win32). This toolkit relies only on the raw Win32 API in C and currently provides the following elements:
Dot-matrix display for an efficient, pixel-addressable displays such as graphical LCDs, OLEDs, etc. with up to 24-bit color
Segment display for segmented display such as segment LCDs, and segment LEDs with generic, custom bitmaps for the segments.
Owner-drawn buttons with custom “depressed” and “released” bitmaps and capable of generating separate events when depressed and when released.
The toolkit comes with an example and an App Note (see http://www.state-machine.com/win32/AN_Win32-GUI.pdf), showing how to handle input from the owner-drawn buttons, regular buttons, keyboard, and the mouse. You can also view an animated demo at http://www.state-machine.com/win32/front_panel.html.
Regarding the size and complexity of the "Front Panel Win32 GUI Toolkit", the implementation of the aforementioned GUI elements takes only about 250 lines of C. The example with all sources of input and a lot of comments amounts to some 300 lines of C. The toolkit has been tested with the free Visual C++ Express 2010 (with the Express Edition Platform SDK) and the free ResEdit resource editor.
Enjoy!
The appliances you mention in your comment clarification to the question will never be using a windows PC, so low level windows programming is not a requirement in that case. In fact, I'd say its undesirable. Prototyping is about speed. It's about how fast you can put something together to show potential investors or upper management or some other decision maker.
You wouldn't want to spend the extra time with low level C and Win32 api until the project requirements were flushed out enough that you knew that was an absolute requirement for the final project deliverables (perhaps a server/PC monitoring tool?). Until then you want speed of development. Lucky for you the industry has tools for rapid prototyping and development of hardware like you describe.
My Preference for Prototyping with Embedded Development
As for my opinion as a developer, I like the .net microframework (.netmf) simply because I'm already a Microsoft .Net developer and can transfer a lot of my existing skills. Therefor I prototype with a FEZ microcontroller using C# under Visual C# Express 2010 (free as you required). Its fast, easy and you are working on the core of your project in minutes.
If your experience as a developer is different, you may look for a micro controller which is programmed using BASIC, Java or some other language to help with the speed of development by reusing your core skill set.
Addressing your Question Bounty Comments
Astonishingly large portions of the embedded software can be developed
on the desktop computer as opposed on the deeply embedded target. This
avoidance of the "target system bottleneck" can potentially improve
productivity by an order of magnitude, if done right. However, to
develop embedded software on the desktop, one needs to simulate the UI
components, such as displays (both segmented and increasingly
graphical), LEDs, knobs, and buttons. I'm looking for such UI
components written in plain Win32 API in C for easy integration with
embedded code to be developed and tested on the desktop Windows.
I did embedded development full time professionally for well over 4 years as well as many years surrounding that part time. While what you said above is somewhat true, it will not save you time or money which is why everyone is confused about the motivation for this strategy. We spent years trying to put out a windows emulator for this company's hardware devices that would theoretically save time for prototyping. It was always a pain and we spent many more hours of work trying to emulate the experience than if we just went straight from sketched UI drawing specs to real development. The emulator lagged behind hardware development and often wouldn't support the latest features until 6 months or more after the hardware was released. It was a lot of extra work for very little value.
You will spend more of your time developing non-reusable win32 platform code and hardware emulation components than actually writing the code for the core project itself. This only ever makes sense for hardware vendors who provide this emulator as a 'value add' tool to potential 3rd party developers, but it does not make sense for prototyping new hardware designs.
Modern development environments like Visual C# Express 2010 with a FEZ microcontroller can compile, push the project output to the microcontroller, and then begin debugging just as fast or faster than you could compile and run a low level windows app in C emulating LCDs or LEDs or switches, etc... So your comment, "improve productivity by an order of magnitude", is simply no longer true with modern tools. (It may have been prior to the last 10 years or so.)
If you really, truly just want to simulate the embedded hardware visually on a PC use something like adobe flash to mock up a UI. But don't duplicate code by coding for windows when the final device you are prototyping won't be running windows (maybe it will be, but you didn't say that). Use the fastest most reliable prototyping tools available today, which is unequivocally not low level C and win32 api!
Maybe use StackExchange for Electronics?
Because this is a development oriented site, discussion about the merits of specific embedded hardware isn't really relevant. If you decide to refocus on using microcontroller electronics for prototyping (Arduino, FEZ, Propeller, Basic Stamp, Pololu, etc) you might ask for electronics hardware advice on stackexchange for electronics. I will say that most of those platforms are designed to facilitate the prototyping of LCDs, LEDs, buttons and interfaces as you outlined. You can usually assemble a few pre-built modules in a matter of minutes and be ready to start coding your project. Huge time savings can be had here.
You are asking for too much you need to take a look # proteus.
http://www.labcenter.com/products/vsm_overview.cfm
As Mahmoud said, you may find your code solution with prototyping example in proteus professional. It is one of popular software for prototyping, simulation and coding, you can download proteus professional for free and check their manual.
Best of luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
If you open the page "Graphics and Gaming (Windows)" on microsoft.com
the last category is described as
Legacy Graphics: Technologies that are obsolete and should not be used in new
applications.
This category includes (among others) the following APIs:
GDI
GDI+
OpenGL
What's your opinion? If i want to roll out a new software today it must support Windows XP (still about 50% of all installed systems). Direct2D requires Windows 7/Vista. What else should be used?
I suspect that Microsoft's definition of "legacy" has little to do with what any sensible developer should do, and is instead based on some Grand Rewrite of the Windows API.
Starting at around Windows Vista, Microsoft has been redesigning many of their API's. We now have MMDevAPI as the One True Sound API, WIC is the One True Image File API, etc. From what I've seen/heard, these new API's are much better than the old ones, and the "legacy" systems all work based on the new ones. In Windows Vista and later, DirectSound is entirely based on MMDevAPI, and components that need to read image files do it via WIC.
Windows 8 will have an ARM version, which it appears will support only a subset of the current Windows API. We won't know for sure until Windows on ARM is released, but, based on the libraries included for the ARM platform in Visual Studio 11 (ref: http://www.winehq.org/pipermail/wine-devel/2012-March/094559.html), it's looking like GDI+ and OpenGL will not be available. GDI is available for linking, but that doesn't necessarily mean it's intact.
This new API's from Vista and later roughly correspond to the libraries in the VS11 ARM target. I'm guessing that anything on that list is there because it's either the latest and greatest way to do what it does, or it's too technically important to discard (for now). Thus, "legacy" is anything that's not the latest and greatest way to do at least one thing.
I'm not sure what is the One True Graphics API. Already we have Direct2D, Direct3D, DirectComposition (which, by the way, is not available until Windows 8), DirectWrite, and DXGI. DXGI seems the closest, but I don't have a deep enough understanding of the graphics API's to say. I suspect gdi32 is technically very difficult to get rid of. How are non-legacy applications meant to find out when part of a window has been revealed and therefore must be painted, without using WM_PAINT, which involves an HDC, and how could a library do that on an application's behalf without replacing its window procedure? How are we meant to make semi-transparent windows without using UpdateLayeredWindow, which takes an HDC? How much does user32 depend on gdi32, and can they really be separated?
From a technical standpoint, Windows can easily get rid of GDI+ and OpenGL, but I'm not convinced that getting rid of OpenGL will work out, even on a new platform that doesn't promise any backward compatibility. It seems too valuable to developers. GDI+ isn't so important, but it's very easy for a third party to provide a replacement.
I would say use any of the API's you listed, and the worst that's likely to happen is that you have to rewrite your UI if you want to port your app to metro or Windows on ARM. GDI is a fine choice if your needs are simple and you'll be coding directly for the Windows API. There aren't many situations where I'd recommend GDI+ over OpenGL as a drawing API. GDI+ is slow, limited, and only available on Windows. The GDI+ API is simpler because it's 2D, so maybe it's worthwhile if you need to do something very simple but with anti-aliasing.
OpenGL isn't deprecated, Microsoft's implementation of it is. Microsoft's implementation is stuck at version 1.1, which is old. The current version of the standard is past version 4. If you want to use OpenGL, it is fully supported by NVidia, ATI, and Intel graphics cards on the Windows desktop, but not in Metro Windows Modern UI apps, is an industry standard, and also works on Mac and Linux. If you need a software fallback implementation, Mesa has got you covered, and it even works on DOS. (Since Mesa can render into memory buffers, there's no reason it won't work in Modern UI apps, but you probably don't want to do this because it can be slow.) One thing of note is that WGL, the API for accessing OpenGL functionality on the Windows desktop, depends on GDI (which is deprecated) so you probably want to use something like FreeGLUT or SDL instead if you want to future-proof your application, which also nets you platform independence.
OpenGL ES is a variant of OpenGL which works on Android and Apple iOS. It is also accessible in JavaScript via WebGL, which Internet Explorer 11 will support (and pretty much every other browser already does.) ANGLE provides a hardware-accelerated implementation of GLES for Windows which piggybacks off of DirectX (version 9 or 11) and thus should work in Modern UI apps as well. Once again, Mesa's got the software implementation covered.
TL;DR: OpenGL is not only not deprecated, it is cross-platform, standard, and has tremendous momentum in the industry. GDI and GDI+, well, not so much.
If you want to support Windows XP, then you're supporting a "legacy" operating system, and as such, using a "legacy" graphics framework is the logical choice.
Even if that weren't true, let's just say that I disagree with the advice given by the linked MSDN article. The "legacy" status here has more to do with which technology the Windows team thinks is cool this week. The status designation of "obsolete" just means that the group responsible is no longer accepting or fulfilling bug reports (except for critical security issues). Not too big of a deal—these technologies have been around long enough that they're fairly feature-complete and stable.
GDI isn't going anywhere, so if you need something rock-solid that is guaranteed to be supported anywhere and everywhere, that's what I would go with.
If you need a bit more 2D capabilities than GDI offers (e.g., alpha channel transparency), then you could consider using GDI+. It's nearly an order of magnitude slower than GDI, but that's not too big of an issue on modern machines with more power than you could ever want. This, too, is going to be supported for a very long time to come.
That said, if I were writing a new app today, I probably wouldn't bother with OpenGL. There's very little that it offers in benefits over Direct2D and DirectWrite, which are both what Microsoft is pushing as the replacements for GDI/GDI+. There might be some benefit to using OpenGL if you absolutely must target Windows XP because as far as I can tell, Direct2D/DirectWrite are only supported on Vista and later, but that's because (as I mentioned originally), Windows XP falls squarely into the "legacy" or "obsolete" camp itself. Alternatively, if you already know OpenGL well and don't have time or the desire to learn Direct2D/DirectWrite, then it might make sense to continue using it in a new application.
Don't let the verbiage of the MSDN article scare you. Choose whatever technology makes the most sense for your specific use case given all of the available information. By the time any of these technologies go away completely, you'll have to re-write the app completely for a dozen other reasons.
Edit: Hmm, it looks like DirectWrite has also been declared (by some people at least) "obsolete" as well, having been replaced by Direct2D. That's funny, it hasn't even been around long enough for me to bother learning it. I guess that only goes to support my earlier argument that "obsolete" simply designates that a particular technology is not what is currently considered to be in vogue by the Microsoft devs.
I'm personally waiting until all the bugs get worked out of this stuff (and we decide on a semi-permanent standard) before I make the switch for any of my applications. Everything I've seen written in DirectDraw or Direct2D has had serious rendering bugs and is a performance nightmare, even on reasonably competent machines. Sure, they only show up sometimes, under the right conditions, but that's too much for me. And I swear, the blurry text shows up all the time. Not being able to read what's on screen is a deal-killer for me and my users. GDI doesn't have this problem, and it's not going anywhere.
Are GDI, GDI+ and OpenGL really obsolete/deprecated?
This is not true for OpenGL. OpenGL 4 allows you to use geometry shaders on winxp. Which isn't possible with DirectX (DirectX 10 and up isn't supported on WInXP). It is also one of the only cross-platform 3D APIs out there.
From a business point of view MS is interested in promoting DirectX since it is their technology that lock Developer into windows platform (they're also interested in making DirectX more attractive for developer, but that's another story). So it makes sense that they aren't keen on promoting OpenGL.
What else should be used?
I'd advise to stop using platform-specific tecnologies when possible. Grab cross-platform framework and use it for your application. There's Qt, GTK, wxWidgets and other toolkits for GUI apps, and SDL(and alternatives) for games. This way when platform developer decide to make ridiculous decision (like not supporting DX10 on WinXP) you dislike, you'll be able to move elsewhere with minimum development cost. Qt is also ridiculously powerful and at the moment I have no reason to use something else for GUI development. Still, situation can change in the future.
In short, while developing for certain platform you should keep in mind that platform developer might have their goals that are not compatible with your wishes. Discovering that your source has become locked into single platform isn't very pleasant experience. Your own goals should be the first priority, and if os developer tries to make you use certain technology you don't like, then you shouldn't support that technology.
Because OpenGL is a standard, it should be considered equally deprecated as C or C++ so it is a matter of time before the entire Windows API -- which today has become a compile once run on every x86 machine API thanks to Wine -- is considered deprecated in favour of .NET and C#.
I use GDI for simple graphics and OpenGL, when I need accelerated 3d.
Another aspect is that Microsoft's build-in implementation of OpenGL is definitely to be considered as deprecated since it is just version 1.1 or something, but that has been for a long time.
Yeah, about OpenGL, it actually outperforms DirectX in many ways both resource and display wise. It will never be promoted by Microsoft because it can't own OpenGL, not to mention most people don't do their research and Microsoft can claim it is old. Truth is opengl is opensource standard and evolves at a much faster rate than closed does because it is more than 1 room of developers paid to work on it. Also Microsoft has contracts with many companies to release using only Microsoft's software, this causes more business for Microsoft and less to use the more advanced OpenGL standard. It is a interesting lock up if you will, Microsoft creates these contracts so that many programs are written in DirectX to keep business for Microsoft, and no company will refuse it because Microsoft has about 80%+ home user market.
I'm a Windows (native, not .NET) programmer and I'd like to port an application to the Mac.
Actually, I believe it will be more of a rewrite, as the original depends on many activex controls.
As I have never used a Mac in my entire life, I'll need some guidance. O:-)
a) What book(s) would you recommend to make the move from Win32 to Mac OS?
b) Is there anything similar to Delphi (RAD) for the Mac?
c) Can anyone recommend (or not) Lispworks (www.lispworks.com)?
d) Is there anything similar to the Windows market of 3rd party COM components (so I don't have to write everything)?
e) Anything else I should be aware of the Mac market?
f) Oh, BTW, what Mac should I buy? O:-) (must be a laptop)
Thanks in advance
I've taught Cocoa programming to several Windows-experienced programmers. You may find a previous post on the subject useful.
Cocoa is a very different way of thinking then MFC and its kin. You will do much, much better if you take the time to learn how Cocoa approaches things and adapt to its mindset rather than trying to find the quickest way to implement your current way of thinking in ObjC. It is possible to write MFC-style code for Mac, but you will always be fighting the framework if you do. I've seen a lot of Windows developers struggle with this.
The best book to learn Cocoa is Cocoa Programming for Mac OS X. Assuming you are a C++ developer with a solid OOP background, this is the book to start with. If you have limited Object Oriented background, then start with Programming Objective-C 2.0.
You would be amazed how fast Objective-C can be to code once you understand the patterns. It really can be stunning compared to C++ in my experience. There are more RAD-like systems like REALbasic, and you can develop Cocoa apps in Ruby now which can be a bit quicker. But there really is no substitute in the Mac market for ObjC. It's hard to make an app that works like a Mac app without using the Mac frameworks, and Mac users tend to be much fussier about such things than Windows users.
I have no background in LispWorks, but LISP seems a terrible language for developing the kind of rich UIs that Mac apps are known for. I like LISP (quite a lot actually), but Functional Programming's "no side effects" philosophy seems at odds with most rich UI goals (especially as the Mac UI becomes more and more animation-centric). If anything, Mac programming is moving towards Declarative rather than Functional programming (Core Animation and Grand Central Dispatch have a lot of Declarative concepts creeping in).
There is not as large a third-party component market as there is for Windows. Some of this is because Cocoa already provides such a rich set of components, which MFC does not, and because well-behaved Mac apps are expected to use those components so that you work like all other Mac apps. There is definitely little market for commercial components in the vein of RadControls for .NET (very nice toolkit, that one). But there are quite a few nice free components out there with flexible licenses (generally MIT-based). A few of my favorites:
Positive Spin Media's excellent tabbar control
OmniGroup's frameworks (though I never use them "as is;" they're better used as examples of how to do things)
Growl
Sparkle
RegexKit
CocoaDev's ObjectLibrary list of other stuff
As I mentioned before, Mac users are picky about their UI. Much, much more so than Windows users. They expect things to be polished, and they expect things to integrate with all the little things that make Macs nice. That means drag-and-drop, Spotlight, services, Applescript, Expose, QuickLook, integrated spelling check, etc. etc. It's very hard to do all these things right if you don't use the built-in frameworks. That's why I recommend new Mac developers start at the beginning and learn the frameworks.
For a Mac, if you have a bunch of hardware lying around (like keyboards and monitors), then a Mac Mini is a nice cheap box. iMacs are great if you want an all-in-one, and any MacBook is appropriate if you like portability. There is no Mac on the market today that is not a perfectly fine development box. Obviously if you do a lot of work, an 8-core Mac Pro makes compiling much faster, but I've done a lot of professional development on a 13" MacBook. If you want to get in as cheaply as possible, look for refurbished or used (I love my refurbished Mac Mini). Any Intel-based Mac is going to be fine for development, at least while you're getting started.
If you are familiar with C, you may want to learn Objective C since that is the Macs "native" programming language. It's also what you have to use to write iPhone applications. Cocoa is Apple's primary API that will have a lot of the tools you are looking for.
a) Read this thread for book recommendations: https://stackoverflow.com/questions/7571/cocoa-and-objective-c-resources
b) Apple makes Xcode for developing in. There are certainly better ones out there, but it's not bad.
d) Cocoa is Apple's main API, which provides "core" services like CFNetwork for networking. There is also core data, core audio, core animation, core image, core location,... Underneath it all, OSX is Unix, so you have access to many unix/linux libs.
e) The iPhone is a big part of the Mac market. The iPhone and OSX development environments are not that different, so you can learn both.
f) Any Mac is sufficient for most development. If you want a laptop, it's really a question of screen size and price. But I would recommend at least a 15 inch screen. You don't need to spend extra for a faster CPU, but you may want to get a larger hard drive.
If you've done your native Windows programming in C and/or C++, you may have an easier time migrating your application to C#/.Net, and then running it in Mac using Mono. At least some of the available third-party .Net components will run on Mono (see http://www.mono-project.com/Third_Party_Controls_Status).
I have no idea what Mac you should buy - I recommend getting one of the pretty ones.
a) ...
b) You could use Python coupled with wxPython and be cross platform. Python is included by default with Mac OS X.
c) ...
d) I'm sure there is, but I can't tell you more. If you use Python, you get tons of third party libraries for free.
e) They don't take kindly alien GUI guidelines:
Word 6.0, launched in 1993, is widely considered to be the worst version of Word ever for the Mac, as it was based on the same codebase as Word 6.0 for Windows. That meant that it looked and worked more like Windows software than a Macintosh program. Mac users were so up in arms that Microsoft actually released a Word 5.1 downgrade to unhappy Word 6.0 owners.
f) Mostly any iMac will be good enough for programming. Choose the one that you like the most and has lots of RAM.
e) Its a small market.
f) An iMac. Edit: since it says laptop - Macbook Pro 13 is a great deal.
For software applications like games, does this mean software companies have a lot of extra coding to maintain 3 branches of certain libraries?
I know this is hard to say, but for game development in general, are there specific areas in the software where they will have to write 3 times in order to work in all 3 flavors of windows?
I'm guessing the core software will be untouched, but maybe some drivers will need to be version specific?
It depends how close to the OS you are. If you're just using the .NET framework or DirectX, probably not much changes between operating systems. If you're writing drivers or relying on the Win32 API then there definitely could be subtle or not so subtle changes.
If your code is written correctly in the first place, there should not be a huge investment into supporting an OS upgrade. Using something like the .NET framework helps guarantee this even more.
Also, why would games have 'drivers'?
Not really. If you use DirectX 9, you are fine on all 3 Windows Versions. The extra maintenance evolves around stuff like the Installer/Uninstaller, about the Games-Tab that was new in Vista (if you want to use it) etc., but as said, DirectX 9 is a stable API on all 3.
You will get into some fun with DirectX 10 (not on WinXP) and with OpenGL (Support in Vista is weird).
Even if you use "portable" interfaces like DirectX or .Net or whatever that are supposed to provide the same functionality, a responsible software developer will have to do QA and testing on each supported platform.
(Note that I don't claim to be a responsible software developer. :-))
Many game develoeprs, including the studio I work for, use engines that manage cross platform issues. We are using Unreal for our game and it ports to the PS3, Xbox, and PC with no issues other than performance differences between them. The engine typically handles the differences in platforms.
As a .Net developer, most of the issues I saw when running applications built with XP as the original target were things we were doing incorrectly that just happened to work in XP (most were using the system colors that looked ok on XP but were wrong for Vista -- e.g., the default Vista theme caused a black font on black background).
It was coding by coincidence at its finest (we were naive enough to not know it was wrong). However, once we started testing on both Vista and XP, we started to produce a better Windows product.
Some of the requirements (restrictions) for such a ui framework/toolkit are:
No single vendor lock down
Ability for real time data visualization
Good initial widgets
Good dash boarding capabilities
cross platform
Good development/debug environment
No flash
It's a pity you can't/won't use Flash. Else I could really recommend Adobe AIR. It has a good editor (Flex Builder built on Eclipse), a good component framework with many out of the box components, charting components set, ability to communicate with many different protocols (and you could write your own protocol implementation), cross platform, runs in the AIR runtime and not in the browser, file IO, ...
I wouldn't pass over Flex/Air (Flash) without a closer consideration but here are a few others I have come across:
wxWidgets
GTK+
Qt
There is also a slashdot post with links to some tookits I haven't heard of. I'll add their recommendations here:
GLUI, an OpenGL-based GUI
Whisper, a Mac/Windows application framework
WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
For general information:
GUI Toolkit/Framework Page
PIGUI FAQ Page
C++ User's Journal PIGUI Page
I might suggest Mozilla XUL, but it has some drawbacks:
No really good development / debug environment (although there are tools and debuggers; they are variable)
You are locked into a vendor, but it is Mozilla.
It is very easy to use though and allows you to reuse your web Javascript skills for a rich-client app.
There's also Java of course. It satifies all your requirements AFAICS.
Plenty of custom charting controls, which are things you will struggle to find for GTK/WxWindows/$other_small_userbase_framework.
If you dont like Swing(its come a long way - Metal is dead, long live SystemDefault L&F!), there are options like SWT or even QT bindings for java(QTJambi).
For C or C++ go QT, its APIs are really nice.
For RCAs check out Eclipse RCP. For RIAs, you might be interested in OpenLaszlo. It's a rich internet platform that can compile both to Flash and DHTML.
http://www.gnustep.org/
"GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components."
Portable to: Windows, BSD-based systems, Linux-based systems, HP/UX, , Solaris, Sparc, GNUstep Solaris 10 U2 vmware appliance, OpenSolaris, others.
I recently made a pretty complete list here: http://commadot.com/ria-frameworks/
ExtJS is probably my favorite and we use that at work. I think it satisfies your list. Otherwise, there are a bunch of other possibilities on that page.