Re: XForms: Xforms as a plugin

Steve Lamont (spl@szechuan.ucsd.edu)
Thu, 2 Apr 98 05:42:06 PST

# To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve Lamont) :

> > Are you actually handling the events in the 3D app? Is the app
> > "eating" the events? Are you using XPutBackEvent() to stuff the event
> > back in the queue?
> The 3D app API allows me to install a callback/handler which is
> executed before any of the 3D apps.' Xevent processing. I believe the
> function is analogous to the xforms fl_set_event_callback(). The 3D
> app. ends up "eating" the events in the end.

Does the handler actually get handed the event or just some
notification that an event has occurred? If the former, you probably
need to stuff the event back on the queue with XPutBackEvent().

> > Does your app make a separate display connection? How is it actually
> > processing the events? With XNextEvent()?
> My plugin doesn't create a new display connection (unless
> fl_initialize() or xforms in general does this).

Yes, fl_initialize() does create a display connection.

> > Does the app separately process its own events? If so, how does it
> > discriminate between the events that it "owns" and those that XForms
> > "owns?"
> The handler callback that I install must return 1 if the event is to
> be handled by the 3D app. Otherwise, it must return 0 indicating the
> event was handled.

And what do you tell it?

> My thinking was that when I call fl_initialize() or fl_show_form()
> later, I'm not able to say that the new window should be a child of the
> 3D app. Does the new window get parented to root?

When a new top level Window is created it is parented to the root
Window and then immediately reparented to the window manager, which
slaps its decoration around it (title bar, borders, and whatever other
gingerbread it wants).

I suppose you *could* try reparenting the XForms window to your
application -- I'm not sure what would happen. You might need to find
the parent of the XForms window (which you could do with the
XQueryTree() function) and reparent *that* to the 3D app.

However, I'm not sure that any of this would work -- I've never tried
doing something like this. Even if it did, I'd be nervous about its
stability.

Are there any other callbacks from the app's API that might be better
suited to doing something like this?

If there's something akin to an XForms idle callback what you may want
to do is to spawn a new process which creates your XForms GUI and then
use that idle callback to process commands passed to it via a pipe or
some other mechanism from the XForms window. If there's a callback
analogous to the XForms IO callback for processing asynchronous IO,
then you could use that and avoid having to poll the pipe
continuously.

If the only thing you have is the API's fl_set_event_callback()
analog, then another possible method might be to use the XSendEvent()
mechanism to communicate between the GUI, the app and vice versa.
Again, spawn your XForms GUI with a fork() and exec(), then using
XSendEvent() and maybe some of the interclient communications
functions should allow you to happily communicate without having to
worry about whose event belongs to whom.

I don't know how interested the rest of the group is in this -- if you
want to carry on this dialog directly, I'll be happy to take it to
private email.

spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/