kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #23490
Re: Legacy Canvas Mousewheel Behavior?
2016-02-28 20:25 GMT+01:00 Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>:
> 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.
I think it would be best to check this with the upstream wx developers
and then I guess it would be fine to include your "fault tolerant"
code, but use a wx version check such that it is easier to identify
for removal once we move to the minum version of wx that supports the
fix.
> Regards,
> Bernhard
>
> On 28 Feb 2016, at 19:33, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References