Feature Request. Make the priority of the object over which the mouse cursor is currently above higher than the selected object

[Anton]

I am now spreading the PCB and encounter such inconvenience. Found two confusing features. For example, deleting is simple by hovering the mouse button on a component / footprint and pressing delete button, the second is selecting an object and deleting it with the delete key. So it turns out that I, for example, just selected via, edited its parameters. And I need to delete some track segment on the other end of the circuit board. I move the mouse cursor over the track segment and press delete and oops - via deletes. The problem is that I often notice that you can quietly remove something in this way.

I think this will help:
1. Make the priority of the object over which the mouse cursor is currently above higher than the selected object (leave the selection itself).
2. Or apply action ONLY on an object when mouse cursor under it. If object is selected, and it a part of selected group - action makes with whole selected group objects.

If you want to perform an action on selected objects, then the mouse must be directed at one of them.

[Seth Hillbrand (sethh)]

We can't do number (1) without causing substantial problems. Number (2) might make sense. Then, if the mouse is not over the selection BB, we would revert to the unselected behavior.

We'll get a few more opinions before changing behavior like this but I've been bitten by this more than once as well but never had a good heuristic to apply to avoid it.

[Anton (antonpupkov)]

Make action ONLY with object, that under cursor. Be it selected or not. This implies that in order to perform an action on a group of selected objects, you must hover the cursor on one of the objects of this group. The action applies to the group. In my opinion it is quite real.

[Michael Kavanagh (michaelkavanagh)]

I think the current priority is correct. Selecting something is a more deliberate action, so should take priority over "cursor hover over item". What about people who select to delete, but their mouse may wander whilst they look for the delete key on the keyboard? This was discussed recently on the mailing list [1] in a different context.

When using a popular M-CAD tool, after doing something its standard to mash the Escape key 2-3 times to make sure everything is deselected before carrying out the next task. Maybe this workflow is inefficient, but it is standard behaviour across most graphical software.

[1] https://lists.launchpad.net/kicad-developers/msg40300.html

[Anton (antonpupkov)]

Yes this inefficient. You right.
KiCAD is not an graphical software. Is a tool, that creates electrical schematic and printed circuit boards, not an pictures, 3d-models and other.

[Anton (antonpupkov)]

See how it works.

[Anton (antonpupkov)]

"Many times Esc pressing" - is a bad standard, as for me. Action must be made ONLY under object, on which mouse cursor howers on. If object is selected and it is a part of selected group action takes on whole group (move, delet, edit some common priperties and so on).

[Anton (antonpupkov)]

The graphic engine will have to be modified so that all functions in kicad 4 are implemented in kicad5 and improved - expanded already in kicad6. I understand that it is easier to impose what the new graphics engine (wxWidgets) provides, but nothing good will come of it. Make a regular painter.

[eelik (eelik)]

No matter how hard I try to learn, again and again I bump to this problem. I haven't analyzed it very deeply but I think it happens after I first have done something to the selected items and and KiCad has left them selected after the action. My brains kind of tell me I have finished what I was doing and now I'm starting afresh. I move the mouse and try to delete something but the previously selected items are deleted.

At least one situation when this happens is when I move a footprint and then try to delete old segments around it.

It's difficult to say how to make this better without adding some complexity or making it less logical in some respect. It's like Michael said, "I think the current priority is correct" even though it doesn't work for me in some situations.

What could be done is to identify the exact situations where this is a problem and only after that think about a focused solution. For example: if something was done to the selected item(s) and after that Delete clicked on top of something else, show a tooltip-like warning (like when you select reference point for a copy) "Press Delete again to delete selection or Esc to cancel". That would leave most of the workflows unaffected but would prevent accidental deletion when it's most likely to happen.

If I select something and then click Delete I most likely actually want to delete the selection. But if I do something else to the selection first and then click Delete I most likely didn't want to delete the selection. Why would I first do something else to it and then suddenly change my mind, wanting to delete it? It can happen but much less likely.

[Anton (antonpupkov)]

Probably the simplest solution will be to enter a warning dialog before deleting in any cases of deletion, for example, "Do you really want to delete the selected object "Object visible name"?" or "Do you really want to delete the object "Object visible name"?" or "Do you really want to delete the selected group of objects?". Continue frantically pressing Esc twice so that the entire selection is removed ...

But why these difficulties. It is enough that the action with the object may be ONLY when the mouse cursor is over it and nothing else. The user pointing the mouse at an object sees what he deletes, moves, edits, and so on. If you need to perform an action on objects - select them and move the mouse cursor over one of them and pcbnew recognizes a group of selected objects; the action will be applied to this group - simply and logically. Nothing will be removed beyond scope (viewport). There is no need to press Esc many times to remove the selections and relax the soul: selections removed I can safely work on).

Even if an object is selected, but the mouse cursor is not on it, no erroneous actions will be performed on it, because the actions are performed ONLY on the object, over which the mouse cursor is located.

[Anton (antonpupkov)]

If you need to delete a lot of unconnected track segments, you will have to confirm the deletion dialog many times. This is pretty awkward.

[Matt Rohloff (mrohloff)]

A solution (in-part) would be to have the item(s) automatically de-selected after completing an action.

For comparison, this is how AutoCAD works.

[Anton (antonpupkov)]

KiCAD is not an autocad, blender3d, wings and so on!!! Is not an 3d 2d graphics editing software!!!

