kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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