kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>