[comp.windows.x] InputOnly Curiosity

seth@ZURICH.AI.MIT.EDU (Seth Goldstein) (02/09/90)

Does anyone have a concrete example of where you'd use an InputOnly
window?

david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (02/10/90)

seth@ZURICH.AI.MIT.EDU (Seth Goldstein) writes:
>
>Does anyone have a concrete example of where you'd use an InputOnly
>window?

Lay one over another window to do special input processing.

Contrived Example: Add the ability to pop-up a new kind of menu to xterm.

Hack main() to create an input only window over the existing xterm
window.  Add event handlers to catch mouse button events on that
input only window.

converse@EXPO.LCS.MIT.EDU (Donna Converse) (02/10/90)

> Does anyone have a concrete example of where you'd use an InputOnly
> window?

see Scheifler Gettys & Newman page 30:

	InputOnly windows are used for controlling input events in situations
	where InputOutput windows are unnecessary.  InputOnly windows are 
	invisible; can only be used to control such things as cursors, input 
	event generation, and grabbing; and coannot be used in any graphics
	requests.

At certain times, xmh maps an InputOnly window which does not propagate 
key and pointer events, preventing the user from sending events to xmh's
interface.  The window is intended to protect against the problem of the
user initiating a function multiple times because the the interface has a
slow response.  It is an economical way to temporarily ignore events.
The default cursor of this window looks like a wrist watch, which cues the
user to wait with the knowledge that something is indeed happening.


Donna Converse
converse@expo.lcs.mit.edu

jeff@rtech.com (Jeff Anton) (02/10/90)

Sure.  Say I have a program that draws some objects on a window, and
then I want the cursor to change when it is moved near an object.
Either each object can be its own InputOutput window with a different
cursor or you can put an InputOnly window with a different cursor
on top of the object.  The same thing is useful for detecting mouse
presses.  Without subwindows, you would have to track or query
the mouse position all the time and change the cursor manually.
					Jeff Anton

rick@hanauma.stanford.edu (Richard Ottolini) (02/10/90)

In article <7037@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes:
>seth@ZURICH.AI.MIT.EDU (Seth Goldstein) writes:
>>
>>Does anyone have a concrete example of where you'd use an InputOnly
>>window?

Hidden "Hot spots" for Hypertext/HyperCard like functions.

dpb@viking.UUCP (Don Bennett 433-3311, 408) (02/10/90)

> Does anyone have a concrete example of where you'd use an InputOnly
> window?

Once upon a time, I had a window that I didn't want the window
manager to iconify.  To prevent an icon from ever appearing on the 
screen, I used an input-only window as the icon-window hint, so
that when the icon window was mapped, you wouldn't see it on the screen.

That's probably no longer the right thing to do. 
(Not that it ever was, but it worked...)

   Don Bennett           (408)433-3311
   dpb@frame.com
   Frame Technology

mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (02/12/90)

> Does anyone have a concrete example of where you'd use an InputOnly
> window?

Certainly.  My window manager wants to display one of nine different
cursors during a resize operation, depending on which ninth of the
window the mouse is in.  I create ten InputOnly windows, one of which
blankets the window to be resized, with the other nine tiling the big
one (the nine are children of the one).  Each of the nine has its
cursor set appropriately; I then grab the mouse with the one as the
confine-to window.  Then the server automatically handles restricting
the mouse to the area desired and changing the cursor to match which
ninth of the area it's in.

It might be possible to get the same effect with InputOutput windows
with backgrounds of None and border-widths of zero, but I'm not sure
the semantics would be quite right.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

smarks@eng.sun.COM (Stuart W. Marks) (02/13/90)

| Once upon a time, I had a window that I didn't want the window
| manager to iconify.  To prevent an icon from ever appearing on the 
| screen, I used an input-only window as the icon-window hint, so
| that when the icon window was mapped, you wouldn't see it on the screen.
| 
| That's probably no longer the right thing to do. 
| (Not that it ever was, but it worked...)
| 
|    Don Bennett           (408)433-3311
|    dpb@frame.com
|    Frame Technology

You're right, this is absolutely the wrong thing to do!  Not only is it
unlikely to work with many window managers, it's also illegal.  Section
4.1.9 of the ICCCM, "Icons," says:

    Convention: The icon window should be an InputOutput child of the root.

In general, there's no way to prevent the window manager from giving one
of your windows an icon.  That's up to the window manager.  However,
setting the WM_TRANSIENT_FOR hint might do what you want.

s'marks

Stuart W. Marks			ARPA: smarks@eng.sun.com
Window Systems Group		UUCP: sun!smarks
Sun Microsystems, Inc.