Linux Graphics Question.

[swestrup]

I've only ever written text-based programs for Linux, and am thinking of writing one that would be inherently graphical in nature. Imagine something like the venerable FractInt.

The question is: is there a standard Linux API that would allow me to have my program open a window and perform graphics in it, and possibly respond to window controls, without being specific to any particular window manager? I would ideally like this program to run equally well under Gnome, KDE, or whatever and yet still make use of whatever the standard widgets of the windowing system are.

If so, what would this API be called, and where can I find docs on it?
---
EDIT: Okay, after a lot of googling and reading, the main contenders seem to be wxWidgets and Qt. Since I happen to know of at least one company looking for Qt developers, I guess that tips the scale in favour of learning that API.

Comments

[cpirate.livejournal.com]

Neither wxWidgets nor Qt really makes use of any standard system widgets; they're both ported to Windows, but they both look equally out of place there. The same could be said for GTK+.

My personal preference is to avoid wxWidgets, as it's a bit limiting and looks out of place on Linux too. The main difference between GTK+ and Qt is that Qt is a native C++ library, where GTK+ is in (object-oriented) C. I find programming in Qt a bit of an irritation, due to the preprocessor you have to use. Programming in straight GTK+ is also annoying, as the C API is rather verbose. If I had to do something like this, I'd use GTK+'s C++ bindings, called gtk-- (or gtkmm), but then I also just plain prefer the look of GTK+. If you've got any particular reason to use Qt, it'd be an equally reasonable choice.

Sadly, I don't know of any abstraction layers that could just take a basic window layout and use either Qt or GTK (or Win32, I suppose), depending on what was available. I guess it'd be difficult to iron out all the little graphical glitches that'd be sure to pop up.

[joenotcharles.livejournal.com]

Qt looks pretty much native under Windows (can't speak for Mac, but supposedly Qt 4's much better than it used to be). On the XP box I'm using right now, both Visual Studio and Microsoft Office look way more out of place than the Qt apps do.

Qt's custom preprocessor is a bit annoying, but you get used to it quickly.

Qt's main advantage is that the documentation is way better than any other windowing API I've ever used, so the learning curve isn't very big at all. (It's at http://doc.trolltech.com/4.3/ for the latest edition, and http://doc.trolltech.com/3.3 for the API-incompatible but still more widespread 3.x version)

[joenotcharles.livejournal.com]

Oh, I missed the bit about using the standard widgets for Gnome or KDE, depending on what's in use. That's one of my pet peeves - it's possible but difficult.

I think most of the work toward this has gone toward allowing Gnome apps to use KDE standard dialogs (file management, printing, etc) and themes, rather than the other way around, which would argue for working with Gtk+. But I don't think any of the work that's been done has actually produced anything anyone uses, so it's sort of a moot point.

[akuchling.livejournal.com]

A game-programming library like SDL (http://www.libsdl.org/) would also work, though it would probably be weak in presenting menus, dialog boxes, and the like.

Aptus (http://nedbatchelder.com/code/aptus/) is a Mandelbrot renderer that uses wxWidgets through wxPython.

[swestrup]

The problem is that I want to explicitly use the default widget set for the environment I'm working in. I don't know of any game library that does that.