Ok, may be not as dramatic as that, but KiCad developers have been known to error on the side of excessive nannying and IMHO this is clearly a case of that. Previously you were able to delete locked items (mainly interested in tracks here, but footprints as well) by hitting delete button twice. On the first hit you would get an unobtrusive message asking you to confirm that you really want to delete it and then second press would actually allow you to do that.
Now, in the latest nightly builds (starting several weeks back) it wont’s let you delete locked items no matter what. You actually have to go and unlock all the items in your selection and only then you could delete them. And if you have a mixed selection of footprints and tracks then you can’t even block unlock them.
The more I work with this setup the more it annoys me. I lock tracks quite often when I don’t want them to be moved by push&shove router, but then deleting them turns into an ordeal. What was was wrong with the confirmation setup? It is still used for the repositioning of locked items (although not as elegantly implemented as the delete option used to be). Why use different logic for that? There is a work around: you can still Ctrl-X your selection, but it just ruins the work flow… probably should not have mentioned that… Somebody might do another public service and lock that out too
Anyhow, time for a commercial plug. If you don’t want to deal with that issue in the 6.0 release, then thumb up my bug report which was downgraded to a wish list status.
If you use: Pcbnew / Route / Interactive Router Settings / Mode: Walkaround, then the Router will not move already layed tracks at all, and there is no need to lock them in the first place.
Also:
Have you tried:
Make a selection.
Right Mouse button and from popup menu: Locking / Unlock
Move selection.
I agree with the others on gitlab. Hitting delete twice is not a good way to override the locked status. And this correctly turns your request into a wishlist item. There are many ways in which locking behavior can be improved, but [Del][Del] is not one of them.
Also: accusing the KiCad developers of “nannying” is not going to help your cause.
Nannying is not an accusation. It simply refers to a practice of limiting user actions by introducing restricting messages or additional safeties. The term is a widely used in software development and is not considered derogatory (otherwise you should get on Wane’s case first) Apologies if it hurt your feelings though
Thank you for your suggestion but I prefer to use push and shove router. I can also not use KiCad at all which would effectively solve all my locked objects issues
The fact that you agree with somebody on gitlab shouldn’t turn my request (even though I was under impression that it was a bug report) into a wish list. If it does, you’ve been given way too much power of agreement.
BTW in case you are interested the conversation there moved on from hitting a delete button twice to hitting two separate buttons once (i.e Delete and Enter). You seem to missed that point.
I’ll repeat what I said in the Gitlab issue: you can still do the “two button” combination that you wanted by assigning “Unlock” action to a hotkey.
That way when you absolutely want to delete an item and don’t care if the items were locked or not, you just press [“unlock” hotkey] [Del]
I just tested it and noticed that there might be a bug with it so I’ll report that, but the general idea is there. EDIT: Gitlab issue for the assignment of unlock key: https://gitlab.com/kicad/code/kicad/-/issues/6688
On gitlab you do not make “bug reports”, but you “create issues”.
It is up to the people who moderate that list to interpret it and add labels, so they can be sorted quicker by other people. This is another reason to keep posts there short. I do not have the power to add or change labels on gitlab. If you look at the top of your thread at gitlab, you can see that the “wishlist” label was added by Michael Kavanagh
I did not miss that. I read it, found it a bad Idea an decided it would not add anything to the conversation there, so I did not respond.
I did make a few other suggestions. One of them was a sort of “god” mode that ignores the locking completely, using an integer to create different severities of locking, and a color change or L label for locked items when selected to give more feedback. Those suggestions probably all got lost because of the long thread with many posts.
I also get the idea that you are completely mis using the “locking” feature. The locking feature is mainly intended for things you absolutely do not want to change accidentally. Examples for these are board outlines and placement of mounting holes. For this reason I also expect that trivially moving locked items will be blocked at some time in the future (also already mentioned in the gitlab thread).
Your wish from constantly wanting to lock stings and then still delete or move them trivially simple seems to have it’s origin in limitations of the Interactive Router. Mis-using one feature to overcome a limitation in another feature is not a good workflow. It can be a temporary workaround, but making bug reports to make this workaround work better for you is not good.
Make that in bold, please.
You tackle one of the most annoying characteristics of the Interactive router - its “passion” to move things around for unknown reasons. I dream about the day I will be able to use Shove as my main routing mode