[Anton (antonpupkov)]

Main target is to make PCB manually or automatically, not an pictures or 3d models.

[Anton (antonpupkov)]

If you familiar with AutoCAD make your PCB with it)). Try, may be it be much faster))

[eelik (eelik)]

Anton,

your comments aren't useful. How other software behaves is completely relevant. Otherwise there wouldn't be menus, buttons etc. and no File, Edit... menu structures. It must be judged case by case basis. If something is problematic for many, then it's problematic. The basic tenet of usability studies is that users are always right when they feel something. But everything in software is a compromise so we have to live by practical realities and competing needs and limits.

You faced difficulties and want things changed but now seem to be denigrating someone else's thoughts.

Speaking of the matter at hand, I have thought this more over time. The current behavior of KiCad doesn't feel any easier. Nowadays it's relavant also for eeschema because of the new toolkit. I continually find myself moving a wrong item because something has been left selected, and the old toolkit worked so that I just moved the cursor and pressed a key on top of a new item. Only time will tell how it feels after months of continuous use (and I'm afraid I have to stop using nightlies at work now).

[Nick Østergaard (nickoe)]

I agree with #3. It may improve the situation for all if the item is deselected after an action is performed as autocad does. (someone suggestd this) But this may also expose other usability issues, we need to be careful here.

KiCad is definitely a 2D and 3D graphical CAD tool.

[Anton (antonpupkov)]

There are users who have been using KiCAD for many years, developing circuit boards. There are users who have worked for many years in GImp, AutoCAD, blender3d and they suddenly needed to make a PCB. Those tools that have been used in AutoCAD, Blender3D, and so on have been formed over the years by users who regularly used this software in their work, similarly to KiCAD. If we take and apply tools and manners from graphic editors, as their users say, KiCAD as a PCB design program will die. It will turn into a genetically modified vegetable: beautiful outside and no inside. I consider the priority to be those users who have been using KiCAD for many years. Naturally, everybody can speak. As for me, starting with KiCAD 5, developers are striving to make it more beautiful and add the same functionality that is found in modern graphic editors. KiCAD as software for developing printed circuit boards is slowly expressed.
What kind of compromise are we talking about? Make KiCAD a universal program for drawing and 3d-modeling?))
On the contrary !!! I don't want a lot of things to change in kicad. As I wrote above in this post, kicad took the path of external decoration and that's it. Some accelerated canvas added. What for? There was an error in pointing to the grid points. In the old canvas it was? What was wrong with the usual? He did not slow down a gram. How many projects I have on it (kicad 4.0.7)! I did not want to offend anyone. Who offended, I apologize.
As for the choice, wrote above. The existence of two ways of doing things leads to conflict. The habitual position of the broadcasts, which was in earlier versions of KiCAD, is rudely broken.
KiCAD is never a 2d or 3d graphic tool. Having the ability to view in 3d is for clarity and greater control. KiCAD draws not lines, points, fills, polygons, primitives, it draws printed tracks, copper zones, vias, footprints, text on the screen printing layer, and so on !!! This is the main thing. Have you ever designed circuit boards?

[Anton (antonpupkov)]

You need to think about printed tracks, holes, pads, vias, layers, layering standards for production and so on, and not lines, polygons, brushes, 3d models, meshes, vertices, edges and so on ...

[Anton (antonpupkov)]

I never use nightlies

[Anton (antonpupkov)]

Use release 5.1.2 it stable

[KiCad Janitor (kicad-janitor)]

Fixed in revision e691704a822816c8f734f3c43a828479900fd710
https://git.launchpad.net/kicad/patch/?id=e691704a822816c8f734f3c43a828479900fd710

[Seth Hillbrand (sethh)]

For now, I've enabled the option #2 for pcbnew edit actions. I'd like some feedback on this workflow change from folks. Are we bumping into new issues? Should we expand this to Eeschema?

Some issues I see potentially existing:
A) Actions may be triggered from other sources that expect the selection (we may need some logic in TOOL_ACTION for the ultimate action source and only accept keyboard here)
B) Cursor cross-platform differences if the context menu on MSW or OSX updates the cursor position before the action, we might have issues reaching some commands by right-clicking on the item. This works on Linux, but I'd like some feedback on whether it works correctly under MSW as well.

[Anton (antonpupkov)]

Yes. I think, for eeschema this way is good too. Single way selection for both eeschema and pcbnew is a good idea.I think that there were no problems in msw, when the context menu is called up (while moving an object) or the editing key is pressed on the keyboard, you need to use your program cursor or disable api msw cursor update. About x can not say anything. It would be good if you could return the selection of objects, if it was accidentally removed (undo selection), cancel the selection in two ways: by ESC with the current tool or via the context menu separately from the tool (cancel selection). The rest in the choice as usual: key shift, control and so on. Maybe it would be nice, in principle, to make a selection mode (like a check mark, which includes the ability to select, mass select objects).

[eelik (eelik)]

I, too, think that eeschema should behave like pcbnew. Especially because it behaved like this (cursor position says which item is acted upon) earlier before eemodern.

And restoring previous group selection would be a good feature. Sometimes I spend considerable time selecting and deselecting items (in pcbnew) to get the desired selection group. It's quite offpissing when it gets lost. With this change - which I quickly tested and found otherwise feeling good - accidental loosing of selection will certainly happen more often.