Initially issue was caused by non-proportional edge slide patch in rev46927 which
had several wrong things:
- It introduced new events TFM_WHEEL_DOWN_EVT/TFM_WHEEL_UP_EVT which were defined
as per-bit OR between edge slide and proportional editing modal events, but
the issue is that modal events are not bit masks and that meant that new events
were defined as 20|24 and 21|25 which is a bit strange.
- Another this was caused by the fact, that keymap wasn't creating for some specific
transform modal keymap item -- it used to be tried to create single shortcut for
two different modal events, which isn't supported by keymaps and resulted by
artifacts in keymap editor interface (nodal event type was empty for wheel movements).
That was caused by different events used by modal keymap and defining shortcuts.
- Actual issue which prevented PgUP/PGDOWN to work was mixing using that new events
for wheel scrolling in switch statements which doesn't do bitmask check.
Solved by separating keymaps used for proportional editing and edge slide -- now
it's mouse Wheel for proportional editing and Alt-Wheel for edge slide. If someone
would want to have single shortcut for this two events it'll imply one of the follofing
things:
- Support poll function for shortcuts, so keymap would definitely know which
modal event to send to operator.
- Generalize TFM_MODAL_PROPSIZE_{UP, DOWN} and TFM_MODAL_EDGESLIDE_{UP, DOWN} so
they can share the same shortcut with current design of keymaps.
This commit adds some first building blocks for the two operators to work modally based on mouse input. To make their function easier, two hotkeys are introduced, Ctrl+B for bevel and I for inset.
TODO:
After discussion with Campbell, we would like to add scale-style line indicators for the operators. This is already done for transform operators but a new interface for mesh operations may have to be written using pieces from that code since, strictly speaking bevel and inset are not exactly "transform" operators.
Also, a better input method for inset is needed and more options exposed. The method implemented right now uses mouse move for thickness and ctrl-mouse move for depth. These are calculated using the distance of the selection center in screen space and the mouse position. While that may work and prevents abrupt changes in values when switching from thickness tweak mode to depth tweak mode, it limits the magnitude of values that can be put into the tool especially in small or large scale.
Alternatives until a better method is written include:
* use relative offset (works but may give strange results)
* tweak manually after the operation.
Have to use a ugly hack, as for pose bones, rotscale transform matrix is not always the same as translate one... :/
Adresses feature request [#30979] snapping: "align rotation with the snapping target" and pose-mode.
Was a bmesh todo, main issue was with shape keys, now disabled any changes to
the shape key data layer, and disabled the option altogether when editing
non-basis shape keys.
when a single face in a loop is hidden, loop cut will subdivide edges on both sides.
creating an edge between the hidden faces.
without this workaround the edge ends up hidden and selected.
added a check in BM_mesh_validate() for hidden/selected elements.
