On 5/5/2016 6:52 AM, Chris Pavlina wrote: > Yes, please don't go interleaving preprocessor statements with fragments of > code like that, it's ugly and very prone to causing mistakes and > misunderstandings. > > #ifdef __APPLE__ > if( type != wxEVT_CHAR ) > aEvent.Skip(); > #else > aEvent.Skip(); > #endif > > ^ That is much clearer to me, it actually reads like C.
Agreed. Also, inlining of if statements is a violation of the KiCad coding policy. > > On Thu, May 05, 2016 at 10:39:50PM +1200, Simon Wells wrote: >> In its current state i am not a fan of this patch, as if someone comes >> along and adds a line between the #ifdev and aEvent.skip() is will >> break, Ideally it should probably be >> >> #ifdef __APPLE__ >> if ( type != wxEVT_CHAR ) aEvent.Skip(); >> #else >> aEvent.Skip(); >> #endif >> >> the comment can still be between the #ifdef and if line but it would >> make the code more obvious at a quick glance >> >> On Thu, May 5, 2016 at 7:44 PM, Collin Anderson <metacol...@electropi.mp> >> wrote: >>> Hi, I have attached a patch that fixes an annoyance that is present in the >>> footprint editor and pcbnew, but only under OS X. In either of these >>> editors, any time a hotkey (or any key in the main edit frame) is pressed, >>> it also triggers OS X's error alert. This means a system alert sound is >>> played, and/or (depending on the user's settings) the screen will flash. >>> This is the normal error cue in OS X, and as you can imagine, it gets >>> somewhat annoying, especially to us finger-happy types who use lots of >>> hotkeys. >>> >>> I searched the mail list, and found a prior reference to it. I can >>> definitely confirm that it has been an ever-present problem on OS X, to the >>> point I'm in the habit of turning off my speakers as soon as I open pcbnew >>> :). It's minor but annoying. It was never fixed as the patch broke other >>> things on other systems. >>> >>> OS X expects key press events to be caught and handled and only get passed >>> all the way up the GUI chain if there simply is no event handler anywhere >>> to deal with it. So a key press event that is passed to the GUI will be >>> seen as an input error, a key press that was sent nowhere and handled by >>> nothing. So I simply corrected this behavior, key events that are handled >>> are caught, but only on OS X, where NOT passing them to the GUI is the >>> correct and expected course of action. It is likely the only platform >>> where this is true, however. >>> >>> I've attached a very modest patch that contains the fix. I have been using >>> a build of KiCad with this patch applied under OS X, and I haven't found >>> any issues, everything works just as before, only now KiCad is wonderfully >>> silent :). >>> >>> >>> >>> >>> -- >>> "Violence is the last refuge of the incompetent." - Isaac Asimov >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ 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
