kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2015-04-02 20:57 GMT+02:00 Garth Corral <gcorral@xxxxxxxxx>:
> Thanks, Nick.  If you can point me to a build of this I will do what I can to look into the issues reported by Wayne.  Next week will be very difficult for me to do this but I’ll try to get to it the following week.
>
> Just to clarify, here are the issues reported by Wayne:
>
>     * The Ctrl+mouse wheel behavior is completely broken on windows and I
>     suspect Linux as well when the use mouse wheel to pan option is set.  It
>     acts just the Shift+mouse scroll wheel (scroll vertically).  This needs
>     to be fixed.  The default behavior should always remain the same across
>     platforms.  It can be OSX specific compiled code or a configurable
>     option but breaking the current behavior on other platforms is not an
>     option.
>
>     * The Ctrl+wheel mouse when the use mouse to pan option is not set
>     (zoom) periodically freezes.  I seems to come back when I perform some
>     other function that updates the display but the exact cause I cannot say
>     for sure.

Could this be related to (fixed) in 5012 "Fix OpenGL canvas freeze
under Windows." ?

>     I did not get a chance to try it out on a laptop to test the track pad
>     behavior.  It definitely needs some work before it can be committed to
>     the product branch.
>
>
> If I’m understanding the first issue (and I may well not be), Wayne is saying that the panning direction is the reverse of his expectation when using either shift or control modified mousewheel.  I’ll certainly look at this to ensure it isn’t something else. If it’s true, though, then this was an intentional decision on my part that was explained in the commit message that I reposted on the list.
>
> 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). This may not be true for windows and Linux, but I suspect that it is. In that case the existing behavior for those platforms would be wrong as well.  It doesn’t matter so much if you have a wheel that only moves vertically; the decision about which way to pan in that instance is somewhat arbitrary.  It becomes readily apparent, however, when the events can be generated by either vertical or horizontal physical motion.
>
> The second issue is definitely worrisome.  It is also interesting because I didn’t change any of the mousewheel zoom code (though I probably should have).  I will attempt to determine a root cause if possible, with the build that you provide.
>
>
> Thanks, again.
>
> Garth
>
>> On Apr 2, 2015, at 9:11 AM, Nick Østergaard <oe.nick@xxxxxxxxx> wrote:
>>
>> 2015-04-02 18:06 GMT+02:00 Garth Corral <gcorral@xxxxxxxxx>:
>>> In response to your previous comments, Wayne, I said:
>>>
>>> "I can’t guarantee that I’ll be able to do anything, but I will try.
>>>
>>> I have no Windows or Linux  machines so if someone could provide me a Windows binary of the trackpad branch maybe I can beg or borrow a box to at least observe the behavior.  I won’t have a Windows development environment so I’ll just have to hope I can see something by inspection."
>>>
>>> I got no response.
>>>
>>> I haven't observed this behavior so it makes it a bit difficult to fix.  There’s nothing in the code that should be pointing device specific so could be down to anything.  I will still take a look if I can get something to look at.  Are there any OS X developers out there with a windows development setup?
>>
>> I can try to make a windows build with your patches.
>>
>>> It’s not impossible or even difficult to make it conditional but it would be ugly; the patch was written with the idea of being merged as some point.  It isn’t the gestures, per se.  The main change is that since the panning gesture presents itself as a mousewheel event, the mousewheel panning code was changed to give a better experience.  There’s also the issue of the preferences.
>>>
>>> At this point perhaps I should just change this to be conditionally compiled, as ugly as it may be.  At least OS X users would get a usable pointing device.  I did, by the way, test this on OS X with several alternative third-party devices, including mice of various sorts and trackballs.  I never observed anything like that described.
>>>
>>>
>>> Garth
>>>
>>>
>>>> On Apr 2, 2015, at 6:54 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>>>
>>>> I've commented on this before.  It breaks zoom and pan behavior on
>>>> windows and linux so it cannot be committed until it is fixed.  I don't
>>>> have an issue with providing nightly osx builds for users to test but I
>>>> would tread carefully here.  It seems that some osx users are using
>>>> alternate pointing devices with success so while you may fix one users
>>>> problem you may create a problem for another user.  If you choose to
>>>> create nightly builds with this patch, please make sure you label the
>>>> build as such so users can choose accordingly.