FYI, meanwhile I found an old mail from Garth on this topic (March last year):
<<<
Shift-modified scrollwheel events in wxWidgets (at least on OS X) have their
axis modified (by wxWidgets) to be horizontal. This matches the behavior of
native OS X applications as well. So making shift-scrollwheel do vertical
scrolling is wrong (and exposed a wxWidgets bug for which I committed a patch).
>>>
Maybe it is this patch
patches/wxwidgets-3.0.0_macosx_scrolledwindow.patch
but I didn’t find a wxWidgets bug for it…
So, regardless if the scrolling direction with shift is right or not, another
wxWidgets bug… should we keep on patching wxWidgets (and file a bug report and
hope for the best)?
The change I proposed below would at least make it fault tolerant without any
additional workaround code.
Regards,
Bernhard
> On 28 Feb 2016, at 19:33, Bernhard Stegmaier <stegma...@sw-systems.de> wrote:
>
> Hi,
>
> while testing the touchpad-panning for the recent 3d-viewer fixes I noticed,
> that non-touchpad-panning using shift/ctrl-wheel and a normal PC mouse seems
> to be broken on OS X with legacy canvas.
>
> It only pans horizontal regardless whether you press shift or ctrl.
> This is already the case in the official 4.0.1, so it has nothing to do with
> my changes.
>
> Debugging this I noticed that obviously wxWidgets or OS X change the wheel
> axis from vertical (0) without shift (or, while pressing ctrl) to horizontal
> (1) when pressing shift.
>
> So, this piece of code (draw_panel.cpp, line 985ff):
>
> if( event.ShiftDown() && !event.ControlDown() )
> {
> if( axis == 0 )
> cmd.SetId( ID_PAN_UP );
> else
> cmd.SetId( ID_PAN_RIGHT );
> }
> else if( event.ControlDown() && !event.ShiftDown() )
> cmd.SetId( ID_PAN_LEFT );
>
> will do a pan left/right when shift is pressed (because axis==1) instead of
> horizontal as it should.
>
> Question is… why is this “if( axis == 0 )” in there (and, only for the shift
> case)?
> Any special purpose?
>
> Of course, I could fix this by adding a OS X specific #ifdef, which reverts
> the change of the axis on shift being pressed.
> However, if the axis would be just ignored in the shift-case like in the
> ctrl-case, it would work without any #ifdef (not tested):
>
> if( event.ShiftDown() && !event.ControlDown() )
> cmd.SetId( ID_PAN_UP );
> else if( event.ControlDown() && !event.ShiftDown() )
> cmd.SetId( ID_PAN_LEFT );
>
> That’s basically what GAL does (ignoring axis, just looking at shift/ctrl
> modifiers) and that’s why it works there.
> However, I don’t know if any intended functionality gets lost with that
> change.
> Maybe something like touchpad-panning when pressing shift, but zoom without
> any modifier?
>
>
> Regards,
> Bernhard
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
