What patch? Did I miss an email in this thread at some point? On 3/1/2016 1:42 PM, Bernhard Stegmaier wrote: > With my patch it should behave the same way on all platforms. > It just does ignore axis then… > > GAL does things already differently and apparently it is fine on > Windows/Linux > and Mac with that code. > So, just using my patch should be the easiest way to get things consistent > again > on all platforms for now. > >> On 01.03.2016, at 19:35, Wayne Stambaugh <stambau...@gmail.com> wrote: >> >> 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
