kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 19/10/2017 à 16:59, Maciej Sumiński a écrit :
> On 10/19/2017 04:32 PM, jp charras wrote:
> [snip]
>> Hi Orson,
>>
>> Could you have a look into this patch?
>> It fixes the issue when a change is committed with a item belonging a footprint.
>>
>> But I do not have very good knowledge of COMMIT classes.
> 
> Hi Jean-Pierre,
> 
> Thank you for looking into the problem. In the proposed patch
> BOARD_COMMIT will try to save the item parent even for items that do not
> belong to modules (e.g. tracks, vias), ending up with the whole board
> stored in the undo buffer.

In fact no: the parent is used only if it is a MODULE (due to the dynamic_cast)

However the patch can save many times the same MODULE, in
COMMIT& BOARD_COMMIT::Stage( std::vector<EDA_ITEM*>& container, CHANGE_TYPE aChangeType )
if the container contains many items of the same MODULE (perhaps no a major issue, but...).

The patch is not really finished, in fact.

> 
> I would rather take advantage of BOARD_COMMIT::m_editModules field to
> determine whether the commit is created by the footprint editor. Then
> the check should be valid, but still the code needs to be tested to be
> sure it works as expected.
> 
> If you can wait, I can wrap up a fix by tomorrow morning.

Yes, Please do.

However, if you use BOARD_COMMIT::m_editModules, it is a bit restrictive, because it means you
cannot edit a pad or a footprint keepout in the board editor (Legacy canvas allows a change of a pad
in the board editor).
I am thinking we could need this kind of edition when the copper layer ID must be taken in account,
typically for the keepout, and perhaps later in pads.
(this is the reason BOARD_COMMIT::m_editModules was not used)

Thanks.

> 
> Regards,
> Orson
> 


-- 
Jean-Pierre CHARRAS