If there is, it seem to be a moving target - as I dig around and follow the leads, each one is a dead end or leads me somewhere else that isn’t quite right. I want offer an idea as a user, as I am not a developer.
[edit]
Oh - wait - posting it bounced me over into the right category. Weird.
Okay, as long as we’re here, has anyone ever proposed the inclusion of “strokes” - the mouse-gesture UI feature that Mentor Graphics uses? It’s absolutely wonderful, and the reason I’ve stuck with MGC under HP-UX for all these years. I’ve tried so many new and open-source packages and really would like to get modern (also, Mentor is extremely complicated), but every time I miss strokes too much and go back to Mentor.
Your post is in the Feature Request Chat category, and it’s meant for that. You can ask comments from other end users. In the end, if it leads to a polished feature request, it must be filed to the issue database in gitlab.
This feature is often called Mouse Gestures in other software (just posting this to help with search-ability) – “strokes” generally means things related to graphical line / text properties in my experience.
Hmm. Rather than just make a vague request, I have a few pages of crappy-but-readable scans from the Mentor manual describing their strokes that I’d like to attach so folks can get a sense of what I’m talking about, but that doesn’t appear to be supported here. How/where can I put it up?
Please post them, I’m quite curious about those mouse gestures in that other program.
My proposal for a mouse gesture in KiCad is for a very simple “auto router” function.
for example, you manually route a track out of an BGA footprint, and then you swipe it in some direction, and that track then gets connected to the nearest pad of the same net in the direction you swiped it.
This can speed up the routing because you can concentrate on your BGA without having to zoom in and out and pan al the time.
I assume it would be relatively easy to write such a limited function, and there are probably a lot more possibilities in that area.
Ah, thanks very much. As I said, a quick+crappy scan, but it’ll get the idea across.
It really is very slick - none of that constant back-and-forth between the work and
a palette (or using your other hand for hot keys) for basic functions like zoom, pan,
move, copy, route, undo, etc. Even the “help” on strokes is a stroke - a question
mark. I haven’t checked to see if this description (which is for the schematic capture,
known as “design architect” in mentor-speak) is complete, but can do so if there’s
interest; also, though most strokes are common across the system, there is some
context-sensitivity i.e. minor differences between schematic and layout.
I think once you see how they’re implemented in the Mentor case, you’ll see that
something this specific probably wouldn’t work. The strokes are general commands
defined by their direction(s) of motion, and what you’re suggesting would gobble up
every direction, leaving no room for any other commands. Perhaps this would work
as a stroke within a routing function, but my guess is that the most workable approach
to adding strokes in general would be to first implement the UI function, then consider
hierarchical, stroke-within-a-stroke nesting. Perhaps possible, but a little further away
from where we are at the moment.
It seems the mouse strokes are that ancient that there are no recent (less than 20 years old) documents or videos on it. This tutorial explains how they work: Introduction to Mentor Graphics
The basic idea is that the stroke (MMB, which I find awkward with most mice nowadays) is divided in a 3x3 grid and converted to a sequence of grid element numbers, an L being converted to 14789.
I’m most definitely here to advocate for its desirability. It’s easy - and a mistake - to take the position that it’s an old idea, and ipso facto one that is obsolete and inferior in a modern context. This wouldn’t be the first case of a great idea being lost because of an arbitrary (and essentially unrelated) decision made by a brainless monolith like u$, and the arguments in favour of three-button mice are manifold.
CAD in general - and, I suggest, EDA in particular - is much more demanding of the UI than the “dominant” (in market terms) applications like spreadsheets and word processing, and that extra finger’s worth of input ability makes a huge difference in speed and efficiency. In my own experience, in the 80s and 90s I used the old DOS version of EE Designer, which (though not using strokes) made excellent use of the three-button mouse. And I’d argue that one of factors in Apple’s early failure to seize a significant part of the CAD market was that they’d hobbled themselves with the one-button mouse (people tend to forget how many really stupid ideas Jobs had, and his notion of the “elegance” of a one-button mouse was one of them). There were companies that put out EDA software for Macs, and they all flopped.
We could dissect and analyze this issue at length, but at the end of the day it’s about how well it works. And if you talk to a Mentor user, you’ll get raves. You don’t have to work with strokes very long for your mind to automatically try to transfer the technique to the normal desktop windowing environment. Happens all that time that I’ll work for a while on a schematic or layout, switch back over to a non-CAD window, and catch myself trying to zoom or dismiss it with a swipe, bringing a “Damn! I can’t do that here!”
This is not a technique that a simple explanation can do proper justice to. You need to start using it, and then have your own “Where have you been all my life?” moment.
Oh - and thanks for that link. It’s a very nice introduction. For those not familiar with Mentor, it’s old-school grownup Unix workstation EDA. Used to be that schematic capture alone was a $25K per seat license. So those guys (and their users) were mos def not messing around.
At the moment both middle button + drag and right button + drag move the canvas. I don’t see a reason why there couldn’t be a configuration option to let either of them initiate mouse gestures. It would be optional and wouldn’t intrude any existing workflow. It would just take a dedicated developer. Frankly, I don’t see the current developers implementing this, but I also don’t see why they would veto this in principle if someone vonluteers to code it.