OSDev.org

my GUI is a simple one, where *all* things(from window to button) are widgets.
well, each widget has a class(which is the same for two buttons, windows, etc) which has some specific "message handlers" for that type of widget(button, window, etc). so, if you change a window-widget's class to button-class, you make a button that widget.
The problem is with those "message handlers". I can do it in several modes:
1. (WinAPI like) message(Widget widget, int message, int param1, int param2) -> simple, general message function, the problem is with the parameters.
2. (Gtk like, I think) handlers for each action (MouseClick, MouseMove, WidgetRedraw). the problem is with the special functions for the widget class.

thanks,
eddyb

Not sure what your question is here. My guess is that the GTK way is basically the Win32 way plus some object-oriented stuff (separate handlers for each message type).

Actually, they are fairly different.
In Win32, everything is a window, and all "event" messages are passed back through the main() program's generic message queue. There are several hundred different kinds of event messages, depending on what action was done on which window type. You just have a big switch statement that handles all the events you are interested in, and pass the rest to the default handler.

In GTK, widgets are created via inheritance, from more generic widgets. It also has two completely separate types of messages, "events" and "signals". Each widget has a predefined array of callback functions for all possible events and signals for that specific type of widget. If the callback is not registered for a specific message, then the message does not get handled. But the callback handler function is called directly and immediately any time an event happens to a widget. There is no message queue.

This actually makes the Win32 method a bit more flexible, because you can take over the function of the default handler -- but there really is no default handler to take over in GTK.

yeah, WinAPI-like is better because is a simple, general handler. it's also good in server-client communication: you need to pass only 4 ints(widget is replaced by a unique id, it's handler). but what do you do if you need, for example, to change the title of the window? you have to pass a char *. i must find something that fits all my need... if you got a suggestion, you're welcome.
thanks, eddyb .

My answer is: try to pass as little as possible. Do NOT pass a huge number of integer arguments. Pass pointers to a filled-in widget structure (object) instead.

In one way, GTK is significantly better than Win32. The widget handle is a pointer to a local, well-defined widget structure. The title of a window is one element of that structure. If you want to change the title, all you have to do is:
(Or the OOP equivalent to that.) And you can't do that with a Win32 HWND.

My suggestion for Win32-style APIs is to pass a well-defined information structure for all events on all widgets. Not just a Wparam and Lparam long int. Put enough info in that structure so that you can reduce the number of possible "event messages" to the minimum possible.
Current GTK event structures, and GTK widget structures are a very good starting point for creating an improved Win32-like API.

that is what I was thinking. it perfect for 1-process GUI. but what if you have some server-client interaction? the widget will be referenced as a unique handler, id, or whatever-called, and you have no more control to the widget struct.

EDIT: I really need to learn something about IPC and server-client GUI stuff. maybe I should make functions for everything and make them accessible via some IPC? maybe I can put the common controls to a lib which does all the stuff?