pererik@kheops.cmi.no (per erik nordbo) (06/12/90)
Adding event handlers to the root window. Is there a way to add Xt R4 event handlers to windows and not just widgets? I would rather avoid open up the XtAppMainLoop() and dispatch non-widget events myself if possible. I'm using properties to share data among loosely coupled processes, registering the property in the root window which is not a widget. Would it possible to convert a window to widget using XtWindowToWidget() and than using the XtAddEventHandler() mechanism. Per Erik Nordboe Chr. Michelsens Institute Norway
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (06/12/90)
> Is there a way to add Xt R4 event handlers to windows and not just widgets? > I would rather avoid open up the XtAppMainLoop() and dispatch non-widget > events myself if possible. I'm using properties to share data among loosely > coupled processes, registering the property in the root window which is not > a widget. Would it possible to convert a window to widget using > XtWindowToWidget() and than using the XtAddEventHandler() mechanism. The is no "officially" supported way to do this, but I have been thinking about this problem, and believe that I have a hack that should do the trick. Please keep in mind that I have not tried this, and am not sure it will work, but it does seem reasonable. The trick is that in order for Xt to be able to process events for the window it must have a widget associated with it. If we can figure out a way to assign a widget structure to a window that already exists, then we should be just fine. What I suggest is that you instanciate a widget of class "widgetClass" this is a Core widget. Rather than realizing this widget you should just assign the window in question to its "window" field (This is the kludgey part). Now since this window knows nothing about Xt Geometry management, you cannot manage it, and all the fields in the widget structure are pretty useless since they do not reflect the real state of the widget. Although I suppose you could set them to be correct. This seems simple enough, why could you run into trouble? The problem arises with the implementation of XtWindowToWidget(). Since this function is executed for every event processed it must be FAST. Now it seems reasonable to implement some sort of hash table to make this lookup work quickly. If this hash table is set up automatically in XtRealizeWidget() then you will lose, since your new widget will not be in the hash table. I haven't looked at this code, so I don't know what is happening, I will leave that as a excercise for the reader. Also realize that since this is not explictly supported by the Xt Intrinsics it is inherently non-portable. Different versions of the Xt Intrinsics may implement this differently. I will leave ti to you what is better for you application. Please let me know what you find out, I would be interestd. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
asente@wrl.dec.com (Paul Asente) (06/13/90)
To expound a bit upon Chris's solution (and to offer one that *is* fully within the bounds of what is supported in the toolkit)... The best way to take an arbitrary window and "widgetize" it is to write a new widget class. This class can be quite simple; the important thing in it is its realize procedure. Rather than creating a window, the realize procedure assigns an existing window to the widget's window field. When this widget gets realized, its window gets entered into the window-to-widget table directly. This widget should never be managed, but it must be realized. Disclaimer: I haven't tried this with the root window, but it should work. The context I used it in was in a widget for a reparenting window manager; it takes the client window and reparents it to the window of an existing widget. -paul asente asente@decwrl.dec.com ...!decwrl!asente
marbru@auto-trol.UUCP (Martin Brunecky) (06/14/90)
In article <9006121416.AA07750@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: > >> Is there a way to add Xt R4 event handlers to windows and not just widgets? >> I would rather avoid open up the XtAppMainLoop() and dispatch non-widget >> events myself if possible. I'm using properties to share data among loosely >> coupled processes, registering the property in the root window which is not >> a widget. Would it possible to convert a window to widget using >> XtWindowToWidget() and than using the XtAddEventHandler() mechanism. > >The is no "officially" supported way to do this, but I have been thinking about >this problem, and believe that I have a hack that should do the trick. Please >keep in mind that I have not tried this, and am not sure it will work, but it >does seem reasonable. > >The trick is that in order for Xt to be able to process events for the window it >must have a widget associated with it. If we can figure out a way to assign a >widget structure to a window that already exists, then we should be just fine. > >What I suggest is that you instanciate a widget of class "widgetClass" this is a >Core widget...(description of kluge deleted).... A'v been looking into the same issue, primarilly to allow me write a widget that could use a window provided by another application. Contrary to Chris, I do not consider window geometry management an issue. If the window has been provided from the outside, the configuration requests performed by the Intrinsics can be prevented by not managing the widget (which makes sense since this window is already managed by someone else). Any configuration requests from XtSetValues can be prevented by making the required, current and new geometry always the same (following the window size). What I do consider important is the ability to hook my window into the toolkit event dispatch, i.e. enable use of the translation management (which also dispatches to any explicitly added event handlers for that matter). There is a private routine _XtRegisterWindow (Event.c), which seems to be the key to the problem. Once the window is registered, XtDispatchEvent will know what to do with events on this window. Since I haven't tried it, I suspect there may be some "gotcha's" with selecting input and, in particular, what happens when I call XtDestroyWidget ? Anyway. Since my case is probbably not the only instance where applications want to share window, XtIntrinsics should be enhanced to deal with this case. Or, at least, support widgets that want to deal with such a scenario. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404