I would like to know where to start with Linux GUI and graphics programming. I am familiar with Windows GUI and graphics programming. I have a few questions. What are the equivalents to the Windows API (ex. Win32 API) and GDI? What is the relationship between X Windows and Gnome/KDE/etc. and Qt/Gtk/etc.? When you write a GUI in Windows, you write a Windows application. When you write a GUI in Linux, are you writing an X Windows application, or a Gnome application, or a Qt application, or what? Where do things like Qt and Gtk fit into the picture? Would WxWidgets fit into the same category as Qt and Gtk? Someone please point me in the right direction. Links or names of man pages would be appreciated :)

Qt and GTK are like Win32 - they handle windows and controls, at the application level. Gnome and KDE are used to the manage where those windows go on the desktop, as well as file management and all the other stuff that makes a computer usable. XWindows provides the interface to the hardware to make all this show up on the screen.

So, when you sit down to write an app, you have to decide:
1) KDE or Gnome exclusive - if you choose this route, you have to link with libgnome or libkde, and only people with KDE or Gnome installed can use it - fluxbox et al are out. If you use Gnome, GTK is required; with KDE, Qt is required.

2) GTK or Qt - This requires only GTK or Qt be installed, which most machines have (Mozilla, for example, is written in GTK). This means Xfce and fluxbox users can use your app, if they have GTK/Qt installed, without pulling in all of Gnome/KDE.

3) Pure Xlib - don't do this.

wxWindows is wrapper around GTK, so GTK is required for wxWindows apps.

Quote: Original post by ze_jackal
3) Pure Xlib - don't do this.

Except if all you are doing is creating an OpenGL window. It is trivial to use pure Xlib to create a simple window, and thus avoid the overhead of linking to qt or gtk.

Quote: Original post by jamessharpe
Except if all you are doing is creating an OpenGL window. It is trivial to use pure Xlib to create a simple window, and thus avoid the overhead of linking to qt or gtk.

Well, its not exactly trivial. If you want to avoid doing Xlib at all (most people never use it directly) SDL does GL really easily.

wxWindows I've never used, and it doesn't appear to be widely used, but the idea sounds good, and I wouldn't avoid it just because its not horribly popular.

Qt is a C++ widget library, but (last I checked) uses a nasty custom preprocessor to kindof "extend" c++. yucky.

Gtk is a C widget library, but... well, its a C library.

I personally like Gtkmm, its nice and C++ (and intelligently so, too!) and just works well with me.

If you want to write linux GUI apps, look at the API's of gtk/mm and Qt and see which one looks nicer to you, and learn it.

I'm a GNOME person, so I'm biased.

For linux, if you're sane, you code using toolkits. The two dominant ones that everyone will most likely have are QT nost popular with KDE and GTK most often found in Gnome. You don't necessarily need the desktops for the apps written with the toolkits to work. Most every distro will have installed the components needed for GTK and QT apps to work in whatever desktop/WM. My preference, wxWindows is almost exactly like MFC. The only difference is that all classes start with "wx" instead of "C" and it will compile almost flawlessly on Mac, windows, linux, and quite a few others. It is a good alternative to QT because it is free to use on more than just linux and a good alternative to GTK because it's implementattions are um... less sloppy on other platforms (see windows GTK apps like Gaim and Gimp). It uses GTK for linux apps by default but there are QT and Motif implementations out there. If you are most familiar with win32 I would recommend GTK, though. HTH.

Also, wxWidgets/wxWindows makes it really easy to write GL apps I don't know if it's as easy sdl. But it is quite trivial.

Also, the Mono Project provides GTK#, which wraps GTK and exposes it to the CLI. I haven't used it, but I've heard it's nifty.

A signifigant portion of the Gnome developers want to gradually move the entire platform over to Mono/GTK#; an equally signifigant portion wants nothing to do with "M$" technology and wants to stick with C. This is the bane of open-source software that lacks a real leader (like Linus) - a situation that is very likely to trigger a fork.

MonoDevelop provides a Linux port of SharpDevelop, which is a pretty neat IDE.

Quote: Original post by ze_jackal
Also, the Mono Project provides GTK#, which wraps GTK and exposes it to the CLI. I haven't used it, but I've heard it's nifty.

The real advantage to having a C API: you can wrap it in almost any language! Qt can't really match the number of bindings in different languages that gtk has.

Quote: A signifigant portion of the Gnome developers want to gradually move the entire platform over to Mono/GTK#; an equally signifigant portion wants nothing to do with "M$" technology and wants to stick with C. This is the bane of open-source software that lacks a real leader (like Linus) - a situation that is very likely to trigger a fork.

I doubt that it'll result in a fork.

If you look real closely at what Mono is doing, well... the "linux stack" is totally free (the windows stack is questionable-ish sorta) so the fears over "M$" squashing their development will be relaxed as soon as more developers realize this.

Also, we're not talking about a total switch. Things like Evolution will (may) be in c#, but most of the core gnome stuff will stay in C.

Quote: Original post by C-Junkie

Quote: Original post by ze_jackal
Also, the Mono Project provides GTK#, which wraps GTK and exposes it to the CLI. I haven't used it, but I've heard it's nifty.

The real advantage to having a C API: you can wrap it in almost any language! Qt can't really match the number of bindings in different languages that gtk has.

Well, that's the beauty of the CLI, isn't it? I wonder if a GCC backend to generate MSIL could be created.

Quote: Original post by C-Junkie

Quote: A signifigant portion of the Gnome developers want to gradually move the entire platform over to Mono/GTK#; an equally signifigant portion wants nothing to do with "M$" technology and wants to stick with C. This is the bane of open-source software that lacks a real leader (like Linus) - a situation that is very likely to trigger a fork.

I doubt that it'll result in a fork.

If you look real closely at what Mono is doing, well... the "linux stack" is totally free (the windows stack is questionable-ish sorta) so the fears over "M$" squashing their development will be relaxed as soon as more developers realize this.

Unfortunately, there's a lot of FUD going around over the state of Mono. Even if Microsoft wants licenses for the ECMA standard parts (I believe they are patented) Novell can just cut them a cheque.

Don't forget FLTK - www.fltk.org
or evas (can't remember the site atm)