SourceForge has been redesigned. Learn more.
Close

#19 glutLockPointer/glutUnlockPointer

open
nobody
Easy (28)
5
2003-12-03
2003-12-03
No

> Most problematic thing is to keep cursor inside
> certain window. (Maybe this is implemented
> already, it isnt in old glut). Using glutWarpPointer
> is really annoying because f.e. while loading big
> files you can easily move mouse outside window
> (or subwindow which is my program case).
> Something like glutLockPointer(int x, int y)
> would be very handy.
> Misiek

The proposal here is that the mouse pointer can
be locked to a fixed position until something
time consuming happens and it can be unlocked.

void glutLockPointer(int x, int y);
void glutUnLockPointer();

We would need to check that this can be
reasonably implemented on various platforms
and that non-mouse controls (alt-tab etc)
are not affected.

Discussion

  • Richard Rauch

    Richard Rauch - 2003-12-03

    Logged In: YES
    user_id=854844

    I suggest locking to a window rather than to a position.
    The former should be easier to do on at least some systems.
    Alternatively, make glutLockPointer() sufficiently vague
    that it can encompass both approaches.

    "Non-mouse controls" is a bit vague. Do you mean controls
    of the pointer? Or of the input focus? Or controls that
    inject fake (fairly low-level) mouse events into the OS
    input stream?

     
  • Nigel Stewart

    Nigel Stewart - 2003-12-07

    Logged In: YES
    user_id=338692

    To clarify what I mean about "non-mouse controls" -
    locking the mouse pointer should not interfere with other
    applications accessed via the "usual" mechanisms -
    Keyboard shortcuts, etc...

     
  • Richard Rauch

    Richard Rauch - 2003-12-08

    Logged In: YES
    user_id=854844

    Hm. I confess that I don't feel particularly enlightened,
    yet. Just application controls, or also
    system/"other-application" controls? (E.g., on X, I run a
    window manager called "twm" by which I have arranged to
    cycle through xterm windows, emacs windows, and a few other
    window types, with certain key-presses. This isn't part of
    the window system, per se, but it is not part of the
    application. Using this, I can change which window is
    front-most, has the focus, and has the pointer over it. Is
    *this* allowed if we have grabbed/locked the mouse?)

    Maybe I should make a stab at what I think to be a
    clarification, and you can correct it where you feel my
    suggestion is wrong:

    When the pointer is "grabbed" to a window or location by the
    application, this will only affect pointer-motion and
    input-focus. The input focus will be rooted to the current
    window, and the pointer will either be fixed to the one spot
    (pixel coords relative to the window) or will be allowed to
    roam freely within the current window but not beyond the
    window's borders.

    It is specifically left undefined what shall happen if the
    user employs an OS feature or system tool to let them change
    the mouse position or window input focus by other than
    normal pointer motion.

    Grabbing the pointer is intended to be a convenience to the
    user (e.g., in a mouse-controlled game, it may be very
    frustrating to move the mouse off of the edge of a window
    and suddenly lose control of the game until bringing the
    mouse back). It is not intended to be either an albatros
    around the library's neck, nor shackles on the user who may
    sometimes truly wish to otherwise use the system without
    killing the application. (Indeed, it is impossible in many
    XFree86 systems to completely stop the user who may switch
    to another virtual console and run another copy of XFree86.)

    The impact on GUI elements is also unspecified, and the
    developer is discouraged from using this in combination with
    buttons, multiple windows, or menus. [This adminishment may
    be lifted in time, but since the primary envisioned value of
    this feature is for game-like environments with a single
    window and direct interaction with the pointer, it is not
    expected that menus or other GUI elements will be of use.]

    The virtue in such a loose specification is that it is hoped
    to cover most, maybe even all, uses while at the same time
    leaving latitude for efficient and simple implementation.
    Also, by disclaiming responsibility for details, freeglut is
    free to clamp down in more particular ways, in the future,
    should that prove desirable---and it is hoped that it could
    be done without violating this spec (hence without breaking
    applications that are correctly written).

    ...now, I surely have left at least as much unspecified as
    you intended (probably a good deal more), but they are
    *specifically* unspecified. (^& If you feel that things
    that I left unspecified really should be laid out in more
    detail, feel free to do so.

     
  • Nigel Stewart

    Nigel Stewart - 2003-12-16

    Logged In: YES
    user_id=338692

    As a refinement to this proposal:

    void glutLockPointer(int enable);

    If enabled, prevents the mouse cursor being moved
    within the current window. No mouse events will
    be received by the window and the cursor will remain
    stationary. If disabled, normal mouse cursor interaction
    will resume, including mouse events. This setting only
    affects the current window.

    No need for glutUnlockPointer in the API.

     

Log in to post a comment.