views:

752

answers:

5

In Windows when you create a window, you must define a (c++)

LRESULT CALLBACK message_proc(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam);

to handle all the messages sent from the OS to the window, like keypresses and such.

Im looking to do some reading on how the same system works in Linux. Maybe it is because I fall a bit short on the terminology but I fail to find anything on this through google (although Im sure there must be plenty!).

  • Is it still just one single C function that handles all the communication?
  • Does the function definition differ on different WMs (Gnome, KDE) or is it handled on a lower level in the OS?

Edit: Ive looked into tools like QT and WxWidgets, but those frameworks seems to be geared more towards developing GUI extensive applications. Im rather looking for a way to create a basic window (restrict resize, borders/decorations) for my OGL graphics and retrieve input on more than one platform. And according to my initial research, this kind of function is the only way to retrieve that input.

What would be the best route? Reading up, learning and then use QT or WxWidgets? Or learning how the systems work and implement those few basic features I want myself?

+4  A: 

It's totally and utterly different. That window procedure is 100% specific to the Windows OS. For linux, it will depend on the window manager (gnome, kde - as you've already mentioned). If you wish to do cross-platform development, you might want to look at things like QT.

You may wish to take a look at the following URLs:

http://www.qtsoftware.com/products/appdev
http://en.wikipedia.org/wiki/Qt_toolkit

Mark Ingram
+6  A: 

Well at the very basic level you have the X Window protocol http://en.wikipedia.org/wiki/X_Window_System_core_protocol, which we can be pretty complex to handle if you want to do any application. Next on the stack there's Xlib http://en.wikipedia.org/wiki/Xlib which is a "convenient" wrapper around the X protocol, but still is complex for "real life" applications. It's on top of Xlib that most other frameworks are built, trying to simplify application development. The most know are: Xt, Gtk, Qt, etc.

Like in window you have a "event loop", and if you want you can implement on top of it a GetMessage/DispachMessage metaphor to mimic the windows behavior. That way you may have a WNDPROC, but natively X doesn't provide such thing.

Before reinventing the wheel is preferable to take a look at similar applications, what they are using.

If you need something simple you can try SDL http://www.libsdl.org/, which is a cross platform library to aimed to develop games/simple applications. Another alternative is Allegro game library http://www.talula.demon.co.uk/allegro/.

Ismael
Could you please elaborate that last statement? I thought the WNDPROC was the event loop. And in that loop, creating my own events so that the rest of the app doesnt know which OS it runs on was something I was planning. Is that whats called a Dispatch system?
mizipzor
Windows have a message loop http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx. Sometimes this is hidden by the framework that you are using, ie MFC, .NET, etc.
Ismael
For each thread you have a message queue, where WM_XXX messages are stored when they are generated, the message loop is responsible to peek these message and deliver them the appropriate window proc.
Ismael
@mizipzor: you're right, the wndproc is the message passing routine for all windows. However, this is a Microsoft Windows based thing. Linux doesn't work in quite the same way. Use a higher-level library - eg QT
gbjbaanb
Don't forget that GTK and and Qt are both cross-platform!
+2  A: 

As stated by xhantt, what transport the equivalent messages you are looking for is the X Window System. Which, indeed, can be a bit complex.

With XLib you will need to handle the events registering and dequeuing in your main loop. See the XLib manual for a complete description on how to proceed. But don't forget that you will only catch window and inputs events this way. Not every OS messages.

You can also look for XCB which is a newer, and probably easier, library.

If you build your application on top of those two library, it will run smoothly under (almost, we can never be too sure) every WM. And you won't require any dependency that most linux user don't already have on their installation. If you go with Qt, GTK, etc... It will be easier and work under any WM, but they may not have library installed.

Window and input events is enough. As stated, I only want a window to draw some OGL in and listen to input, for a simple game. Thanks for the link to XCB, Ill look that up.
mizipzor
+1  A: 

In principle it is absolutely the same. However, it has nothing to do with communication with the OS (nor does it on win32, using user32.dll is entirely optional)

A GUI application has an event loop somewhere, which processes messages from a queue at some level.

There are a lot of libraries typically used to "hide" this behaviour - you can use them (and indeed, you should). If anything, the Xlib event system is even more perverse than Win32's user32.dll one, and is less widely understood, therefore fewer people use it directly.


In Linux or in Windows, applications can use the low-level GUI, or can use a library. Most use a library. Applications can also choose to do neither and operate without a GUI (server applications typically do this). Applications can create multiple threads, one of which sits in an event loop, and others work differently. This is a popular approach too.

  • Most GUI applications use a higher level library for their GUI
  • Non-interactive applications, e.g. server applications, don't use the GUI at all and don't use the libraries (e.g. XLib, user32.dll)
  • Applications which don't lend themselves to an "Event loop" (e.g. Games) typically use a separate thread to process their event loop.
  • These things are largely true on Win32 and Linux.
MarkR
Nice, I was hoping for an answer like this. Im writing a game, so there will not be much GUI or system events. But if I would claim that the event loop is the only way to retrieve input from the user, can you prove me wrong?
mizipzor
Games usually have a separate thread for running the event loop from the one which runs the game logic - the game logic thread typically picks up data in shared variables etc from the event processing thread. There are other possibilities however.
MarkR
A: 

on windows, there is "message map" for declare the message's callback functions, what 's the instead on qt,I know the signal/slot could do the some thing ,but how it's do on the bankend?

alex