After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710770 - Fix Screen cursor movement
Fix Screen cursor movement
Status: RESOLVED FIXED
Product: mousetrap
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Logan H
mousetrap-maint
Depends on:
Blocks:
 
 
Reported: 2013-10-24 01:14 UTC by Scott Cunningham
Modified: 2014-09-13 02:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A partial fix to bug, that prevents MouseTrap from crashing with Screen enabled (1.49 KB, patch)
2013-12-05 04:49 UTC, Logan H
none Details | Review

Description Scott Cunningham 2013-10-24 01:14:21 UTC
Currently the mouse will move sarcastically within a small area of the screen and seems to snap back to its original location as the user moves their head.

We need to fix the cursor movement so that it will move as the user turns their head(up, down, left, right, or diagonally).  The further to any of the previously listed directions the user moves their head, the further the cursor should move across the screen.  The cursor should stop moving when the user stops rotating their head(allowing them to hold the cursor at any point of the screen, as long as their head remains idle).  If the user moves their head back towards the center of the screen, the cursor should move back with them.
Comment 1 Logan H 2013-12-05 04:49:23 UTC
Created attachment 263560 [details] [review]
A partial fix to bug, that prevents MouseTrap from crashing with Screen enabled

This is a partial fix to screen.py. The only change in this patch was to prevent MouseTrap from crashing when Screen was selected. "expose_event" in connect was replaced with "draw". 

While "draw" is the new "expose_event" connect event, the expose_event function still is not getting called. Since the function isn't getting called, the cursor movement isn't occurring. This function may not be getting called because of an issue with the Mapper class, and the "expose_event" not being connected properly to gtk to be launched. The issue may also be resolved once tracking is resolved. It appears that the following function from lkpoints may trigger the events to happen, in which case, screen won't work until lkpoints in properly tracking and triggering events.