On 4/4/2015 11:41 AM, Simon Richter wrote: > Hi, > > On 04.04.2015 17:23, Lorenzo Marcantonio wrote: > >> On Sat, Apr 04, 2015 at 01:36:31AM +0200, Simon Richter wrote: > >>> 2. Keep strings/bitmaps outside of LIB_PIN > >>> These are UI elements. > >> Also, AFAIK the bitmaps are only used in the pin dialog... > > So far. I plan to add the same widget into another dialog, so it makes > sense to move the responsibility for initialization out of the dialog. I > also need a simpler representation in the table, before entering edit mode. > >>> 3. Keep load/save outside of LIB_PIN > >>> These belong to the load/save routines, which may change when switching to >>> s-expressions. > >> *Could* be contested, depending on the OO school you follow: >> >> - You can say that serializing is responsibily of the pin (i.e. >> virtual methods) > > Yes, that is the current approach. > > As far as I've understood, there is a certain desire to switch the > format, which means we will need two parsers at least, and ideally also > two formatters so we can still save to the old format for some time. > > I think if I were to submit these changes, I'd inline the > parsing/formatting bits back into lib_pin.cpp for the time being, and do > the split separately.
Please do not make any changes to the schematic file parsing or formatting code at this time. I will be rewriting the entire schematic I/O handling code after the stable release and after I fix the underlying schematic data model. Expect the the schematic I/O handling to look very similar to the pcb I/O handling. > >> - You can say that the load/save is/has/uses (we could discuss days on >> this detail alone...) a pin factory (for load) and a pin user (for >> save) > > Well, I'm thinking about Model-View-Controller, because that would allow > easy compartmentalization (legacy load/save, S-exp load/save, legacy > rendering, GAL rendering, non-modal dialogs). > >>> 4. Introduce dedicated ComboBox for pin shapes > >>> This makes the pin shape selection widget reusable across different >>> dialogs, and removes the responsibility of the user to initialize the >>> available selections. > >> Is there more than one dialog using these? Anyway it could be said >> that's a quite easy to do refactoring of the code. > > Soon. > >> Also: pin type is more or less useless (like the related DRC), so >> I wouldn't worry too much about it. > > Right, I just had to start somewhere. > > Simon > > > > > _______________________________________________ > 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