XtWindowToWidget from another application.
gate...@googlemail.com
NULL windget returned when passing a Window I have retrieved from
calls to XQueryTree.
Now I have read around and I understand that Xt is client-side and all
widgets are created within the context of the host application, and I
have read up and checked out editres, but I was hoping for something a
bit simpler to implement.
The particular peice of code I have written is running inside of a
plugin that is loaded by the application that owns the Windows I have
retrieved from XQueryTree. I was working on the assumtion that by
calling XtWindowtoWidget inside of the plugin I would be able to avoid
using editre, and would be able to retrive valid Widgets from the
Windows passed to it. Am I correct in this assumtion or totally
missing something?
To quickly explain what I want to do, as I have no access to the
window structure through the program hosting my plugins API. I am
using X to select on various events to drive the plugin. My problem is
that this application has been written using motif, It creates around
600 Windows when it loads, and when inspecting the whole desktop
Window heirarchy though Calls to XQueryTree there is no way to of
telling which of the windows belong to this application, as in there
is no ClassName, WindowName, or anything set for many of these
windows.
I have made various attempts to find a 'common key' using only xlib,
but have not had much luck.
I have tried out the editres program itself, and indeed that shows I
can retrieve the whole widget tree using this protocol, I was however
hoping there might be another, simpler option?
The only information I really need to know is that Window "x" is part
of Application "y", and so far it seems that without inspecting these
windows as widgets this information is not available.
Any suggestions would be greatly appriciated.
Thanks
John.
Winston
corpse. Nothing below should be considered definitive, and I don't know
Motif at all.
"Gate...@googlemail.com" <gate...@googlemail.com> posted:
> Hello. I am having a problem using XtWindowToWidget to get a a non-
> NULL windget returned when passing a Window I have retrieved from
> calls to XQueryTree.
Barring some sort of jaw-dropping handshaking, I think that's a good
thing.
> The particular peice of code I have written is running inside of a
> plugin that is loaded by the application that owns the Windows I have
> retrieved from XQueryTree.
Even after reading your post carefully, I'm not clear whether the
situation is 1) Application(not yours) -> plugin(not yours) with an API
that won't let you access any window information -> your code, or
2) whether you mean Application(not yours) -> your plugin.
If the former, I can't help, so I assume you control the whole plugin.
> I was working on the assumtion that by calling XtWindowtoWidget inside of
> the plugin I would be able to avoid using editre, and would be able to
> retrive valid Widgets from the Windows passed to it. Am I correct in this
> assumtion or totally missing something?
Type (Window) is just a unique ID, and thus pretty safe to tell any
caller. Type (Widget) is (struct _WidgetRec *), a pointer into the
application program's memory space, which isn't going to be mapped into
another process's memory absent some very careful and explicit handshaking
between the two (which I suspect would be risky to both processes). :-)
> To quickly explain what I want to do, as I have no access to the
> window structure through the program hosting my plugins API.
I'm having trouble understanding that sentence, mostly likely because
I've never written plugin software. Does the Application pass the plugin a
Window ID, or just stdin/stdout pipes for data exchange?
> I am using X to select on various events to drive the plugin. My problem
> is that this application has been written using motif, It creates around
> 600 Windows when it loads, and when inspecting the whole desktop Window
> heirarchy though Calls to XQueryTree there is no way to of telling which
> of the windows belong to this application, as in there is no ClassName,
> WindowName, or anything set for many of these windows.
[...]
> The only information I really need to know is that Window "x" is part
> of Application "y", and so far it seems that without inspecting these
> windows as widgets this information is not available.
But are you starting with x, y, or neither? If the Application gave the
plugin a Window w, won't an XQueryTree (..., w, &parent_return, ...) loop
find Application's top window? Then for any window at all, testing
(top-parent(window) = x's top) would indicate "is same application"
(regardless of what file name the application was run as). If you actually
care about some program's invocation name, maybe xlsclients can help.
I'd be happy to learn more about how browser plugin interfaces generally
work. HTH,
-WBE
Jano
> I was working on the assumtion that by
> calling XtWindowtoWidget inside of the plugin I would be able to avoid
> using editre, and would be able to retrive valid Widgets from the
> Windows passed to it. Am I correct in this assumtion or totally
> missing something?
>
You are missing something.. :-)
Window(s) are basic rectangles on the screen...
Widget(s) are complex object(s) potentatially having numerous windows...
For instance, a Scrollbar widget has at least 5 windows : the
container, the 2 windows containing the arrows, the one containing the
slider image, plus the one containing the area where the slider
slides...
Thus, a XQueryTree will give you all 5 window Ids, only one of which
will correspond to a valid Widget... : the container window...
> To quickly explain what I want to do, as I have no access to the
> window structure through the program hosting my plugins API. I am
> using X to select on various events to drive the plugin. My problem is
> that this application has been written using motif, It creates around
> 600 Windows when it loads, and when inspecting the whole desktop
> Window heirarchy though Calls to XQueryTree there is no way to of
> telling which of the windows belong to this application, as in there
> is no ClassName, WindowName, or anything set for many of these
> windows.
Yes there are means...
XQueryTree gives you exactly the descending children, as well as the
main child and the root..
Thus all children listed if you start from the TopLevel are really
children of this Window, and thus of the application..
Whether or not they correspond to a Widget depends on the explanation
above...
> I have made various attempts to find a 'common key' using only xlib,
> but have not had much luck.
>
> I have tried out the editres program itself, and indeed that shows I
> can retrieve the whole widget tree using this protocol, I was however
> hoping there might be another, simpler option?
>
> The only information I really need to know is that Window "x" is part
> of Application "y", and so far it seems that without inspecting these
> windows as widgets this information is not available.
>
> Any suggestions would be greatly appriciated.
>
> Thanks
>
> John.
If you want to test about a certain Widget type, there are ways to do
so, as some callbacks only exist in some type of widgets...
--
Fred
> GateFi...@googlemail.com wrote:
> > I was working on the assumtion that by
> > calling XtWindowtoWidget inside of the plugin I would be able to avoid
> > using editre, and would be able to retrive valid Widgets from the
> > Windows passed to it. Am I correct in this assumtion or totally
> > missing something?
>
> You are missing something.. :-)
>
> Window(s) are basic rectangles on the screen...
>
> Widget(s) are complex object(s) potentatially having numerous windows...
>
> For instance, a Scrollbar widget has at least 5 windows : the
> container, the 2 windows containing the arrows, the one containing the
> slider image, plus the one containing the area where the slider
> slides...
One could make a scrollbar that way, but a Motif scrollbar actually
has only one window. It draws the slider and arrows into a pixmap,
then copies the pixmap to its one window.
--
Fred K
Jano
I do not know for sure for the scrollbar widget, as I have not looked
through the source code how it is built, so I might have been
mistaken.. (and actually, as the libraries depend on systems, I am not
even sure there is a single implementation...). But I apologize for the
mis-representation of things if they are really implemented like that
in every distribution..
As a reminder, Motif is NOT an implementation protocol, but a high
level specification.
But the basic principle of widgets is this one... And most widgets are
complex, and moreover containers have themselves windows attached, so
almost any construction with xmFrame, xmForm, or xmRowColumn or
xmScrolledWindow or xmRadioBox, or xmList, or xmScale, etc etc have a
series of windows...
A very simple test is printing the result of a XQueryPointer ...
:-)
PS: a note to the OP
Also, the window(s) of the container(s) are often not viewable (they
are hidden by the windows of the widgets managed by the container)
--