Why does Eeschema ever do anything other than rubberband wires?

I had opened a bug a few days ago, and after a very productive & helpful discussion with the developer I have agreed to close it. Regarding Eeschema, normal window select (left to right) or “greedy select” (what a term!, right to left):

I was having difficulty to drag portions of my schematic. I wanted wires to rubberband but if the wire was selected in the group to be dragged, it would move more like a solid rod (thus screwing up connections on either end) rather than rubberband. Part of the issue (Windows 10) is that I did not know to CNTRL-Click to toggle the selection of individual wires or symbols in the selection window.

Another difficulty is that I cannot add to or subtract from the selected group after I have tried to drag it and found I needed to add or subtract wires or symbols. I need to start over. This is clumsy.

Question to all users of Eeschema: What is the point of having wires move as fixed length rods rather than rubberband? I do not see any point to it. What am I missing?

Compare to operation of ExpressPCB classic which always does a greedy select and which always rubberbands wires. This is a very light program (very few features) but I find that schematic editing in ExpressPCB is easier than in KiCad.

Application: KiCad
Version: (5.99.0-817-gad3c4b37a), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    Build date: Feb  1 2020 22:00:50
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.71.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.66.0
    Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

Do the selection and then press the TAB key. With version 5.1.4 on linux, the wires rubberband.

1 Like

Thanks. I do not use Linux but I guess I can try that and see if it works with Windows 10. My question might sound sarcastic but it is not intended that way. What is the purpose of a wire not rubberbanding? Do you find that to be a useful mode of editing? My point is that if nobody finds that non-rubberbanding mode to be useful, why does KiCad operate that way? On the other hand, maybe I am missing something (but I think I have all 3 fingers.) :slight_smile:

The software is undergoing constant development, it is not possible to implement everything at once, if changes are suggested or required they have to be given a priority and dealt with as (volunteer) time permits.

You could have of course linked to the mentioned report: https://gitlab.com/kicad/code/kicad/issues/3840.

See also “Orthogonal wire drag”:

And this leads to a question: why would KiCad should allow non-orthogonal lines when dragging if the user hasn’t allowed them? This leads to speculation about how it should behave in details - where the corners should be after moving etc. It’s not a simple question. Just try to come up with logic which satisfies everyone so that the wires don’t need cleaning up afterwards.

And to takes things further - and to answer to your original question - let’s suppose I want to move a block beyound another block. For example in your screencast left or right outside the current view. What should happen to the wires? What does your application do? I suppose it doesn’t do anything intelligent. You have to redraw the wires. Is it easier to clean up from the result of rubberbanding or do it from scratch? I think sometimes cleaning up is easier, but sometimes doing from scratch. And now the question has been answered.

So, in an ideal world there would be autorouting for wires. But as we all know, knowbody has made a reliable, fast and easy real-time autorouter for layout, either (in the whole industry).

BTW, for comparison, here’s how 5.99 works for me:

If you move a selected box along wires than drag mode could be useful. But I don’t remember I have ever done such move.
I typically have vertical bus (or two) and several pieces of schematic attached to it. When needed some room for one more piece I move them vertically or to the other bus. Try to do it with drug mode :slight_smile:
I prefer the default behaviour as I can just select and move the schematic block (with bus entries) where I need it and no wires drag after me.

Not quite correct.

The schematic wire autorouter from xlinx in ISE and Vivado work quite well, though without to claim being perfect.

1 Like

I may take a beer or two every now and then, otherwise I don’t take drugs. But I’m curious if someone else have experimented with KiCad like that. :laughing:

:laughing:
It took me some time to understand. I read (probably wrongly) both words the same so see no difference.

I just confirmed this works w/
Application: Eeschema
Version: 5.1.5+dfsg1-2~bpo10+1, release build
When done moving the components, press
Shft-TAB to de-select the group from dragging/moving.
Thanks @slc for the pro tip.

Hi, Russ

