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