[XForms] ClientMessage handling change?

[Jean-Marc Lasgouttes]

>>>>> "Jeff" == Jeff  <wd4nmq at comcast.net> writes:

Jeff> To subscribers of the xforms list As I have said in previous
Jeff> posts I want to be able to process ClientMessage Xevent
Jeff> messages. After several attempts I found that ClientMessages are
Jeff> handled. But, it is very limited in scope.

Jeff> It looks for a WM_PROTOCOLS and WM_DELETE_WINDOW atoms. If it is
Jeff> not that, it passes it to fl_handle_form with FL_OTHER and
Jeff> FL_OTHER causes it to be passed to other open forms.

Jeff> Now, I thought the whole purpose of ClientMessage was to pass
Jeff> messages to specific windows, ie forms. Now, would it nor make
Jeff> since to have a user registered routine to handle
Jeff> ClientMessage's that are not WM_PROTOCOLS and WM_DELETE_WINDOW
Jeff> atoms?

Yes, that would be a good idea, since it is backward compatible with
the current behaviour.

Jeff> So, a flow in handle_client_message() could go:

Jeff> Is message type == WM_PROTOCOL? Yes, then handle it and exit
Jeff> function. No, is there a registered ClientMessage Handler? Yes,
Jeff> pass it to user handler function and exit on return. No, pass as
Jeff> FL_OTHER to fl_handle_form as before.

Or you could have a default handler that handles WM_PROTOCOL, and the
user handler would be free to call this or completely override it.

Jeff> I really think this would be a good thing for xforms. It seems
Jeff> that gtk and kde already support this. Plus, as I previuosly
Jeff> mentioned it would be much easier to have worker threads use the
Jeff> XSendEvent to a form's event handler to do a form gui update
Jeff> rather then have to use mutexes in an event loop.

Could you try to write a sample implementation?

JMarc