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.
Issue was caused by generated images had got no profile set (IB_PROFILE_NONE)
which confused OpenEXR saver (which makes sRGB conversion for profiles which
are not linear).
Actually this is much deeper issue which would require the whole color pipeline
workflow (which would happen at some point when currently urgent stuff is resolved),
but having correct profile set for generated images would still be helpful.
from Jason Wilkins (jwilkins)
only applied some parts:
* const correctness
* moved a variable into a move local scope so it is also inside a #if/endif and does not end up conditionally unused
Issue was introduced by yesterday's commit 47021 and caused by some handler's
which is getting called from ui_handler_popup frees event.
Worked around a bit by storing return value for ui_handler_popup before running
other handlers, but this only means global refactor of even handling order is
getting closer and closer.
- previous commit was so similar to the patch Shinsuke wrote, better to add him as contributor, this commit will add to generated credits.
- this commit has no functional changes.
Do not block EVT_DROP event from popup handler.
Not ideal solution sine it'll be much nicer to cleanup event handling order,
but should be acceptable for now.
