kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

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.

> - 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

Attachment: signature.asc
Description: OpenPGP digital signature