Sigh, I only replied to Nick.
Begin forwarded message:
From: Garth Corral gcor...@abode.com
Date: April 2, 2015 at 11:57:03 AM PDT
To: Nick Østergaard oe.n...@gmail.com
Subject: Re: [Kicad-developers] Bob's Mac Usability Problems
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.
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.n...@gmail.com wrote:
2015-04-02 18:06 GMT+02:00 Garth Corral gcor...@abode.com:
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 stambau...@gmail.com 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
