No good cross-platform GUI TKs?

So, I am trying to decide on a cross-platfrom API/TK/whatever-you-like-to-call-it, and wow, I am at the point where I have to lean back and just laugh.

A few years ago, I made a nice little personal contact database in MySQL and wrote a front-end for it in C++ using Qt 3.something on my Slackware Linux system. It worked, and it was fast. I never compiled it on Windoze. Well now I'm working with the latter, trying to get ramped back up on this stuff, and having major issues with Qt 4.8.3 and Qt Creator. I built a program, but simply connecting to the database, doing nothing else, then disconnecting will cause the program to crash on exit.

Being very frustrated at not even getting example code to work in Qt, I started looking into Java, and learned I had to decide whether to Swing, or to SWT. Then I found out about the recently uncovered major vulnerability here: http://www.informationweek.com/secu...n-plu/240007985 So, I'm not crazy on the idea of using that now. Also, I'd rather have native code anyway. I don't like the sluggishness of Java.

So then I looked at using eC, with the Ecere IDE. It's a really fast IDE, I'll give it that. What I can't give it credit for is working... at all. I used their installer that includes the IDE and MinGW environment. There was little to nothing in the way of configuration directions, and I got no errors or warnings. But, when creating and running the simple little hello world code from "The Ecere Tao of Programming", the IDE just crashes. Sometimes it crashes when building, sometimes when cleaning, and sometimes not at all, but when the program runs, there is no output. And then the IDE crashes.

I tried installing Qt Creator on my personal Gentoo Linux system, but there are umpteen "blocked" packages for some reason, and being a new Gentoo user, I don't know what that means or what to do about it. A quick web search reveals no quick fix, and it was too late to start digging into the why and how of correcting that.

So like I said, I just have to sit back and laugh at this point. I have been at this for days and still haven't managed to get far enough in my own code to be the cause of any of these problems. Even the example code I am trying to test out doesn't work right. Sometimes, you just have to walk away, and sometimes, you just don't have time to.

Oh well, my rant is over. At least I got to vent a bit.

For what it is worth, I coded a nice little free app that has a userbase of approx. 500-600 users, as far as I know (based on download stats. Might be less or more because I stopped keeping download stats after a while and not everyone downloading it is necessarily using it). I used python and Tkinter to code the GUI and it runs on:
Windows (tested from Windows 2000 to Windows 7)
Linux (various distros: Ubuntu, Fedora, Gentoo for sure)
Mac OSX (This is what I developed the app on)
OpenBSD (tested version 4.6 up)
NetBSD
FreeBSD

Tkinter does GUI work fairly decently across different OSs.

The app I wrote can run in GUI mode as well as text mode. So if you're running it in from a Windowing environment, it will show a GUI using Tkinter and if you're running it from a ssh terminal, it will try to present a text GUI using the curses package, failing which, it will fall back to printing questions one line at a time and take input manually. You can also specify all the options by writing a config file and telling the program to use the config file instead (which is useful if you want to run the program as a cron job). In writing this, I was somewhat inspired by emacs which also runs in GUI or text mode depending on where it is running.

The reason it can run like this is because I abstracted out the program logic from the part that receives user input. Then I simply made 4 or 5 different user interface classes: one that draws a GUI, one that draws a text GUI, one that reads from config file, one that reads from command line etc. All these user interface classes have identical method names to retrieve the user input, therefore the rest of the program doesn't care how the user entered the data.

On startup, the code looks at the environment and decides what OS it is running on and whether it is running in a GUI or not (in case it is in a *nix environment). Then the code creates an instance of an appropriate user interface class and passes it on to the program logic class. That's how the code works across multiple OSs and GUIs

I don't know python, but I have used Tcl/Tk in the past... I'd forgotten about that option. It's a bit crude looking, but it always seemed to work, and was reasonably speedy. I might have to check into that.

I was rather disappointed in Ecere. I liked what I'd read about the eC language and was really looking forward to trying it out. Well thanks for the reply, you've given me another option to think about!