[XForms] ClientMessage handling change?

[Jeff]

As I have said in previous posts I want to be able to process 
ClientMessage Xevent messages. After several attempts I found that 
ClientMessages are handled. But, it is very limited in scope.

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

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

So, a flow in handle_client_message() could go:

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

The user's handler code would use it's on message type atoms.

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

So what does anybody who still reads this list and thinks xforms may 
still survive think about this idea?

Jeff
wd4nmq at comcast.net