[Bf-committers] Continuous Grab vs Tablet
ideasman42 at gmail.com
Tue Nov 3 11:10:53 CET 2009
Its possible to know the source on each X11 event too, this is one way
we could try get it working better.
On Tue, Nov 3, 2009 at 10:53 AM, Damien Plisson <damien.plisson at yahoo.fr> wrote:
> Hi Matt,
> A few ideas on this tablet vs mouse :
> You can get tablet information asynchronously with GHOST_GetTabletData.
> And there is a field telling if the tablet is currently used or not
> ( tabletData->Active != GHOST_kTabletModeNone).
> Polling this to decide on entering grab mode in the triggering event
> handler (GKEY, transform manipulator, ...) may help ? Or placing this
> check inside the "Enter Warp" function ?
> Otherwise, at least on cocoa (I don't know for other platforms), for
> each mouse event, we can get its source (tablet or mouse).
> Hope this helps,
> Le 3 nov. 2009 à 08:28, Matt Ebb a écrit :
>> Continuous grab currently does not play well with tablet use, it
>> conflicts as the tablet is trying to set absolute mouse coordinates.
>> This becomes very apparent now it's on by default and causes some
>> pretty crazy behaviour: http://mke3.net/blender/devel/2.5/continuous_grab_tablet.mov
>> Ideally the two should play nicely - If continuous grab is enabled,
>> when it's a mouse event, the cursor should be warped, but when it's a
>> tablet event, it should leave the cursor alone.
>> In practice though it's a bit tricker, I had a look through the code
>> today and it seems the in the part of the Blender code which decides
>> whether to warp or not, the event is always sent without tablet
>> customdata. Looking at the event, it seems to be the event which
>> initiates the tool, i.e. GKEY.
>> So anyone have any ideas on solving this?
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers