[Kicad-developers] Pointers to start contributing
Hello, I've recently started using KiCAD and I absolutely love it. Since it is open-source, I though I'll contribute to the project in which ever way I can. I have been using Orcad, Altium and Eagle during my career as an Electronics Engineer and then I had to work in Software. Therefore, I'm well versed in C, C++ and Python too. I've already built the project referring the documentation. I'm planning to go through the source code to just understand the architecture. Is there an architectural document for KiCAD? If there is anyone who has time to give me any pointers, it would be greatly appreciated. You all have done an amazing job! Thanks! Best Regards, Pradeepa Senanayake. ___ 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
[Kicad-developers] New cursor logic
The handling of cursors (arrow/pencil/etc., not the crosshairs) got pretty broken in the transition to action-based menus/toolbars/hotkeys. I’ve refreshed it and added some new stuff. There is now an onSetCursor() handler which is called form both the GAL canvas and the GAL backend. This is required (at least on OSX) to keep the cursor from flickering between the assigned cursor and the arrow. There’s also now a facility for the point editors to communicate with the drawing tools so that the cursor can be a pencil except when over a point (when it’s an arrow). And two-click-place tools (such as place symbol) now switch between pencil (idle state) and arrow (when dragging an instantiated item to place it). As always, scream if you see anything odd. Cheers, Jeff.___ 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] MSVC?
On 27/06/2019 12:02, Simon Richter wrote: > Hi, > > I've rebased[1] Tom's adaptation of my MSVC branch on top of current > master, seems to compile still[2], except for the usual dependency problems > with the generated lexers[3]. > > In this branch, we have an assembler based libcontext (taken over from > boost) that is in a later commit replaced by Windows Fibers. > > Before I do any further work on this branch: which implementation should we > go with, so I can squash the branch to that state? > Hi Simon, Thanks for your work. I'd go for the WinFiber API, it's stable, it's been in WinNT systems for ages... The libcontext backend for winfibers is somewhat ugly (it's just a proof of concept), would you be able to clean it up a bit before merging? 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] Additional parameters on simulation dialog
Hi Sylwester, I took a look at your repo and I have a few comments on your changes. I did not test it so there may be functional issues as well. Please simplify your logic in DIALOG_SIM_SETTINGS::TransferDataToWindow(). It's way more complicated than it needs to be. Get rid of DIALOG_SIM_SETTINGS::disableCtrlOnCheckboxEvent() and use the appropriate wxUpdateUIEvent[1] handler to enable and/or disable any controls. Manually doing this will almost certainly lead to broken control states. We have done this poorly so many times in the past that I am not allowing it in new code. If you want to submit your changes for consideration, you should squash you changes into a single patch and submit the output of `git format-patch` to the mailing list. Cheers, Wayne [1]: https://docs.wxwidgets.org/3.0/classwx_update_u_i_event.html#aa25df58e7047f819f5dd0520eb2cc8ea On 6/21/19 3:00 PM, Sylwester Kocjan wrote: > Hi, > > I prepared some changes in KiCad simulation dialog. They are about > additional simulation parameters. According to tutorial, which I've > found on website, I store them on GitHub repository in branch > "Sim_InitialConditions_SK" here: > > https://github.com/skocjan/kicad_initialconditions.git > > Could you please have a look and do some review if possible? I'd be > grateful for feedback if these changes are OK. In future I'd like to > implement OP analysis using some controls I've added > (https://bugs.launchpad.net/kicad/+bug/1821360). > > Additionally I also prepared polish translation for new strings. > > My aim was to make simulation with arbitrary initial conditions > possible (additionally I added other options). Right now it is possible > to enable checkbox UIC on TRAN tab, but there is no possibility to set > IC to any arbitrary value in element properties. I'm afraid it will > involve change in .sch format. Please take note that it is also > possible to define initial conditions for entire nodes instead of > capacitors or inductors (for example: ".ic v(11)=5 v(4)=-5 v(2)=2.2", > see ngspice manual, chapter 15.2.2). It is also a challenge. > > So in current state we can use for initial conditions results of .OP > analysis or default zero. > > From my point of view these are the topics, which should be taken into > account during review: > - in simulation code sometimes there is used '\n', sometimes "\r\n". > Maybe it should be unified? Is there a common definition for newline in > wxWidgets? > - I added .option savecurrents: someone added TODO that it doesn't > work. Maybe should we hide this control? > - something happened to colours on dialog windows, see attached image. > I don't know what is it and how to fix it. seems to be unrelated to my > changes, but maybe I'm wrong? (this is visible on Ubuntu 18.04) > - some feedback regarding how to add IC field to capacitors, inductors > or nodes will be very appreciated ;) > > Limitations of my changes: > - parsing SPICE .options is not implemented (in bool > DIALOG_SIM_SETTINGS::parseCommand( const wxString& aCommand )) > > Best regards, > Sylwek > > > ___ > 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] [Patch] Cleanup of cmake python flag dependency handling
Hi Ian, I merged your patch into the master and 5.1 branches of KiCad. Thank you for your contribution to KiCad. Cheers, Wayne On 6/20/2019 12:37 PM, Ian McInerney wrote: > Based on the previous discussion on the list about the cmake handling > for the python flags, I have made the attached patch for master. In it I > have cleaned up how all the KICAD_SCRIPTING_* flags are handled in the > main cmake file so that now the flag KICAD_SCRIPTING acts as a global > off switch for all python support (it will set all other flags to OFF > when it is set to OFF by the user). I have also added version checking > to the wxPython detection portion, so that it now verifies that Phoenix > was actually found when it was requested, and that the classic interface > was found if it was requested. A mismatch in the wxPython requested > flavor and found flavor is a fatal error for the process so the user has > to sort out what is happening with their versioning. > > I do not believe these changes will break existing build processes, > since they should already have the flags in the valid combinations and > the defaults for the flags remain the same. > > -Ian > > ___ > 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
[Kicad-developers] MSVC?
Hi, I've rebased[1] Tom's adaptation of my MSVC branch on top of current master, seems to compile still[2], except for the usual dependency problems with the generated lexers[3]. In this branch, we have an assembler based libcontext (taken over from boost) that is in a later commit replaced by Windows Fibers. Before I do any further work on this branch: which implementation should we go with, so I can squash the branch to that state? I'd then do some more test builds and also actually run the program once or twice, so we can get the branch ready for merging. Simon [1] https://git.launchpad.net/~sjr/kicad/msvc-new [2] https://jenkins.simonrichter.eu/job/windows-kicad-msvc-tom/8/ [3] https://jenkins.simonrichter.eu/job/windows-kicad-msvc-tom/9/ ___ 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] Bug created by commit 6253b44f20
Hi JP, No need to file a bug. This is the third or fourth corner case I’ve run in to which tells me I need a more robust design. I’m going to remove SetTool() in favour of always using Push/Pop. Cheers, Jeff. > On 27 Jun 2019, at 08:58, jp charras wrote: > > Hi Jeff, > > Your fix (commit 6253b44f20) is incorrect and creates a new and more > serious bug: > * When the highlight tool or the delete tool is activated (checked) the > first time you click on the canvas, the previous tool is checked with a > very strange behavior (at least on W7 32 bits) depending on the previous > tool. > > for instance after activating the delete tool: > > - if the previous tool was the Select tool (arrow tool), the select tool > is displayed as checked, but the delete tool is still activated (but non > checked): you can delete items. > - if the previous tool was the Add symbol tool, as soon as you try to > delete an highlighted item, the item is not deleted, but instead the Add > symbol dialog is opened. > > I can fill a bug if you want. > > -- > Jean-Pierre CHARRAS > > ___ > 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
[Kicad-developers] Bug created by commit 6253b44f20
Hi Jeff, Your fix (commit 6253b44f20) is incorrect and creates a new and more serious bug: * When the highlight tool or the delete tool is activated (checked) the first time you click on the canvas, the previous tool is checked with a very strange behavior (at least on W7 32 bits) depending on the previous tool. for instance after activating the delete tool: - if the previous tool was the Select tool (arrow tool), the select tool is displayed as checked, but the delete tool is still activated (but non checked): you can delete items. - if the previous tool was the Add symbol tool, as soon as you try to delete an highlighted item, the item is not deleted, but instead the Add symbol dialog is opened. I can fill a bug if you want. -- Jean-Pierre CHARRAS ___ 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
