On Mon, 2020-07-13 at 15:09 +0200, Simon Richter wrote: > Hi Conrad, > > On 13.07.20 14:48, Conrad Wood wrote: > > > I am keen on generating the outputs for manufacturing and > > documentation > > (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a > > git > > hook. > > There is still some UI code inside the data representation, so for > now > scripting can only control a GUI instance. This is kind of annoying > for > git hooks as you need to set up a fake display server.
Exactly. I feel understood and I am pleased that this is a "known" annoyance rather than an "unknown" one :) > > > I've seen various 'hacks' out there to provide a graphical 'diff'. > > I > > would like to see the API either provide means to do a diff on two > > commits of the same repository, graphical or otherwise, in such a > > way > > that it can be integrated into a web-based process. > > (with "diff" I mean a method to see where and what changes were > > made in > > two versions by a person not trained to do PCB design. - this is > > mostly > > to review changes and spot unintended modifications) > > diff/merge is non-trivial, because PCB structures are three- > dimensional > while files are one-dimensional strings of bytes. Anything that is > able > to generate meaningful diffs would need to fully understand the > files, > not just look for similarities. Indeed. That's why I think much of the parsing and 'understanding' of the files should be moved out of the GUI and into a library. Then we can have an API for it and can start building on top of it. > > > On bigger/complex boards, there are often 'sections' which are > > handled > > by exports. for example, radio vs memory/cpu vs powersupply. It > > would > > absolutely awesome if we can progress KiCad to support such teams. > > In > > my mind, I am thinking of a KiCad server which serves clients and > > sections can be 'locked' and worked on simultaneously. > > Simultaneously I > > mean, with changes being propagated to each KiCad Client in real- > > time. > > That is partially a function of diff/merge, and also requires more of > a > notification system than we currently have (basically, we know to > update > *the* view when data changes, but we'd need to track multiple views > on > the data and add a way for data modifications to fail because of > conflicts -- plus UI presentation for that. > > That would require a lot of changes to internals. I am quite aware that this is a lot of changes. I don't suggest that we do everything at once. What I'd like to see though, is that there is a long term view of where we want to take APIs and the GUI/Library split (currently not even certain if that is the planned approach). I am no expert at the KiCad code, but when I did look if I can add such APIs, it became clear that there is a lot of work to do in splitting this out. I guess what I am really asking, is, a) what is the decision making process for KiCad-Dev for such long-term changes? b) how does KiCad-Dev deal with large-ish changes that may span multiple releases or reach further in the future than, say, a feature request or a bug report? c) How can I help? :) _______________________________________________ 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
