stein@spot.wbst128.xerox.com (Adam Stein) (10/09/90)
Since the 'Save Screen' command in OpenWindows is hardcoded to the filename
it saves in (which is very inflexible), I thought I would whip up an X
version of Sunview's toolplaces (it finds out the locations of the windows
on your desktop and associated icons). Please let me know if this has already
been done so I don't reinvent the wheel.
By using xlswins, xprop, and xwininfo I can get all the information I need.
Now comes the problem. WM_COMMAND is set only for a public domain program
I have (calctool). For OpenWindow's programs (clock, shelltool, perfmeter)
WM_COMMAND isn't set. Does anybody know of a way I can find out what command
was executed with which window? Contool 3.0 also doesn't set WM_COMMAND
but at least I can change that. I can't modify any of the programs that
come with OpenWindows. Thanx for any help in advance.
Adam Stein
Adam Stein @ Xerox Corporation Email: stein.wbst129@xerox.com
stein@arisia.xerox.com
Disclaimer: Any/All views expressed ...!uunet!xerox.com!stein.wbst129
here have been proved to be my own. Hopefully one of the above will work.hsu@eng.umd.edu (Dave "bd" Hsu) (10/09/90)
In article <546@spot.wbst128.xerox.com> stein@spot.wbst128.xerox.com (Adam Stein) writes: >... I thought I would whip up an X >version of Sunview's toolplaces ... >Now comes the problem. WM_COMMAND is set only for a public domain program >I have (calctool). For OpenWindow's programs (clock, shelltool, perfmeter) >WM_COMMAND isn't set. Does anybody know of a way I can find out what command >was executed with which window? I tried emailing you directly, but nslookup can't resolve your address, xerox.com (at PARC) can't either, and following the mail path backwards (uhura.cc.rochester.edu!rochester!spot!spot.wbst128.xerox.com!stein) died when rochester didn't know who spot was. Y'all need to do something about your mail address. I believe the answer to your problem lies in the ICCCM...it includes a convention for reporting exactly this sort of information, and the Open- Windows tools are supposed to be ICCCM compliant. The main problem I see with this idea is that some popular X clients (who shall remain nameless but whose initials are x.t.e.r.m.) are notoriously non-compliant, so you'll probably have to combine techniques. -dave -- Dave Hsu Systems Research Center, Building 115 (301) 405 6594 hsu@eng.umd.edu The Maryversity of Uniland, College Park, MD 20742-3311 "A book?" "That's right. When I was your age, television was called books. This is a special book..."
toml@ninja.Solbourne.COM (Tom LaStrange) (10/09/90)
|> By using xlswins, xprop, and xwininfo I can get all the information I need. |> Now comes the problem. WM_COMMAND is set only for a public domain program |> I have (calctool). For OpenWindow's programs (clock, shelltool, perfmeter) |> WM_COMMAND isn't set. Does anybody know of a way I can find out what command |> was executed with which window? Contool 3.0 also doesn't set WM_COMMAND |> but at least I can change that. I can't modify any of the programs that |> come with OpenWindows. Thanx for any help in advance. Speaking of WM_COMMAND, it sure would be nice if XView clients would also set WM_CLASS. Anyone from Sun listening? -- Tom L.
hsu@eng.umd.edu (Dave "bd" Hsu) (10/10/90)
In article <1990Oct9.023620.17172@eng.umd.edu> hsu@eng.umd.edu (Dave "bd" Hsu) writes: >In article <546@spot.wbst128.xerox.com> stein@spot.wbst128.xerox.com (Adam Stein) writes: >>Now comes the problem. WM_COMMAND is set only for a public domain program >I believe the answer to your problem lies in the ICCCM... Duh. Okay, so I'm a very green novice. Send a WM_SAVE_YOURSELF first to force WM_COMMAND to be set. -dave -- Dave Hsu Systems Research Center, Building 115 (301) 405 6594 hsu@eng.umd.edu The Maryversity of Uniland, College Park, MD 20742-3311 "A book?" "That's right. When I was your age, television was called books. This is a special book..."
) (10/11/90)
XView programs don't initially set the WM_COMMAND property as is required by the ICCCM. This is a bug. They do set this property in response to a WM_SAVE_YOURSELF message, so sending this message works around the problem effectively. (All XView applications ask for WM_SAVE_YOURSELF.) In any case, it's probably a good idea to send WM_SAVE_YOURSELF to those clients who have requested it before you collect their WM_COMMAND properties. It will ensure that the command string is up to date. On a related note, stan!ninja!toml@uunet.uu.net (Tom LaStrange) writes: > Speaking of WM_COMMAND, it sure would be nice if XView clients would also > set WM_CLASS. Anyone from Sun listening? Yes I'm listening. It is true that XView doesn't set WM_CLASS. It should. s'marks Stuart W. Marks ARPA: smarks@eng.sun.com Windows & Graphics Software UUCP: sun!smarks Sun Microsystems, Inc.