While the OP’s post is perhaps a bit of a long rant about a rather trivial, albeit at times extremely annoying, it is not “simply silly”. It’s possible some of these issues are slowly being fixed in the nightlies but not everyone uses the nightles and these issues do exist in the most recent stable release.
The only part of the OP’s post I disagree with is …
It is quite common in CAD to have the cursor return to the previous position on the canvas before the context menu was invoked. This behavior in Kicad is as expected, although occasionally the mouse does end up somewhere unexpected.
If I do this I get the grid-context menu and when I close it I am returned to the “Clarify Selection” context menu.
Well, that is my opinion; should have stated, “in my opinion”.
While I am currently using a “nightly”; I had been using “Official Stable” for quite some time and never found the mouse jumping problem the OP and other have stated.
Yes, the mouse does jump; and it goes exactly where I expected it should go ( always has ).
Is this a xx.xx.06 issue?
I’ve easily spent over an hour trying to figure out the complaint to determine if I could think up a solution. Even after your post, I’m still trying to find the original problem.
I’m starting to think it is a OS and Mouse settings issue; and not really related to KiCad at all.
On Edit: Basically, I can not ever remember having the problem, and I can not currently duplicate the problem.
Well the rest of us must be imagining things then, at least that’s your opinion.
The behavior of the “Clarify Selection” context menu is very inconsistent. I have just checked and it indeed does what I stated above, sometimes! In fact if I left click on a junction to get the “Clarify Selection” (CS) menu and then I click on the menu’s title it closes the menu. However, if I right click on a junction to get the “CS” menu and then click (left or right) on it’s title the “CS” menu closes and the grid context menu opens. If I then click “Close” in this menu it closes and both menus remain closed, most of the time. Occasionally closing the grid context menu returns to the “CS” menu. It’s really rather unpredictable, at least I haven’t yet found the circumstance that causes it to reopen the “CS” menu.
And clicking on the main window title bar while any context menu is open causes the entire window to move down the screen to where the menu was.
As I said earlier these things might be fixed in the nightlies which explains why you can’t reproduce it. But this issue and several other GUI inconsistencies have existed since 4.0.1 and remain in the current release.
I found it! Right click on a junction (or any other point where there are multiple objects) to get the “CS” menu, then right click outside that menu but not on any other object and you get the grid context menu. Now, instead of selecting “Close” left click outside that menu and the “CS” menu pops back up.
Another interesting one I found. Right click to get the “CS” menu, now while that menu is open right click on another nearby object (a single object or you get another “CS” menu). Weird things happen. What happens is the cursor snaps back to it’s origin position and if it is now over an item in the new context menu that item is actually selected. To see this hold the right mouse button down when right clicking on the single item, the new context menu will appear and the cursor snaps back and you can see the item that will be selected. It might delete the node or connection or bring up the label properties dialog or simply zoom.
If the cursor is not over an item in the new context menu then it just displays the menu but left clicking outside that menu will again return you to the “CS” menu.
I think the warping makes sense if you use keyboard only. Generally I use mouse + a few key shortcuts, but recently I found that many operations can be done with keyboard only, and it is almost better than the WIMP method. The tedious bit with the keyboard-only approach is moving the cursor; the warping method minimises the amount of cursor moving required.
I find the warping weird, but have gotten used to it. I would not implement warping in any application I write. Occasionally I find the whole Kicad window jumps somewhere unexpected.
As someone who writes software, what people mean by “good” or “bad” interface really means “does exactly what I expect”. Since people have very different expectations, it’s almost impossible to create a universally “good” interface. I can put in alternative methods, but then each type of person will demand that is the default. Some people even ask that the alternative method is removed, just in case they “accidentally” select it.
The first time I used KiCad, after a few days I had several pages of A4 of things I would like to change. I decided to throw that away, embrace the oddities and just try to get on with designing boards…life is too short.
tldr; you can’t please all the people all the time. Corollary: no software is perfect.
[quote=“Sprig, post:15, topic:7077, full:true”]
The complaint by the OP seems to me to be simply silly.
While WORD or EXCEL might not move the mouse pointer on different left/right mouse clicks, the purpose in a ECAD program is entirely different.[/quote]
While Word and Excel are entirely different indeed, where did I ever give you the idea that I was comparing KiCAD with them? I’m comparing KiCAD with many other CAD packages, none of which exhibit this behaviour, and most of which follow standard design paradigms so that moving from one application to another isn’t an awkward, jarring and counter-intuitive experience.
Besides, what particular property of an EDA package is it that requires pop-up menus to behave differently to practically all other pieces of software, both CAD and non-CAD.
Well, the problem with people who are invested so much in something as you appear to be, is that you can’t see the faults that others talk about in your beloved software. It’s great that a non-standard way of working happens to suit you, but at least consider the possibility you’re in a minority, and take a step back to at least see what other people can see.
Funny, it’s the only warping function that includes the possibility to disable it (which is one of the first things I did).
[quote=“1.21Gigawatts, post:21, topic:7077, full:true”]
While the OP’s post is perhaps a bit of a long rant about a rather trivial, albeit at times extremely annoying, it is not “simply silly”. It’s possible some of these issues are slowly being fixed in the nightlies but not everyone uses the nightles and these issues do exist in the most recent stable release.[/quote]
Thank you!
[quote]The only part of the OP’s post I disagree with is …
It is quite common in CAD to have the cursor return to the previous position on the canvas before the context menu was invoked. This behavior in Kicad is as expected, although occasionally the mouse does end up somewhere unexpected.[/quote]
Hmmm, it’s not something I’m used to at all, and I use a number of different CAD packages (AutoCAD, Mechanical Desktop, AmiCAD, Eagle, Cycas, Solid Edge, Solid Works…) Perhaps it’s a configurable option that’s available but I have never enabled?
KiCads user interface is evolving as the various components are getting better integrated.
The schematic part is in a major rewrite, that certainly won’t be finished this year. The current menu structure is clumsy and inconsistent
My experience of commercial PCB software is just as bad, I have never come across ECAD that could honestly be called intuitive. Training is a money spinner for many suppliers
Yes, they all have their quirks, but none that I have used break UX guidelines so fundamentally or frustratingly as KiCAD. Or in ways that would be so easily fixed by the developers.
Anyway, if there’s a nightly that was mentioned that does not have warping enabled in it, I’m willing to try it out for a week or two, but otherwise it’s shelved until it’s had a bit more polish.
if you find just hitting ‘Esc’ a blocking feature for embracing a powerful open source ECAD, no problem at all…
[ probably you will be back soon, considering the other options out there ]
if you find just hitting ‘Esc’ a blocking feature for embracing a powerful open source ECAD, no problem at all…
[ probably you will be back soon, considering the other options out there ][/quote]
No, hitting Escape isn’t a problem, but that’s a work-around for unintuitive UI behaviour and isn’t a substitute for my suggested change, which was having an option to disable the mouse warping “feature”. Besides, hitting Escape also warps the mouse, which may have been a good idea in the '80s when CAD packages were predominately text driven an a mouse was an optional extra for most computers, but doesn’t fit well with the modern (as in the last two decades) model of mouse-driven software.
Some other CAD packages (e.g. Solid Works) also use hitting Escape as a method of cancelling the current command (along with an entry in the right-click menu), but they certainly don’t warp the mouse when you do.
I’m not sure I’ll end up back here to be honest. You’re probably right in that the other options aren’t going to be any good. But being the best of a bad lot isn’t the same thing as being good, and while I’m all for open source software, I’m not willing to make massive sacrifices in usability for that ideal (this “feature” isn’t the only potential deal-breaker in KiCAD - it’s just the most obvious one to me). If there are no other suitable alternatives, I’ll end up back with Eagle unfortunately.
It took me a while, but I finally realized that this whole topic is a non-issue. The OP wants to use the program in way that it is not designed to work. The mouse “snaps back to grid” to allow operation/edit of the item that was selected in the first place.
If one uses the mouse primarily, to place a wire one would click the “Place wire” icon in the right menu bar. Left clicking anywhere, starts a wire. If one chooses to right click on a junction (instead of simply left clicking) then one is given the option to “Begin Wire”. Yes, the mouse goes back to the center of the junction. Why should it not? That is the specific location where the user initiated the command.
Should the wire start where the user clicked inside the menu bar instead? Or should the user have to manually move the mouse back to the junction to start the wire?
With the “Arrow” selected in the right menu bar, left clicking brings up the “CS” menu. What is so difficult about not left clicking on the junction without making a task selection from the right menu bar (or hot key) in the first place?
The user then has some choices. What is so difficult about just clicking the “x” selection to close the box? Or, right clicking outside the box, then right clicking a second time. Or, just depressing the “Esc” key?
But I have to ask again, “What is so difficult about not left clicking on the junction without making a task selection from the right menu bar (or hot key) in the first place?”
Eescheema requires that items are aligned to the grid to ensure connectivity. Having the cursor “snap-to-grid” at the location where the command was executed is a feature, not a failure.
Why does anything have to connect with the cursor? Every other CAD package allows objects to snap to a grid without the mouse cursor itself having to snap to the grid. I have to wonder now if you actually use any software other than your beloved KiCAD. Because that last point makes no sense other than from the perspective of making feeble straw-man excuses in defense of a package that can do no wrong in your eyes.
If a user left-clicks on an icon in the right menu bar, or makes the selection with a hot-key, then KiCad Eescheema functions EXACTLY this way. The cursor shows the grid the item will be placed on, and it is not the location of the mouse pointer.
Right clicking opens menus. If a user chooses to right-click and open a menu, why would that user expect the cursor location to warp to the mouse pointer location when making a menu selection?
For example, to draw a wire and change between the 100 and 50 mill grids during the draw. There are two choices:
Warp the mouse pointer back to the cursor.
Randomly draw the wire to the location of the mouse click where the grid selection was made.
If a user chooses to add a part to the schematic, left clicking the “Place Component”, and then left clicking when the cursor is where you want it on the grid brings up the “Choose Component” menu. Same two choices now.
Warp the mouse pointer back to the cursor.
Leave the mouse where it is and drop the part onto the schematic on whatever grid happens to be under the mouse pointer when navigating the menu.
It should be obvious by now why I think most of this is sorta silly.
If you left click, it works exactly like the OP wants.
How many complaints do you think there would be if the mouse pointer did not warp back to the cursor after invoking and making a menu selection?
Many from you and a loud minority I’m sure, but for people used to using any other packages, none. And those complaints from you and the rest of your minority could easily be appeased by offering your preferred behaviour as an option, rather than enforcing it as it is currently.
It’s clear that you have no interest in any sort of improvement that might expand the KiCAD userbase. It happens sometimes that people like the feeling of using some niche software, with its arcane methodologies and behaviours, for the “because you can” factor or whatever. There are others however who might like software they use to expand beyond the inner circle of loyal fanboys, but it’s clear that the KiCAD community isn’t well furnished with such people.
As I said before, there are plenty of other UX issues that all add up to an impression of KiCAD as a great concept that’s about 80% finished, with little desire to push on for the last 20%. But for now, that’s not good enough for me so I’ll leave it alone. Perhaps I’ll check in again in a few years when the editor UI rework is complete, but for now I’m gone. Thanks to you and everyone else here for giving me a clear picture of the current state of KiCAD.
Sprig is clearly on a different page, and still confusing nightly versions with release versions. In any case nothing we say here is going to effect any change. I don’t think the mouse snapping back to the canvas position where the menu was invoked is quite the show stopper you make it out to be, it’s certainly not that unintuitive. The inconsistent menu behavior is much more annoying but still not a show stopper. While EESchema is currently undergoing a makeover you can lodge your complaint/request.
KiCad, despite it’s peculiarities, is a very useful and functional tool and well worth learning to avoid or workaround it’s various pitfalls. It’s certainly not unique in that regard.
Thank you again for injecting a bit of understanding and realism. Clearly they are things that can be worked around, my decision is whether I would prefer to put up with an awkward and hobbled-by-design interface, or go back to Eagle’s less-user-friendly licencing schemes and less terrible interface. Currently, and unfortunately, the latter is ahead by a fair margin.