Shift+tab does not work for me using Windows 10. What OS are you using?
Cntrl Key does work to toggle items into or out of the selection group.

64-bit debian linux codename buster

TAB key does not do it in Windows 10. CNTRL key does.

GITlab is something which I far from fully understand. Anyway I thought I captured the essence of the discussion in my post.

In my opinion what you want to do in that case is cut and paste, not drag. CNTRL-C and CNTRL-V are the conventions in Windows for doing that.

I agree with your video. But you selected only two symbols, not a group which includes a bunch of wires. I am thinking that what I really want is for wire ends and junctions to drag, but not wires unless they are fully included in the selected group.

Just to poke fun at Piotr: In drug mode everything works or nothing works or it does not matter. Seriously I have deep respect for all of you working in English as a Second Language ESL = Equivalent Series Inductance.

Aspirin and IPA are my drugs of choice; not both at the same time. :slight_smile:

Not really: it’s a normal “move by dragging” operation. In eeschema (5.99) G is drag, M is move.

But I’m a bit confused. By now it should be clear that you can “box select” greedily or non-greedily, by dragging the selection box corner left or right. You can add to it another box selection by keeping SHIFT pressed down. You can add items by keeping SHIFT pressed and clicking. You can toggle the selected status of an item by keeping CTRL pressed and clicking. So, selecting shouldn’t be a problem.

What do you mean? I can select, drag, click to end the drag, change the selection (add or remove as described above) and drag again with the changed selection. There’s no need to start over. I can use CTRL+Z, normal undo, to go back where I was - it even remembers selection.

KiCad can do greedy selection, is there a problem? KiCad seems to rubberband wires always when dragging with G, what is the problem?

I don’t understand. I can select or deselect what I want, including wires and junctions, and it drags with rubberbands. Can you give a specific example where you can’t do what you want?

1 Like

OK so far so good. At the beginning I was using only Shift+Click and not CNTRL+Click

Cannot do that. Once I begin to drag, the group is stuck to the mouse even without me depressing the mouse button. If I need to then add or subtract from the group I cannot because the group follows the mouse. If I hit escape key then I need to start over.

EDIT:

Oooh…OK. Was not aware of CntrlZ for undo. My thinking is that dragging should only happen when I hold the mouse button down. If I release the mouse button then I ought to be able to add or subtract to the group before dragging again. So CntrlZ seems like it can work but also seems like more steps. Cannot do this with menu edit-undo because the group will simply follow my mouse as I go up to click on the menu.

It is not my intent to promote other software. But if anyone is willing to see how moving (dragging) works in ExpressPCB:

  1. Select the group of symbols and release the mouse button. The selected group changes color.
  2. Click on the group and hold the mouse button down. No command is needed.
  3. Drag the group with the mouse button held down and release the button when the group is where you want it.

If ExpressPCB were perfect I would not be using KiCad. But I do not see any disadvantage to this much simpler and more intuitive editing operation.

For starters, let’s make it absolutely clear that I’m talking about 5.99. I believe you do, too, because you gave the version information in the first post.

5.1 is very different: if you select a group, it begins to move (i.e. the selection is detached) immediately when you move the mouse.

In 5.99 you have to initiate moving or dragging. You can click on the selection and move the mouse. What happens should depend on your settings:

image

At least that’s how I interpret it. But it doesn’t work - I reported a bug: https://gitlab.com/kicad/code/kicad/issues/3861.

If I understood it correctly and it’s fixed, KiCad can behave exactly as you describe ExpressPCB.

But what does this mean:

As I said, this is how 5.1 works. 5.99 is different.

Hi, Eelik

Thanks. That information is excellent.

Yes…I thought I noticed some difference in the behavior but did not remember for certain. In 5.1 was it necessary to hold the mouse button down in order to do this drag?

No, vice versa. In 5.1 you can’t move the mouse without moving the selection. In 5.99 you have to explicitly initiate moving with mouse click or a hotkey (just like in any normal software).