Reece, On 5/3/2019 2:09 PM, Reece R. Pollack wrote: > Hi Wayne, > > No worries on formatting. As a senior professional software engineer I'm > used to dealing with formal coding conventions and I'm keeping the web > page open while I'm writing. I prefer the K&R style myself, but I'm not > going to lose sleep over the differences. > > I had a bit of trouble getting the clang-format commit checker to work. > Mint 18 installs clang-format 3.8 by default, which doesn't support the > 'BreakStringLiterals' key. It spits out the following message: > > YAML:23:22: error: unknown key 'BreakStringLiterals' > BreakStringLiterals: false > ^~~~~ > Error reading /home/reece/MyProjects/KiCad/kicad/_clang-format: Invalid > argument > > With the invocation of clang-format buried under the git extension > mechanism this error message is invisible to the user. Worse, > clang-format then blithely ignores the entire style file and reformats > the file using its default settings (IndentWidth 2, etc.). The notes > should probably be updated to note the minimum version of clang-format > required to handle the supplied _clang-format file.
I'm guessing John used a later version of clang-format when he wrote the commit hooks. John, any ideas how to fix this or do we force devs to use clang-format > 3.8? > > -Reece > > > On 5/2/19 7:56 AM, Wayne Stambaugh wrote: >> Hi Reece, >> >> Just a few comments on top of Jeff's reply since this will be your first >> patch submission: >> >> Please follow the coding style policy[1]. It saves a lot of back and >> forth. There is also a git commit hook[2] which you can use to verify >> your coding style is correct. You will have to have clang-format >> installed on your system in order to use this feature. >> >> When you are ready to submit your patch(es), use `git format-patch` to >> create the patch(es) and post them on the mailing list for comment. >> >> It was great talking with you at KiCon. Thank you again for your >> interest in contributing to KiCad. >> >> Cheers, >> >> Wayne >> >> [1]: >> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html >> >> [2]: >> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools >> >> >> On 4/30/19 9:50 PM, Reece R. Pollack wrote: >>> Inspired by KiCon (and before the high wears off) I'm moving forward >>> with my project to allow the user to specify the coordinate display >>> origin in pcbnew. I have this working as patches to the v5.1.2 branch, >>> but they're hard-coded to use the Aux origin. I'd like some guidance on >>> how best to code this for eventual inclusion into the v6 development >>> branch. >>> >>> My plan is: >>> >>> 1. Create a new class ORIGIN_TRANSFORM. This class maintains the >>> user's >>> configuration and provides functions to perform the transforms >>> necessary to convert between the internal coordinate representation >>> and the equivalent coordinates relative to the user-selected >>> origin. >>> 2. Embed two ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS >>> class representing the origin transforms for the X and Y axes. >>> 3. Create a new tab in the pcbnew "Preferences" to allow the user to >>> select the origin (Page [default], Aux, or Grid) and direction >>> (Left >>> or Right [default], Up or Down [default]) for each axis. >>> 4. Modify the board file format to save and load the user's >>> ORIGIN_TRANSFORM configuration. Saving this in the .kicad_pcb file >>> allows everyone editing the board to see coordinates reported >>> relative to the same origin. >>> 5. Modify each of the dialog classes that displays object coordinates >>> to use the ORIGIN_TRANSFORM objects to display coordinates relative >>> to the user-selected origin. When the dialog is closed object >>> coordinates are converted back to internal coordinates. >>> 6. Modify the PCB_BASE_FRAME class to display the absolute cursor >>> position relative to the user-selected origin. >>> >>> This is structured to allow the UNIT_BINDER class to manage origin >>> transforms, much like it handles the mm/mil conversions. I would change >>> the constructor to take a reference to an ORIGIN_TRANSFORM object as an >>> additional argument; the default value would be a unity-transform whose >>> conversion functions return the value to be converted unmodified. Those >>> UNIT_BINDER objects that represent a coordinate value (commonly m_posX >>> and m_posY) would be constructed with a reference to one of the two >>> ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class. >>> >>> The problem with this strategy is that KiCad reuses UNIT_BINDER objects >>> for dissimilar purposes. For example, >>> DIALOG_GRAPHIC_ITEM_PROPERTIES::m_endX can represent the end point of a >>> graphic line, for which origin transform is needed. But it can also >>> represent the radius of a circle, for which origin transform is >>> inappropriate. Thus UNIT_BINDER needs a method similar to the Show() >>> function to enable or disable the origin transform depending on how it >>> is being used. This may argue against pushing this functionality into >>> UNIT_BINDER. >>> >>> If I don't modify the UNIT_BINDER class I'll probably code the >>> ORIGIN_TRANSFORM class to handle wxPoint objects rather than individual >>> coordinates. Thus there would be only one ORIGIN_TRANSFORM object added >>> to the BOARD_DESIGN_SETTINGS class. The transform in the dialog class >>> then becomes a single call to transform a coordinate pair rather than >>> one each for X and Y. >>> >>> Thoughts? Comments? Suggestions? Brickbats? >>> >>> -Reece >>> >>> >>> >>> _______________________________________________ >>> 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
