Got it. Thanks. Garth
> On Apr 3, 2015, at 5:19 AM, Nick Østergaard <oe.n...@gmail.com> wrote: > > Hi Garth > > Please try out the new build I have made. It is made against your > branch, hence the lower revision number. > > http://www2.futureware.at/~nickoe/kicad-osx-trackpad-gestures-r5277.5c2b56a-i686.exe > > Nick > > P.S. you sent this only to me, but I think it contain way too much > information to miss the list. > > 2015-04-02 20:57 GMT+02:00 Garth Corral <gcor...@abode.com>: >> 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 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. >>>>> >>>>> I don't understand the difficultly in modifying the patch to either be a >>>>> build time option or a run time option. How hard would it be to use >>>>> something like wxPlatform to check if osx is the platform and a user >>>>> option to enable/disable the osx gesture support. Something like: >>>>> >>>>> if( (wxPlatform::Get().GetOperatingSystemId() & wxOS_MAC) >>>>> && enableOSXGestures ) >>>>> { >>>>> perform OSX gesture specific behavior >>>>> } >>>>> else >>>>> { >>>>> perform the existing behavior >>>>> } >>>>> >>>>> If speed is an issue, you can keep the wxOperatingSystemId in memory >>>>> rather than checking it every time. >>>>> >>>>> On 4/2/2015 9:34 AM, Adam Wolf wrote: >>>>>> I don't want to make that choice. I will leave that up to Wayne. >>>>>> >>>>>> I will support making builds of whatever he chooses. >>>>>> >>>>>> Adam Wolf >>>>>> >>>>>> On Apr 2, 2015 9:31 AM, "Tomasz Wlostowski" <tomasz.wlostow...@cern.ch >>>>>> <mailto:tomasz.wlostow...@cern.ch>> wrote: >>>>>> >>>>>> On 02.04.2015 11:01, Bernhard Stegmaier wrote: >>>>>>> For me, this is still the reason why KiCad without Garths panning >>>>>> patches is just a no-go on OSX. >>>>>> Adam, Wayne, >>>>>> >>>>>> I guess there's no problem with merging these patches to the Mac stable >>>>>> release, especially since we need to build a patched wxWidgets version >>>>>> anyway? >>>>>> >>>>>> Cheers, >>>>>> Tom >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
