Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 4, 2015, at 8:15 AM, Bob Gustafson bob...@rcn.com wrote: Testing report on this nightly build: Application: kicad Version: (2015-04-03 BZR 5572)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.54.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_WXPYTHON=ON USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF This is the latest OS X nightly build from Adam - http://downloads.kicad-pcb.org/osx/DEBUG/ http://downloads.kicad-pcb.org/osx/DEBUG/ In the pcbnew window, the scripting console seems to work fine (It responds to ‘help()’ ) I don’t think it has the trackpad patches installed yet, but the pcbnew and eeschema windows do pan horizontally in response to CMD - two finger move on the trackpad. pcbnew does this in all three view modes (default, OpenGL, and Cairo). The OpenGL mode has the smoothest motion. The panning direction is opposite to the direction of two finger panning in other Mac applications. Also, adding the shift key - shift CMD two finger move, I was expecting the panning motion to be up-down, but it is actually panning on a 45 deg angle NW-SE in the pcbnew window. This key combination gives in-out zoom on the eeschema window. I believe the diagonal panning is the wxWidgets bug that I was talking about in my most recent response to Nick, which he forwarded to the list. It exposed the fact that wxWidgets changes the axis on shifted mousewheel events and is the reason that I reversed the shift and cmd modifiers for horizontal and vertical panning in my branch. Well, that plus the fact that every other Mac application on the planet uses shift for horizontal scrolling. Regular nightly builds of the product branch would need wxwidgets-3.0.0_macosx_scrolledwindow.patch applied to fix this, which i sent to the list some time back and Wayne committed. Garth The grid dots disappear in the OpenGL mode. It might be useful to have a check mark appear on the View menu to indicate which of the view modes is being used at the moment. - Solid progress - thanks much to all. ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Testing report on this nightly build: Application: kicad Version: (2015-04-03 BZR 5572)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.54.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_WXPYTHON=ON USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF This is the latest OS X nightly build from Adam - http://downloads.kicad-pcb.org/osx/DEBUG/ In the pcbnew window, the scripting console seems to work fine (It responds to ‘help()’ ) I don’t think it has the trackpad patches installed yet, but the pcbnew and eeschema windows do pan horizontally in response to CMD - two finger move on the trackpad. pcbnew does this in all three view modes (default, OpenGL, and Cairo). The OpenGL mode has the smoothest motion. The panning direction is opposite to the direction of two finger panning in other Mac applications. Also, adding the shift key - shift CMD two finger move, I was expecting the panning motion to be up-down, but it is actually panning on a 45 deg angle NW-SE in the pcbnew window. This key combination gives in-out zoom on the eeschema window. The grid dots disappear in the OpenGL mode. It might be useful to have a check mark appear on the View menu to indicate which of the view modes is being used at the moment. - Solid progress - thanks much to all. ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Hi all, I haven't added any trackpad stuff to any of the nightlies, so this is just the regular Python nightly. Adam Wolf Cofounder and Engineer WL On Sat, Apr 4, 2015 at 11:15 AM, Bob Gustafson bob...@rcn.com wrote: Testing report on this nightly build: Application: kicad Version: (2015-04-03 BZR 5572)-product Release build wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8) Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac Boost version: 1.54.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=ON KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_WXPYTHON=ON USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON KICAD_USE_WEBKIT=OFF This is the latest OS X nightly build from Adam - http://downloads.kicad-pcb.org/osx/DEBUG/ In the pcbnew window, the scripting console seems to work fine (It responds to ‘help()’ ) I don’t think it has the trackpad patches installed yet, but the pcbnew and eeschema windows do pan horizontally in response to CMD - two finger move on the trackpad. pcbnew does this in all three view modes (default, OpenGL, and Cairo). The OpenGL mode has the smoothest motion. The panning direction is opposite to the direction of two finger panning in other Mac applications. Also, adding the shift key - shift CMD two finger move, I was expecting the panning motion to be up-down, but it is actually panning on a 45 deg angle NW-SE in the pcbnew window. This key combination gives in-out zoom on the eeschema window. The grid dots disappear in the OpenGL mode. It might be useful to have a check mark appear on the View menu to indicate which of the view modes is being used at the moment. - Solid progress - thanks much to all. ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
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
Re: [Kicad-developers] Bob's Mac Usability Problems
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. 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.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
Re: [Kicad-developers] Bob's Mac Usability Problems
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
Re: [Kicad-developers] Bob's Mac Usability Problems
Super - I will go out and get a standard PC logitech mouse. According to the reports on the 5k iMac, you have 14.7 million pixels with a resolution of 5,120x2,880 - very impressive. Bandwidth to the screen is beyond Thunderbolt 2, so no wonder you have some slowness moving pixels. There may be an adjustment for resolution - so you can trade off speed vs pixels. Thanks much. I was beginning to believe there were no real KiCad Mac users. Bob G On 04/02/2015 03:24 AM, Piotr Esden-Tempski wrote: Hi everyone, I am using a 5k IMac with a standard PC logitech mouse. I have the nightly build 5547 installed. I do not experience any problems with zooming in GAL. (Besides the already reported bug with the F2 button) What I do experience is the lack of rats nest. Sometimes when zooming there is a remainder of a short rats nest wire but that is basically it. Also as a side note the only mode usable on the 5k iMac is the OpenGL GAL mode. Everything else is way too slow to be usable (probably too many pixels to render :D) I had to start Kicad in a low resolution mode so that default mode is somewhat usable. (Reported to Nick and he was so kind that he added this to the FAQ) I hope this is useful information. Cheers, Piotr On Apr 2, 2015, at 12:50 AM, Maciej Sumiński maciej.sumin...@cern.ch wrote: On 04/01/2015 10:23 PM, Bob Gustafson wrote: I just now downloaded your OS X nightly build (both debug and regular) on my wife’s Mac mini. She does not like the trackpad and has an Apple Mouse (latest model) - more or less a standard Mac (it does have a Cinema 30 from a previous Mac). When I create a board, add some chips and wires, I have difficulty in controlling the circuit on the screen. Whenever I touch the top of the mouse (one finger or two), the circuit layout zooms wildly. It doesn’t matter whether I stroke the mouse up and down or left-right, the circuit zooms big (bigger than the screen) or tiny. No panning action from the mouse. This is with both the eeschema and pcbnew views. Perhaps I have my mouse preferences set incorrectly, but other applications work just fine. With LibreOffice or Preview, I can easily pan (one finger) in all directions without causing any zoom. This is close to the same action I see on my Mac Laptop. If this is the normal operation of KiCad on the Mac, I can’t see how it can be a release version. Bob G Have you or any other OS X user tried GAL with a common PC USB mouse? Is the problem associated with this particular mouse model or is it the same for any other pointing device under OS X? Regards, Orson ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 2, 2015, at 12:45 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 02.04.2015 21:17, Piotr Esden-Tempski wrote: Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Hi Piotr, Can you take a screenshot of the last point?^^ Cheers, Tom Hi Tom, Here you go. :) It is bit difficult to show with a single screenshot, as it changes while dragging parts around. I think it still considers some parts being in the center of the drawing? If you need more information I can try to record a short screencast to illustrate the issue better. :) Cheers, Piotr -- Piotr Esden-Tempski Founder: 1BitSquared ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 2, 2015, at 1:20 PM, Piotr Esden-Tempski pi...@esden.net wrote: On Apr 2, 2015, at 1:16 PM, Piotr Esden-Tempski pi...@esden.net wrote: On Apr 2, 2015, at 12:45 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 02.04.2015 21:17, Piotr Esden-Tempski wrote: Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Hi Piotr, Can you take a screenshot of the last point?^^ Cheers, Tom Hi Tom, Here you go. :) It is bit difficult to show with a single screenshot, as it changes while dragging parts around. I think it still considers some parts being in the center of the drawing? If you need more information I can try to record a short screencast to illustrate the issue better. :) One more thing. I just realized, it is not the origin. It is the position where the parts were before I used the spread function… Again, just as a data point, I am seeing exactly what Piotr is seeing. -a ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Hi Piotr Thanks much for the nice explanation. OpenGL looks like the correct direction. Best regards - Bob G On 04/02/2015 02:49 PM, Piotr Esden-Tempski wrote: Hi Bob, I did not change the resolution of my whole screen. I only told Mac OS to start Kicad.app in low resolution mode. (it makes all the children start in that mode too) This is how I solved it, see section Retina display slow” http://www.kicad-pcb.org/display/DEV/Known+System+Related+Issues Obviously this can be also achieved by telling the OS to decrease the resolution of the Retina display but then all applications will run at lower resolution. This is not a good solution to the problem. I also have an external screen which is not HiDPI and moving the window over there makes it also run faster. Also this has nothing to do with thunderbolt speed. Apple is usually not selling stuff they can not drive. This is why the 5k iMac display can not be used from an external computer but only from the built in one. The speed issues are related to KiCad not being able to render so many pixels not that the machine can not control the display. As I assume the default and cairo views don’t use any hardware acceleration and have to render all those pixels in software. The OpenGL graphics mode is the only mode that has no issues rendering on that display and is totally fine with the resolution. For default view and even worse cairo I have to start in the “Low Resolution mode” this way the software thinks the display is low resolution and has to render much fewer pixels. The operating system then scales it up, probably using hardware, so that it is not so tiny on the screen. Also the only application I use that has speed issues on this display is KiCad at the moment. I can’t wait to see OpenGL canvas be used throughout KiCad so I can take advantage of the nice screen. :D But I am totally fine with the lowres mode for now, just sharing the current state of affairs. :) I hope this clarifies the situation. Cheers, Piotr -- Piotr Esden-Tempski Founder, Embedded Systems Engineer 1 Bit Squared 'Professional Nano UAV Systems' http://1bitsquared.com On Apr 2, 2015, at 12:28 PM, Bob Gustafson bob...@rcn.com mailto:bob...@rcn.com wrote: Begin forwarded message: Date: April 2, 2015 at 03:58:18 CDT From: Bob Gustafson bob...@chidig.com mailto:bob...@chidig.com To: Piotr Esden-Tempski pi...@esden.net mailto:pi...@esden.net, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch Cc: Adam Wolf adamw...@feelslikeburning.com mailto:adamw...@feelslikeburning.com, kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Bob's Mac Usability Problems Super - I will go out and get a standard PC logitech mouse. According to the reports on the 5k iMac, you have 14.7 million pixels with a resolution of 5,120x2,880 - very impressive. Bandwidth to the screen is beyond Thunderbolt 2, so no wonder you have some slowness moving pixels. There may be an adjustment for resolution - so you can trade off speed vs pixels. The Preferences our Mac mini include an item for screen resolution. It seems reasonable that if you cut the resolution, your screen render time should speed up. See attached tiff of preferences window. DisplayResolutionPrefs.tiff ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Hi Bob, I did not change the resolution of my whole screen. I only told Mac OS to start Kicad.app in low resolution mode. (it makes all the children start in that mode too) This is how I solved it, see section Retina display slow” http://www.kicad-pcb.org/display/DEV/Known+System+Related+Issues http://www.kicad-pcb.org/display/DEV/Known+System+Related+Issues Obviously this can be also achieved by telling the OS to decrease the resolution of the Retina display but then all applications will run at lower resolution. This is not a good solution to the problem. I also have an external screen which is not HiDPI and moving the window over there makes it also run faster. Also this has nothing to do with thunderbolt speed. Apple is usually not selling stuff they can not drive. This is why the 5k iMac display can not be used from an external computer but only from the built in one. The speed issues are related to KiCad not being able to render so many pixels not that the machine can not control the display. As I assume the default and cairo views don’t use any hardware acceleration and have to render all those pixels in software. The OpenGL graphics mode is the only mode that has no issues rendering on that display and is totally fine with the resolution. For default view and even worse cairo I have to start in the “Low Resolution mode” this way the software thinks the display is low resolution and has to render much fewer pixels. The operating system then scales it up, probably using hardware, so that it is not so tiny on the screen. Also the only application I use that has speed issues on this display is KiCad at the moment. I can’t wait to see OpenGL canvas be used throughout KiCad so I can take advantage of the nice screen. :D But I am totally fine with the lowres mode for now, just sharing the current state of affairs. :) I hope this clarifies the situation. Cheers, Piotr -- Piotr Esden-Tempski Founder, Embedded Systems Engineer 1 Bit Squared 'Professional Nano UAV Systems' http://1bitsquared.com On Apr 2, 2015, at 12:28 PM, Bob Gustafson bob...@rcn.com wrote: Begin forwarded message: Date: April 2, 2015 at 03:58:18 CDT From: Bob Gustafson bob...@chidig.com mailto:bob...@chidig.com To: Piotr Esden-Tempski pi...@esden.net mailto:pi...@esden.net, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch Cc: Adam Wolf adamw...@feelslikeburning.com mailto:adamw...@feelslikeburning.com, kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Bob's Mac Usability Problems Super - I will go out and get a standard PC logitech mouse. According to the reports on the 5k iMac, you have 14.7 million pixels with a resolution of 5,120x2,880 - very impressive. Bandwidth to the screen is beyond Thunderbolt 2, so no wonder you have some slowness moving pixels. There may be an adjustment for resolution - so you can trade off speed vs pixels. The Preferences our Mac mini include an item for screen resolution. It seems reasonable that if you cut the resolution, your screen render time should speed up. See attached tiff of preferences window. DisplayResolutionPrefs.tiff ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 2, 2015, at 1:16 PM, Piotr Esden-Tempski pi...@esden.net wrote: On Apr 2, 2015, at 12:45 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch mailto:tomasz.wlostow...@cern.ch wrote: On 02.04.2015 21:17, Piotr Esden-Tempski wrote: Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Hi Piotr, Can you take a screenshot of the last point?^^ Cheers, Tom Hi Tom, Here you go. :) It is bit difficult to show with a single screenshot, as it changes while dragging parts around. I think it still considers some parts being in the center of the drawing? If you need more information I can try to record a short screencast to illustrate the issue better. :) One more thing. I just realized, it is not the origin. It is the position where the parts were before I used the spread function… Cheers, Piotr -- Piotr Esden-Tempski Founder: 1BitSquared___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On 02.04.2015 21:17, Piotr Esden-Tempski wrote: Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Hi Piotr, Can you take a screenshot of the last point?^^ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Come on, this is an issue that has always existed in GAL as far as I can remember. A bug has recently been reported on this on a workaround. I hope this can see be resolved. This happens also on linux. https://bugs.launchpad.net/kicad/+bug/1438406 2015-04-02 22:16 GMT+02:00 Piotr Esden-Tempski pi...@esden.net: On Apr 2, 2015, at 12:45 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 02.04.2015 21:17, Piotr Esden-Tempski wrote: Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Hi Piotr, Can you take a screenshot of the last point?^^ Cheers, Tom Hi Tom, Here you go. :) It is bit difficult to show with a single screenshot, as it changes while dragging parts around. I think it still considers some parts being in the center of the drawing? If you need more information I can try to record a short screencast to illustrate the issue better. :) Cheers, Piotr -- Piotr Esden-Tempski Founder: 1BitSquared ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
I have OSX and Linux (Fedora21) development environments, but no
Windows. My luck at generating fully operational OSX binaries is spotty
- perhaps due to multiple boost libraries (still working this out).
As I recall, I did merge your trackpad branch with the then current head
and I think I did see up-down and left-right action from my Mac Air
laptop. That build seemed to have other problems, so it was only a
fleeting experience.
I would be happy to try a build with both OSX 10.10.2 and Fedora21
(equipped with Clang too). If it is possible to segregate your trackpad
stuff into patch form rather than branch merge - it might be better at
this end.
Thanks much for your effort!
Bob G
On 04/02/2015 11:06 AM, Garth Corral wrote:
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?
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
___
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
Re: [Kicad-developers] Bob's Mac Usability Problems
Super - will look for them Bob G On 04/02/2015 12:31 PM, Adam Wolf wrote: I will work hard on getting nightlies with the trackpad patch applied, in the DEBUG/trackpad/ directory. Adam Wolf Cofounder and Engineer WL On Thu, Apr 2, 2015 at 1:27 PM, Bob Gustafson bob...@rcn.com mailto:bob...@rcn.com wrote: On 04/02/2015 09:05 AM, Andy Peters wrote: On Apr 2, 2015, at 1:24 AM, Piotr Esden-Tempski pi...@esden.net mailto:pi...@esden.net wrote: Hi everyone, I am using a 5k IMac with a standard PC logitech mouse. I have the nightly build 5547 installed. I do not experience any problems with zooming in GAL. (Besides the already reported bug with the F2 button) What I do experience is the lack of rats nest. Sometimes when zooming there is a remainder of a short rats nest wire but that is basically it. I use a Kensington Expert Mouse (read: best pointing device EVER, all others just suck) with my desktop Mac (and the work PC). I mapped one of the buttons to be the middle mouse button. It works well. I'm not at my MacBook Pro, but I could swear that there is a way to set up a modifier key/mouse click combination to emulate the middle button. I'll check later. I also have the GAL rats-nest issue Piotr mentions. ___ The graphics program Blender uses modifier key/mouse click combinations. See: http://wiki.blender.org/index.php/Doc:2.4/Manual/Interface/Keyboard_and_Mouse The following table shows the combos used: 2-button Mouse Apple Mouse LMB Template-LMB.pngLMB Template-LMB.pngLMB Template-LMB.png (mouse button) MMB Template-MMB.pngAltLMB Template-LMB.png ⌥ OptLMB Template-LMB.png (Option/Alt key + mouse button) RMB Template-RMB.pngRMB Template-RMB.png⌘ CmdLMB Template-LMB.png (Command/Apple key + mouse button) Unfortunately for me, these don't work with KiCad on a trackpad or magic mouse equipped Mac OSX 10.10.2 ( With the command key down and rubbing the magic mouse lightly in any direction, a chip footprint can be panned to the left and back to center on pcbnew. No modifier key combo seems to enable up down panning.) With the option key down, mouse motions draw an outline box - perhaps a group select command. Thanks for all your comments. Bob G ___ Mailing list: https://launchpad.net/~kicad-developers https://launchpad.net/%7Ekicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers https://launchpad.net/%7Ekicad-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
Re: [Kicad-developers] Bob's Mac Usability Problems
Hi Maciek, I just tested it a bit more. The behaviour of the ratsnest is a bit confusing here. Let me describe it with the steps I took and what I observed. These are steps on a completely new pcb. * open pcbnew (leave in default mode) * Read netlist * Spread out All Footprints (Ratsnest wires are visible) * Switch to OpenGL view (Footprints are still visible but no ratsnest wires) * Move a part around (Ratsnest wires of that particular part appear) * Switch back to default view and to OpenGL again (the ratsnest wires that were not visible in OpenGL are still invisible and the ones that I made appear by moving a part around are still there) * Save pcb file and exit pcbnew * Reopen pcbnew with the newly created board file * Switch to OpenGL view (All ratsnest wires are visible) Additionally to all that, at the step where I move the parts around in the OpenGL mode, additional ratsnest wires are being drawn to the origin of the canvas. They are gone after reloading the pcb file. Cheers, Piotr On 04/02/2015 07:43 AM, Maciej Sumiński wrote: On 04/02/2015 04:05 PM, Andy Peters wrote: [... I also have the GAL rats-nest issue Piotr mentions. Does it mean it is never visible? Even when you are dragging components? Are there OS X users for whom it works properly? Regards, Orson ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On 04/02/2015 04:05 PM, Andy Peters wrote: [... I also have the GAL rats-nest issue Piotr mentions. Does it mean it is never visible? Even when you are dragging components? Are there OS X users for whom it works properly? Regards, Orson signature.asc Description: OpenPGP digital 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
Re: [Kicad-developers] Bob's Mac Usability Problems
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
Re: [Kicad-developers] Bob's Mac Usability Problems
I had personally been wondering when GAL mode would support a ratsnest, so I have a feeling it is across the board for OS X :) Adam Wolf On Thu, Apr 2, 2015 at 10:43 AM, Maciej Sumiński maciej.sumin...@cern.ch wrote: On 04/02/2015 04:05 PM, Andy Peters wrote: [... I also have the GAL rats-nest issue Piotr mentions. Does it mean it is never visible? Even when you are dragging components? Are there OS X users for whom it works properly? Regards, Orson ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
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 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
Re: [Kicad-developers] Bob's Mac Usability Problems
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
Re: [Kicad-developers] Bob's Mac Usability Problems
Otherwise you might want to make a build and put it into the DEBUG folder for testing. Den 02/04/2015 15.34 skrev Adam Wolf adamw...@feelslikeburning.com: 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 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
Re: [Kicad-developers] Bob's Mac Usability Problems
I have a DEBUG/ folder in the nightlies directory for bugfix-confirmation
builds.
I'll take a look at doing the wrapper, but unfortunately it's toward the
bottom of my list, until the stables get closer. If anyone else wants to
work on this, feel free! :)
Adam Wolf
On Thu, Apr 2, 2015 at 9: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
Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 2, 2015, at 1:24 AM, Piotr Esden-Tempski pi...@esden.net wrote: Hi everyone, I am using a 5k IMac with a standard PC logitech mouse. I have the nightly build 5547 installed. I do not experience any problems with zooming in GAL. (Besides the already reported bug with the F2 button) What I do experience is the lack of rats nest. Sometimes when zooming there is a remainder of a short rats nest wire but that is basically it. I use a Kensington Expert Mouse (read: best pointing device EVER, all others just suck) with my desktop Mac (and the work PC). I mapped one of the buttons to be the middle mouse button. It works well. I'm not at my MacBook Pro, but I could swear that there is a way to set up a modifier key/mouse click combination to emulate the middle button. I'll check later. I also have the GAL rats-nest issue Piotr mentions. ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On 04/02/2015 09:05 AM, Andy Peters wrote: On Apr 2, 2015, at 1:24 AM, Piotr Esden-Tempski pi...@esden.net wrote: Hi everyone, I am using a 5k IMac with a standard PC logitech mouse. I have the nightly build 5547 installed. I do not experience any problems with zooming in GAL. (Besides the already reported bug with the F2 button) What I do experience is the lack of rats nest. Sometimes when zooming there is a remainder of a short rats nest wire but that is basically it. I use a Kensington Expert Mouse (read: best pointing device EVER, all others just suck) with my desktop Mac (and the work PC). I mapped one of the buttons to be the middle mouse button. It works well. I'm not at my MacBook Pro, but I could swear that there is a way to set up a modifier key/mouse click combination to emulate the middle button. I'll check later. I also have the GAL rats-nest issue Piotr mentions. ___ The graphics program Blender uses modifier key/mouse click combinations. See: http://wiki.blender.org/index.php/Doc:2.4/Manual/Interface/Keyboard_and_Mouse The following table shows the combos used: 2-button Mouse Apple Mouse LMB Template-LMB.pngLMB Template-LMB.pngLMB Template-LMB.png (mouse button) MMB Template-MMB.pngAltLMB Template-LMB.png ⌥ OptLMB Template-LMB.png (Option/Alt key + mouse button) RMB Template-RMB.pngRMB Template-RMB.png⌘ CmdLMB Template-LMB.png (Command/Apple key + mouse button) Unfortunately for me, these don't work with KiCad on a trackpad or magic mouse equipped Mac OSX 10.10.2 ( With the command key down and rubbing the magic mouse lightly in any direction, a chip footprint can be panned to the left and back to center on pcbnew. No modifier key combo seems to enable up down panning.) With the option key down, mouse motions draw an outline box - perhaps a group select command. Thanks for all your comments. Bob G ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
Thanks very much for your comments. At least I don't feel so alone. Best regards - Bob G On 04/02/2015 04:01 AM, Bernhard Stegmaier wrote: Up to now I also didn’t find any way to have a “middle button” with only Apple gear (there seem to be some tools for simulating, but I didn’t try them yet). So, it might work with a normal PC mouse, but why should I want to use such a thing in an Apple environment - or, just buy one to be able to use KiCad? Current Apple mice and touchpad have the touch panning you are used from every smartphone, tablet, and more important any other OS X application. More bad, just like Bob said… since the normal mouse wheel is mapped to zoom, if you accidentally touch the mouse the wrong way it zooms in/out which is very nasty. For me, this is still the reason why KiCad without Garths panning patches is just a no-go on OSX. It is great with them… :) Regards, Bernhard On 02 Apr 2015, at 09:50, Maciej Sumiński maciej.sumin...@cern.ch wrote: On 04/01/2015 10:23 PM, Bob Gustafson wrote: I just now downloaded your OS X nightly build (both debug and regular) on my wife’s Mac mini. She does not like the trackpad and has an Apple Mouse (latest model) - more or less a standard Mac (it does have a Cinema 30 from a previous Mac). When I create a board, add some chips and wires, I have difficulty in controlling the circuit on the screen. Whenever I touch the top of the mouse (one finger or two), the circuit layout zooms wildly. It doesn’t matter whether I stroke the mouse up and down or left-right, the circuit zooms big (bigger than the screen) or tiny. No panning action from the mouse. This is with both the eeschema and pcbnew views. Perhaps I have my mouse preferences set incorrectly, but other applications work just fine. With LibreOffice or Preview, I can easily pan (one finger) in all directions without causing any zoom. This is close to the same action I see on my Mac Laptop. If this is the normal operation of KiCad on the Mac, I can’t see how it can be a release version. Bob G Have you or any other OS X user tried GAL with a common PC USB mouse? Is the problem associated with this particular mouse model or is it the same for any other pointing device under OS X? Regards, Orson ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
I will work hard on getting nightlies with the trackpad patch applied, in the DEBUG/trackpad/ directory. Adam Wolf Cofounder and Engineer WL On Thu, Apr 2, 2015 at 1:27 PM, Bob Gustafson bob...@rcn.com wrote: On 04/02/2015 09:05 AM, Andy Peters wrote: On Apr 2, 2015, at 1:24 AM, Piotr Esden-Tempski pi...@esden.net wrote: Hi everyone, I am using a 5k IMac with a standard PC logitech mouse. I have the nightly build 5547 installed. I do not experience any problems with zooming in GAL. (Besides the already reported bug with the F2 button) What I do experience is the lack of rats nest. Sometimes when zooming there is a remainder of a short rats nest wire but that is basically it. I use a Kensington Expert Mouse (read: best pointing device EVER, all others just suck) with my desktop Mac (and the work PC). I mapped one of the buttons to be the middle mouse button. It works well. I'm not at my MacBook Pro, but I could swear that there is a way to set up a modifier key/mouse click combination to emulate the middle button. I'll check later. I also have the GAL rats-nest issue Piotr mentions. ___ The graphics program Blender uses modifier key/mouse click combinations. See: http://wiki.blender.org/index.php/Doc:2.4/Manual/Interface/ Keyboard_and_Mouse The following table shows the combos used: 2-button Mouse Apple Mouse LMB Template-LMB.pngLMB Template-LMB.pngLMB Template-LMB.png (mouse button) MMB Template-MMB.pngAltLMB Template-LMB.png ⌥ OptLMB Template-LMB.png (Option/Alt key + mouse button) RMB Template-RMB.pngRMB Template-RMB.png⌘ CmdLMB Template-LMB.png (Command/Apple key + mouse button) Unfortunately for me, these don't work with KiCad on a trackpad or magic mouse equipped Mac OSX 10.10.2 ( With the command key down and rubbing the magic mouse lightly in any direction, a chip footprint can be panned to the left and back to center on pcbnew. No modifier key combo seems to enable up down panning.) With the option key down, mouse motions draw an outline box - perhaps a group select command. Thanks for all your comments. Bob G ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
I haven't noticed it, but my pcbnew designs still have only 3 wires.. Bob G On 04/02/2015 09:43 AM, Maciej Sumiński wrote: On 04/02/2015 04:05 PM, Andy Peters wrote: [... I also have the GAL rats-nest issue Piotr mentions. Does it mean it is never visible? Even when you are dragging components? Are there OS X users for whom it works properly? Regards, Orson ___ 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
Re: [Kicad-developers] Bob's Mac Usability Problems
On Apr 1, 2015, at 14:10, Adam Wolf adamw...@feelslikeburning.com wrote: Hi folks, I'm making this thread so Bob has a place to bring up his usability problems. I have a hard time following the mailing list when threads diverge, and making multiple threads really helps me out. Adam Wolf ___Bob Gustafson writes: Thanks much Adam. I’m reposting below my Mac usability mails taken from the “GAL questions (with regarding 3d-viewer)” thread === I just now downloaded your OS X nightly build (both debug and regular) on my wife’s Mac mini. She does not like the trackpad and has an Apple Mouse (latest model) - more or less a standard Mac (it does have a Cinema 30 from a previous Mac). When I create a board, add some chips and wires, I have difficulty in controlling the circuit on the screen. Whenever I touch the top of the mouse (one finger or two), the circuit layout zooms wildly. It doesn’t matter whether I stroke the mouse up and down or left-right, the circuit zooms big (bigger than the screen) or tiny. No panning action from the mouse. This is with both the eeschema and pcbnew views. Perhaps I have my mouse preferences set incorrectly, but other applications work just fine. With LibreOffice or Preview, I can easily pan (one finger) in all directions without causing any zoom. This is close to the same action I see on my Mac Laptop. If this is the normal operation of KiCad on the Mac, I can’t see how it can be a release version. Bob G On Apr 1, 2015, at 11:22, Bob Gustafson bob...@rcn.com wrote: Too bad.. On 04/01/2015 11:17 AM, Adam Wolf wrote: Yup. The trackpad stuff didn't get in before the feature freeze, so it will be a bit before it's in the tree. On Apr 1, 2015 12:15 PM, Bob Gustafson bob...@rcn.com wrote: My Mac air laptop only has a trackpad. If I would buy a 3 button mouse, it would be one more piece of klim-bim to bring along. The advantage of the built-in trackpad is that I can have the whole laptop on my lap. Difficult to find a suitable place for the mouse in that environment. Thanks for your suggestion though. Bob G On 04/01/2015 09:06 AM, Adam Wolf wrote: Bob, You can use a 3 button mouse, right? KiCad explictly states in the docs that it requires a 3 button mouse. Adam Wolf Cofounder and Engineer WL On Wed, Apr 1, 2015 at 10:00 AM, Bob Gustafson bob...@rcn.com wrote: On 04/01/2015 07:34 AM, Nick Østergaard wrote: ___ 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
