kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

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).

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 <stambaughw@xxxxxxxxx> 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 <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> 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 <gcorral@xxxxxxxxx
>>>>> <mailto:gcorral@xxxxxxxxx>
>>>>> <mailto:gcorral@xxxxxxxxx>> 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
>>>>>> <stegmaier@xxxxxxxxxxxxx
>>>>>> <mailto:stegmaier@xxxxxxxxxxxxx> <mailto:stegmaier@xxxxxxxxxxxxx>>
>>>>>> 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
>>>>>>> <stegmaier@xxxxxxxxxxxxx
>>>>>>> <mailto:stegmaier@xxxxxxxxxxxxx> <mailto: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);
>>>>>>> }
>>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>>> <mailto: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
>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>> <mailto: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
>>>> <mailto: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
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>