don@BRILLIG.UMD.EDU.UUCP (03/27/87)
I've got a copy of the Xtool distribution, and I've compiled it on a
Vax running 4.3BSD. I'm running the V10R4 server on a Sun 3/160.
There seems to be a problem with "xtools" (The program that starts
things up for you when you run the server, not the X Toolkit.)
grabbing mouse button events that clients using the "Xtool" library
should be getting.
When I run, for example, demo1, and press and release the middle mouse
button in the "Press Me" button, an xtools menu pops up and "Repaint
screen" gets selected from it, and the XToolkit button does not get
pressed. If I press and release the middle button rapidly, xtools
refreshes real hard, and some times the button events get through to
demo1, and "Button Pressed" is printed out. When ever I move the
mouse into the "Press Me" button, it is highlighted. When I press any
button in it, it is un-highlighted, and in the case of the middle
button, the xtools menu pops up. When I release it, the highlighting
returns. When I move out, the highlighting goes away. This is the case
with all the buttons in demo1, demo2, and xedit. All the buttons
work fine when I am not running xtools.
To start the server, a shell script sets DISPLAY and runs "xinit
xtools", and the "xtools" puts its silly little box with an X in it in
the upper right corner of the screen, and grabs buttons events on that
window and the root window. When it gets a middle button, it puts up a
menu using XMenu.
When xtools selects input from the root window, it goes:
XSelectInput(RootWindow, ButtonPressed | ButtonReleased);
When xtools selects input from the little xtools window (with the
"X"), it goes:
XSelectInput(ToolWindow, ButtonPressed | ButtonReleased |
ExposeWindow);
When xtools calls XMenu, it goes:
status = XMenuActivate(menu, &pnum, &snum, x, y,
MiddleMask | ButtonReleased, (char **)&val);
Another thing is that when I rapidly stretch demo2 around, between
sizes that require different button configurations, several times in
quick succession, it causes the geometry managers to become confused,
and it starts oscillating between two button arrangements, and won't
stop. This is easy to reproduce, by pressing some button many times in
succession (demo2 does a sleep(1) after each press so it's easy to
get ahead of), and immediately stretching it to two very different
sizes.
Other than those problems, what I've seen of the toolkit looks real
good. "xedit" gives a flash of deja vu, and a nice demo of Xtoolkit's
capabilities. ("X is not a verb, either!")
I understand that this code is some what of a prototype, and that,
as the cry of the X implementors goes, I should "Just wait till V11!".
I do however want to start working on some widgets of my own right
now, and would like to know how safe it is to base my code on the
internals of other widgets in the current version of Xtool. What I
would really appreciate is information about which parts of XTool are
shaky prototypes that are going to be redone in time, and which parts
are good firm starting points, likely to stay pretty much the way they
are.
Thanks a lot!
-Donken@rochester.UUCP (04/03/87)
I wrote xtools and I agree it is a hack. As an X novice at that time I was not aware of the ramifications of grabbing events from the root window. It has served me well enough, though. I might go over to Ed Moy's xinit with startup file ~/.xinit (one less process). In any case I have no further intention of doing anything more with xtools. Anybody is welcome to trash it or improve it as they wish. Ken