Has CERN began work on that yet? On Fri, Nov 17, 2017 at 02:26:01PM +0000, Wayne Stambaugh wrote: > Hey Jon, > > There is currently a CERN work order for improving bus handing which > would almost certainly clash with anything you are working on so you may > want to hold off until that is implemented. > > On 11/16/2017 09:24 PM, Jon Evans wrote: > > Hi Wayne, JP, and others with lots of Eeschema knowledge, > > > > I am working on a set of features to expand the capabilities of buses in > > Eeschema (more details soon, but in short, extending the concept of a > > bus beyond just a vector of signals with the same prefix, to an > > arbitrary grouping of signals). > > > > As I have looked in to this more, I have realized that it would be very > > useful for the implementation of these features (as well as others I can > > imagine) if the way that connectivity is managed were to be > > refactored/expanded. > > > > Right now, my understanding of the code is that connectivity between > > objects is only calculated as part of creating a netlist -- > > in SCH_EDIT_FRAME::BuildNetListBase(). This information is not cached > > anywhere or attached to the graphics objects, so it needs to be > > recalculated every time it is requested (today mostly by the "Highlight > > Net" feature). > > > > Since some of the things that I am working on would benefit from having > > easy access to the associated net/bus information for a graphical item, > > I was thinking that it would be a good idea to store this information > > and update it when the schematic is modified, rather than recalculating > > it every time it is needed. > > > > If I go down that path, then I start to think about how to store the > > data -- right now we have NETLIST_OBJECT, but this class is mostly > > targeted at ending up with a netlist suitable for ERC/transfer to PCB, > > and has some behavior that doesn't really line up with what I want -- > > for example, it "explodes" buses into individual objects for each bus > > member. > > The NETLIST_OBJECT is where this should be done. Keeping it synched > with schematic changes could be expensive because the current design > doesn't really support incremental updates. I'm not even sure that is > possible or practical. It may be necessary to create a different object > for this purpose but I would rather not. On my todo list is a unified > SCHEMATIC object that would handle updating the NETLIST_OBJECT when new > objects are added to the schematic that change the netlist. When I have > time to get around to that is anyone's guess at this point. I'm hoping > find time to work on it once the new schematic file formats are complete. > > Cheers, > > Wayne > > > > > I could either expand/rework NETLIST_OBJECT to do what I want, or I > > could leave it alone and build a different storage structure in > > parallel. The latter option might result in some duplicated data, but > > would also somewhat isolate these new features from the netlist > > generation code, which could reduce risk of breaking something. > > > > Do you have any input about this? > > > > Thanks, > > Jon > > > > > > _______________________________________________ > > 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