TIMER events could get keymodifier set - in this case the user assigned
spacebar modifier for setting views (running smoothview timer)
Also: cleaned op old hacks from event checking code.
The rule should be:
1) generate event properly, frozen state
2) pass on to handlers without exceptions or changing internal state
The only exception currently is for the "CLICK" (map key-release to unhandled
key-press).
Also: made --debug-event print OK. Slight cleanup in eventprinting in general.
It was putting the wmEvent state print in wrong place, doing it 4 or 8 times.
(since 2010)
- Using 2-button mouse emulation (common for tablets)
- Press LMB, start painting, press ALT, release LMB
- This kept painting to run, since the release event was a MMB,
not handled by paint code.
For the french keyboard setting (AZERTY) on Windows, the '!' came back with winevent->type=312, winevent->ascii='!' and the ISTEXTINPUT only matched key codes up to 255. Now replaces with
ISKEYBOARD in wm_eventmatch.
Now modifier key press gets generated without having own modifier set.
Same happens for double clicks on modifiers.
This also fixes case: press shift twice first, modifier fails.
- Solved Modal Keymap hijack of event codes
(with note this should be coded better)
- Added dedicated state variable check_click in event to trigger it
All this in an attempt to get code understandable and predictable again. :)
This solves error like:
- editmode mesh
- select a vertex
- grab it, press control for grid snap
- on LMB assign, it also did an extrude.
not work.
This is a temporary fix to make button type work. I'll check on other cases
now too.
Best would be to have UI code return correct flags for whether it has
done something or not. This hasn't been coded really - so that's a todo for
a later cleanup there.
The modifier keys were getting own key as modifier :)
Made it not possible to use them for events.
Still open issue: for some reason modifer key 'press' gets swallowed.
Digging into that.
Double clicks were never working reliably in Blender - this mostly because
it wasn't a real event, but something generated in the handler code.
Now it is an actual event - meaning it always gets handled (if you have
a keymap item for it of course), but if there's no doubleclick handling
it treats the doubleclick as a normal click.
Also cleaned code. No recursion anymore.
Seems the issue was caused by G.is_break set to Truth on both escape
press and release. This ended up in situation when after press event
compositor was tagged to redraw and new job was started. On escape
release this compositor job was cancelled.
Made it so G.is_break is setting on escape press event only.
Add an optional ghost argument to set the new mouse location when un-grabbing. - without this the mouse would flicker at the old location before moving to the new location - when using the color picker for eg.
Additional changes:
- Option to the ndof menu letting you pick turntable/trackball independently
of the mouse viewport navigation style
- Option to change the rotation sensitivity separate from the panning
Holding shift + moving the ndof does just as before locking it to panning
Holding ctrl + moving will lock it to only rotation
Patch by Fredrik Hansson, thanks!
Reviewed by self and Mike Erwin.
This in fact had nothing to see with this operator or its fade option, reports were simply not shown when repeating an operator.
Carefully checked/tracked all calls to wm_operator_exec and WM_operator_repeat, and could not see any reason why this was this way, so I disabled this. Very easy to undo in case ugly problems arize (but I really do not expect any!).
