kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 26/03/2018 à 18:40, Wayne Stambaugh a écrit :
> On 3/26/2018 7:19 AM, jp charras wrote:
>> Le 26/03/2018 à 01:31, Wayne Stambaugh a écrit :
>>> Now that a fix for the lost data has been merged, we should defer the fix for how to handle deleting
>>> objects from removed layers until v6.  In the mean time, we should clearly define the behavior
>>> before we write any code to prevent any wasted developer time.
>>>
>>> Cheers,
>>>
>>> Wayne
>>
>> Hi Wayne,
>>
>> Before waiting for V6, there are a few things that must be fixed.
>>
>> - Minor issues:
>> * I am thinking the layers now used in DRC should be not removable (edge cut, courtyards and in the
>> future margin layer)
>> I have a basic fix for that.
> 
> I'm fine with this but we should define which layers are "mandatory" and
> which layers are not and make the UI behave accordingly.

I am thinking edge cut is mandatory.
I do not have a strong opinion about margin layer, not yet in use.

Because courtyards are used in V5 libs and DRC, I am inclined to think they are mandatory.

My fix makes the UI behave accordingly.

> 
>> * non copper layers used in footprints can be removed  (without fortunately destroying the
>> footprint) without warning: I have a fix to warn the user then removed non copper layers are in use
>> in a footprint.
> 
> This seem reasonable.

OK.
I can commit this small change.

> 
>>
>> -Not so minor issues:
>> Multilayers items (blind/buried vias, keepout zones) are incorrectly handled:
>> * In GAL mode, removed Multilayers items are still visible after deletion.
> 
> This should be fixed.  Even if it's something as crude as checking to
> make sure the layer actually exists in the board before drawing an
> object in gal.

I am certainly not a GAL specialist, but it is just a cache rebuild issue.

However, apart GAL issue, Multilayers items are not correctly handled, because they are deleted
regardless they are still existing on not deleted layers.

> 
>> * In all modes: because undo is not handled, if a removed item (for instance a track) was previously
>> modified (and therefore in the undo list), and if a undo command is made, Pcbnew crashes.
>> At least the undo/redo list should be cleared.
> 
> I'm guessing users are not going to like having their undo/redo historyt
> wiped out after a long editing session.  Would it be possible to just
> remove the objects/actions on the removed layers from the undo/redo
> buffer rather than clearing the entire buffer?

Sure, but I am not sure this is a small change.

A stub exists: see in pcbnew/undo_redo.cpp: TestForExistingItem( BOARD* aPcb, BOARD_ITEM* aItem ),
but I am not sure it can be done for rc2.


-- 
Jean-Pierre CHARRAS