Selecting and moving qs

when moving parts around, there’s more than necessary mouse clicks and motions and keyboard interaction to do a job.
When I talk productivity, I am talking about reducing the interaction with the tool to do a specific job. It’s more than what some people say ‘a different way of doing things’ .
At the moment, without a selection filter, clicking on something to move it will bring up the resolution menu. Often it will bring up the primitives of a footprint and the footprint. IMO you never want to move the primitives of a footprint in PCB layout. You can and modify the footprint, make a new one or whatever of a primitive needs moving. Its extra work for the PCB person to clarify this sort of thing for the tool all the time.
image

So what is required here is a panel or a toolbar with a selection filter.
Allow the user to turn off what they dont want selected, this stops the tooling having to ask, and stops the user having to spent extra clicks to resolve the ambiguity.

apparently there is a selection filter but I dont have it, or its not being displayed !

View > Appearance Manager.

Found just the heading text (no check boxes) it under Thunderbird on a different monitor, thanks for that…

I am not so sure about that. You are still new with KiCad, and according to your profile you’ve been working with altium / protel for 35 years. You can get get the basics of a PCB design program in a few weeks (or any other program of similar complexity) but being productive with it takes more time and effort. When you wrote that, you had not seen the selection filters yet for example.

Also, when I want to move something in KiCad, I rarely use a mouse button, but use the m key instead. Because individual pads in general do not get moved, hovering over a pad and pressing m generally grabs and moves the footprint. When you click on an item to select it, there are too many possibilities to make a good guess.

There is of course still room for improvement in KiCad. A simple example, when I press m while hovering over a pad, and there are also tracks attached, then at the moment KiCad asks me whether I want to move the footprint or the track. And because tracks nearly always can be selected outside of a pad, it makes sense to select the footprint by default.

An additional problem is that UI changes can not be made too lightly, KiCad has a significant user base, and if too many things change from the way they work now, that will result in a lot of annoyance and complaints. Changes and improvements in the way KiCad work must fit within the current flow, or there must be very good other reasons for a change.

1 Like

Hi Paul
Fair points.
Yes there are a few different ways of doing things, like m. although I have not quite figured out when I can and cannot use m, or use left mouse drag.
On your ‘simple example’. In Altium they’ve tried a few variations on that… one was if component unselected, click and drag just moves the component. selected then click and drag, moves traces also. But not everyone was completely happy so it become a tick box option. I find there are few situations where draging tracks (stretchign etc ) does what you need.

One good one is ‘move attached primitives with component’. Example, on a stitching capacitor (1 x cap, 2 vias, 2 traces) …That is, rather than selecting the whole combination and moving it, the most popular has been if component is unselected, click and drag the mouse MOVES everything. and selected and click and mouse drag just moves the component.
(single click selects) .

In KiCad [Click + Drag] (when unselected) simply creates a selection box. But KiCad also has has the d hotkey for drag. It can drag a single footprint while keeping tracks attached. It is a relatively new function, and it does not work (yet) on for example a selection.

drag on a pad tends to grab an attached pad and drag only the track instead of the pad / footprint.

Also, people with much experience in other EDA suites can be valuable for the KiCad project. Knowing which sort of GUI changes work and which don’t is an important step. Making a writup for a decent proposal can then be a next step, but as I wrote earlier, changes have to fit within KiCad. And it takes some time to know both methods to be able to spot areas where KiCad’s GUI can be improved. KiCad’s way is quite heavily leaning on the use of hotkeys to directly select functions.

I can not make such proposals myself. I just do “hobby projects”, have been using KiCad for over 7 years and have forgotten how my previous program worked. But I do know that KiCad works better then that old program (Ultiboard 5.71 or thereabouts) ever did.

KiCad also has quite a lot of fun functions that improve productivity. For example the [Ins] key to repeat the last action (also with auto label increment) is a good example of this. Just recently I discovered that if you hover the mouse over a wire with a label, and then press l to start a label, then it automatically duplicates the label that is attached to that wire.

Another important difference is that bugs in KiCad actually get fixed. Simple bugs in KiCad are usually fixed within hours to a few days. I had a subscription for that ultiboard program once and they sent me CD’s with new versions every few months. They had so many bugs moving around that at some point I just settled on a relatively well working version and did not even bother to take new CD’s out of their packaging. It was quite atrocious.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.