Currently, when I select items on the board and start to move them (without commiting, so the objects are floating with the cursor), if I cancel the move (which could have been an unintentional move) the move is undone but the selection is automatically cancelled, too.
I’d prefer that in this case, ESC would cancel/undo only the Move operation, and then (if needed) another ESC would cancel selection.
Reasoning: sometimes selection can be a time-consuming process (add multiple items to selection); and from time to time the user may not select eveything they want; after doing a Move, it becames clear what was left behind. With current behavior, I don’t know how to cancel move and fine-tune my selection.
With suggested behavior, I’d just ESC cancel my Move, fix my selection and try to move again.
What’s your opinion?
I was confused a bit by you short desctiption of what you did, and after some experimentation I did:
- Drag a box around some items to create a selection.
- Press M to move the selection.
- Move the cursor around, the selection moves with it.
- Press [Esc] to cancel the move.
- The selected parts go back to their old orientation, but are not selected anymore.
So I can confirm this behavior, both in the PCB Editor of KiCad V6.0.6 and in the current nightly V6.99.
Also, when you do not press [Esc] to cancel, but press the left mouse button to confirm the move and then press [Ctrl z] to undo the move, then the items go back to their old location, but they stay selected.
Even more so, this behavior is inconsistent. In the schematic editor, the move is canceled, but the selection does stay active until a second [Esc] keypress is entered.
What you describe is exactly my issue. In your Step 5, i’d like the selection to stay there until next ESC.
Your commit/undo may be a workaround, but I’m always sceptical about commiting somehting that is obviously incorrect to me (I know there’s Undo, but anyway… it’s kind of “invasive”).
Thanks for the tip on Schematic - it works the way I like (so I don’t loose my precious selection after 1st ESC).
Agree, it is a nuisance, especially with difficult selections that take two or three tries to get right.
At least there is the workaround I mentioned earlier. (Confirm, then undo with [Ctrl +z]).
This is worth opening a bug report on gitlab. Both for not loosing the selection, and for having consistent behavior between the schematic and PCB Editors. @fred4u Will you look into this (first search gitlab, etc) or shall I do this?
I’ll take care of the report.
EDIT:
@paulvdh there’s something interesting:
It’s exactly the same issue, reported as a wishlist item.
It was assigned a milestone (6.0), but for some reason was closed by the bot, with the status “fix commited” which is definitely not true (and there’s no mention on the relevant commit).
Is it something to reopen, or time for a new report with the link to the old one?
Gosh, good find.
You must have spend some time digging through those 10k closed issues.
Either should work, but I do not have the ability to re-open an issue (Except when I created it myself), and creating a new issue for it (with links to the old one and this thread) therefore seems to be the best option.
OK, issue reported:
There is still no fix in 6.99 downloaded yesterday.
The new issue fred4u created has also been closed with a fix commited now. So it should be fixed in tommorow’s nightly and in KiCad V6.0.7 when that is released. (Probably a few weeks, as bug fix relases are made approximately once a month).
That is quick. Is there a special reason for this?
I have a (slight) preference for a (somewhat) regular release schedule. Mayor versions now have the intention to be updated about once a year. Maybe once a month would be a reasonable schedule for bug fix updates?
But as I’m running Linux, these updates come automagically with regular system updates and it is thus not a very important issue for me.
We are on a roughly monthly cadence for patch releases at the moment. It’s not a firm schedule, but at the current pace bugs are fixed, this cadence seems about the right balance between not releasing too frequently and not keeping bugfixes from the userbase for too long. It is likely that this will slow down in the future, especially if a particular patch release has no high-severity bugs.
It looks like the fix discussed here didn’t make it into 6.0.7, as the freeze was before the fix. So it probably will have to wait until 6.0.8 in a month and a half.
I do not remember the exact sequence. But I know that group selections are sort of a pain. If I go to drag and I find that my selection was not quite right I generally need to start over. This difficulty is exacerbated by the fact that wires can push or pull a corner (or push a wire end) but they do not move a junction dot. This is all counterintuitive. I wanted to post a .gif but for some reason I cannot get Licecap to run at the moment…
You can add (shift+click LMB) and remove (ctrl+shift+click LMB) individual items to/from your existing selection, to get it right without starting over.
It’s not cherry-picked to the 6.0 branch yet, so it’s not even available in the 6.0.x testing build.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.