Re: x programming

On Fri, 12 Jan 2007 21:14:18 +0100, Zvuk staggered into the Black Sun
and said:
I didn't really start understanding programming for Windows before I
discovered Win32

A lot of the time, going lower-level than you need to just wastes your
time. Do you hand-optimize your assembly on everything you write?

In Linux, [Qt/GTK+ ~= MFC]. But, is there a counterpart of [the]
Win32 [functions], an "under the hood" approach that would not be
*too* complicated [for me] to understand?

MFC:Win32::GTK+:Xlib . Sort of. Xlib is much lower-level than GTK+ or
Qt, and practically all widget sets in use right now are built on top of
Xlib. So you might think about fiddling with Xlib and seeing if that
provides you with any insights. Start small, with something like xeyes,
modify it some, see what you learn from it.

I mean, are there messages like in Win32?

Not in the same way. X is *different* from Win32. I'll say a bunch of
stuff below, say something if there's anything you don't understand
fully.

The X server ("graphics+input driver") passes keyboard and mouse events
to X clients ("GUI apps") that indicate they want those events. An X
client may not be on the same machine as the X server, there might be
any of 15 different window managers running (or no WM at all!), there
might be one of 2 desktop environments running (or no DE at all). The
WM draws all titlebars and frames, and allows a user to resize/move
windows. Processes can communicate amongst themselves using SysV IPC,
pipes, or local sockets. GNOME/KDE apps can send messages to each other
and the overall desktop environment using protocols called Bonobo and
DCOP. HTH,

--
Some people are alive only because it is traditional to keep
torturing the poor guy about being lost in the machine room with an
IBM water buffalo. --MegaHAL, trained on ASR
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
.