afzal@cui.unige.ch (Afzal Ballim) (03/14/91)
from: dshr@eng.sun.COM (David Rosenthal) >> Is it possible to change the position of the mouse pointer through software? >> >It is possible to do so, but doing so is strongly deprecated. ... > >The point here is that the pointer is a shared resource between all the >clients. You may think its just fine for your client to randomly warp >the pointer. I may think so too. The user who ends up running your >client and mine together sees chaos as they both fight over where the >pointer should be. So, don't warp the pointer. Leave it to the user >to decide where it should be. Certainly one should not randomly warp the pointer around, however there are cases where pointer warping is necessary, and it is not just toolkit writers who may need to do it. For example, suppose you are writing a client which requires a choice be made on startup for proper functionality. In this case it seems to me reasonable to popup a menu of choices and warp the pointer to the menu. Sure, the rest of the functionality of the client should be defined such that until this choice is made a warning is given. However, the warping is a strong way of indicating to the user that the choice must be made. You might reply that the warning should suffice, and that the warping is anti-social. However, in my experience naive users find warning messages to make a choice, when they try any action in a widget, far more annoying than warping the pointer to a popup on startup. (Note: to minimise conflict with other applications, such warping as I mentioned above should only take place if the pointer is within the bounds of the top level window for the application. So, what one should do is have an entry action for the top level window which checks to see if the selection has been made, and if not pops up the popup (if not already popped up) and warps the pointer.) ______________________________________________________________________________ Afzal Ballim |EAN,BITNET,EARN,MHS,X.400: afzal@divsun.unige.ch ISSCO, University of Geneva |UUCP: mcvax!cernvax!cui!divsun.unige.ch!afzal 54 route des Acacias |JANET: afzal%divsun.unige.ch@uk.ac.ean-relay CH-1227 GENEVA,Switzerland |CSNET,ARPA: afzal%divsun.unige.ch@relay.cs.net
dshr@eng.sun.COM (David Rosenthal) (03/17/91)
> Certainly one should not randomly warp the pointer around, however there are > cases where pointer warping is necessary, and it is not just toolkit writers > who may need to do it. For example, suppose you are writing a client which > requires a choice be made on startup for proper functionality. In this case > it seems to me reasonable to popup a menu of choices and warp the pointer to > the menu. Sure, the rest of the functionality of the client should be > defined such that until this choice is made a warning is given. However, > the warping is a strong way of indicating to the user that the choice must > be made. You might reply that the warning should suffice, and that the > warping is anti-social. However, in my experience naive users find warning > messages to make a choice, when they try any action in a widget, far more > annoying than warping the pointer to a popup on startup. > > (Note: to minimise conflict with other applications, such warping as I > mentioned above should only take place if the pointer is within the bounds > of the top level window for the application. So, what one should do is have > an entry action for the top level window which checks to see if the > selection has been made, and if not pops up the popup (if not already popped > up) and warps the pointer.) This is not a sensible approach: 1. The client's top-level window appears some time after the action is taken to start the application. I hope you are not suggesting that when the client finally gets started it should randomly attempt to sieze the pointer away from whatever is happening then and pop something up. That would be seriously anti-social. It sounds to me as though you are stuck in PC/Mac thinking, where there is only one application running at a time and nothing else can happen between the user's actions to start an app and the time it grabs the screen, keyboard and mouse for its exclusive use. 2. Popups should be implemented by the toolkit. All toolkits I've seen implement them. So that if, in the particular user interface style the toolkit writer is implementing, warping the pointer to a pop-up is the right thing to do, the toolkit writer should do it. The toolkit writer should understand the need to grab the server when it happens, and all the other details. The application writer should *not* be trying to do this - they should use whatever popups are provided by their toolkit. 3. If the user tries to do something that doesn't work in the current state of the client, it is appropriate to popup a warning and prevent them from doing anything else until it has been dealt with. It is very anti-social to prevent them from doing anything with other clients while this happens. Thus, the grabs necessary to deal with pointer warping should be used with extreme caution because they may prevent the user working with anotehr application while you have the pointer warped. To repeat my original point - application writers should never warp the pointer. Toolkit writers may warp the pointer under controlled circumstances, such as when implementing popup warnings and scrollbars, but should always do it with the src-window set as required by the ICCCM. David.
rhl@grendel.Princeton.EDU (Robert Lupton (the Good)) (03/17/91)
I hate to disagree with David Rosenthal, but I think that the one use that I have for warping the pointer is legitimate.... I have some image display code that runs from an xterm, but creates an image display in a window of its own. If the user asks for a cursor display (by typing "cursor" to the xterm, in which resides the pointer) the pointer is warped to the image window and cursor mode is activated; when the cursor is no longer desired the pointer is warped back to where it started. No server grabs are needed. Robert
dshr@eng.sun.COM (David Rosenthal) (03/18/91)
> I have some image display code that runs from an xterm, but creates an > image display in a window of its own. If the user asks for a cursor display > (by typing "cursor" to the xterm, in which resides the pointer) the pointer > is warped to the image window and cursor mode is activated; when the cursor > is no longer desired the pointer is warped back to where it started. No > server grabs are needed. > It sounds to me like you are assuming "focus-follows-cursor" mode. Because your window has the input focus is no reason to believe that the pointer is in the window. Besides, a user interface that depends on the user typing into an xterm isn't taking full advantage of the capabilities of X. I think if you designed a real X user interface you would discover no need for pointer warping. For example, why don't I get a cursor display simply by moving the cursor into the image window. Saves typing :-) David.
david@lta.COM (David B. Lewis) (03/19/91)
> who may need to do it. For example, suppose you are writing a client which > requires a choice be made on startup for proper functionality. In this case > it seems to me reasonable to popup a menu of choices and warp the pointer to > the menu. Sure, the rest of the functionality of the client should be What do the various HCI guides say about positioning the dialog so that it's under the position of the pointer, where the user might be paying attention? (The center of the screen has always seemed to me to be a pretty arbitrary place to popup a message, anyway.)