On 3/1/2016 1:25 PM, Bernhard Stegmaier wrote: > I did that for a PC mouse with my Mac. > As I said in the beginning… Whoever does this, I get axis 0 when nothing > is pressed, and axis 1 when shift is pressed (using the same mouse, the > same mousewheel, no touchpad). > That’s why it only did scroll horizontal with the original code (obviously > only > on OS X).
It sounds like this is not what is happen on linux. We may have to normalize the axis/shift key behavior to account for platform differences. > > Of course, the axis is for things like touchpads and that’s exactly what gets > used in touchpad-panning mode. > That’s exactly what is the really nice thing about the automatic axis change: > With touchpad-panning the same piece of code works with a touchpad and > a normal mouse. > Unmodifed wheel scrolls up/down, shift-wheel scrolls left/right. > Kicad doesn’t have to know anything about which device is there, it just > works… :) > > >> On 01.03.2016, at 19:15, Wayne Stambaugh <stambau...@gmail.com> wrote: >> >> I believe the axis is for mice with multiple wheels where the 0 axis is >> the scroll wheel typically used for vertical scrolling. I do not >> believe the shift or control keys have anything to do with the axis in >> the wxMouseEvent but I have looked at the wxWidget code to see if that >> is the case. Perhaps there are some inconsistencies between platform as >> to what these axis mean. The easiest way to find this out is to trace >> the mouse events and see which axis is being sent in the wxMouseEvent >> inside the OnScroll function. >> >> On 3/1/2016 12:44 PM, Bernhard Stegmaier wrote: >>> Yes, but documentation doesn’t state anything about changing axis with >>> shift/ctrl (at least, I didn’t see it). >>> >>> If the non-touchpad scroll code shall ignore ignore any additional axis, >>> then the current implementation is wrong (it doesn’t ignore axis). >>> >>> Attached a patch to ignore axis in non-touchpad scroll code (as it was >>> before rev4505). >>> Therewith, also shift/ctrl panning again works on OS X (though it might not >>> conform to Apple UI guidelines where shift-wheel does a horizontal scroll). >>> >>> >>> Regards, >>> Bernhard >>> >>> >>> >>> >>> PS: >>> Mac users using a PC mouse and a Apple mouse in parallel might notice >>> that the >>> scroll direction of PC mouse is just the other way round than for Mac >>> mouse (and >>> maybe touchpad). >>> Yes. I don’t want to investigate if I can find out which device is >>> connected, so it >>> is as it is. Don’t use a PC mouse on a Mac… :) >>> >>>> On 29.02.2016, at 01:24, Wayne Stambaugh <stambau...@gmail.com >>>> <mailto:stambau...@gmail.com>> wrote: >>>> >>>> Take a look at the documentation for wxMouseEvent.GetWheelAxis()[1]. >>>> Some mice and/or trackpads can generate additional axis for horizontal >>>> scroll support. That's why the scroll code ignores any additional axis. >>>> Prior to 2.94, GetWheelAxis() returned an int where 0 was the vertical >>>> scroll. Now GetWheelAxis() returns wxMOUSE_WHEEL_VERTICAL and >>>> wxMOUSE_WHEEL_HORIZONTAL which are enums. I didn't look but I'm >>>> assuming they map to 0 and 1 but it would be more correct to use the >>>> enums rather than 0. >>>> >>>> [1]: >>>> http://docs.wxwidgets.org/3.0/classwx_mouse_event.html#a6e455a3fa3708031d8571e42489d453e >>>> >>>> On 2/28/2016 6:22 PM, Bernhard Stegmaier wrote: >>>>> Hi Garth, >>>>> >>>>> thanks for the link, do you remember what this patch does actually fix? >>>>> I just checked and the bug is closed… and is integrated both in current >>>>> 3.0.x branch and master (I am using master). >>>>> If I understand the ticket correctly, this fix is only about the >>>>> not-working event.skip() or some duplicate handling. >>>>> >>>>> So, even with this fix the current scrolling is broken due to (obviously >>>>> OS X only) change in axis when shift is pressed. >>>>> But, as you said, this might be on purpose, because it just leads to >>>>> consistent behaviour of how it is handled in native OS X applications >>>>> without having to change code or knowing which device is used. >>>>> >>>>> On OS X the only thing you would want to use is some Apple device with >>>>> touchpad-panning anyway… :) >>>>> >>>>> I still would consider this a wxWidgets bug, because I would expect that >>>>> a platform-independent application framework doesn’t show different >>>>> platform specific behavior like this… but that’s another story. >>>>> >>>>> Anyway… this still leaves the question open on how to fix it - assuming >>>>> that a consistent KiCad behavior on all platforms is the goal. >>>>> Change axis back on OS X or remove the piece of code that checks axis >>>>> (if somebody can remember why it is done this way)? >>>>> It came in with >>>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4505 >>>>> … but there is no hint why this was changed. >>>>> >>>>> >>>>> Regards, >>>>> Bernhard >>>>> >>>>>> On 28 Feb 2016, at 23:18, Garth Corral <gcor...@abode.com >>>>>> <mailto:gcor...@abode.com> >>>>>> <mailto:gcor...@abode.com>> wrote: >>>>>> >>>>>> Hi, Bernhard >>>>>> >>>>>> Yes, you have it right on both counts. That was, and still is, my >>>>>> assessment. The existing behavior is not correct, at least as far as >>>>>> OS X (and probably Linux) is concerned. I don’t know about windows. >>>>>> That is the patch that fixes the issue to which I referred in that post. >>>>>> >>>>>> I think it might be this issue: >>>>>> >>>>>> http://trac.wxwidgets.org/ticket/15684 >>>>>> >>>>>> >>>>>>> On Feb 28, 2016, at 11:25 AM, Bernhard Stegmaier >>>>>>> <stegma...@sw-systems.de >>>>>>> <mailto:stegma...@sw-systems.de> <mailto:stegma...@sw-systems.de>> >>>>>>> wrote: >>>>>>> >>>>>>> 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 >>>>>>>> <mailto:stegma...@sw-systems.de> <mailto: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); >>>>>>>> } >>>>>>>> elseif(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); >>>>>>>> elseif(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 >>>>>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>>>>> <mailto: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 >>>>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>>>> <mailto: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 >>>>> <mailto: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 >>>> <mailto: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
