Drawing a Line seems to work different compared to the others. In the PCB editor all works the same. A bug or what’s the thought?
Which version?
I usually start line, click a few times, when want to lock a corner, the when finished - Right Click and choose Finish.
The line-tool is not a single line tool, but a multiline-tool. The multi-line is not finished after your second LMB-click, so the ESC key deletes the complete current work in progress.
One could argue that the ESC-key should not delete the entire work and that all already fixed line-segments should remain. (similar to the “route-track” behaviour in the pcb-editor).
Ok but it seems not ok or does it?
It’s just the current solution (at least for v6,v7,v8 and next year v9). So no bug, but as said maybe debatable how the ESC key works.
To end the multiline-tool:
- double-click with LMB
- or use hotkey “Finish current tool” (normally assigned to “End”-key)
I just want it to be a bit “logical”, these 4 graphical tools should work the same. What do I miss here?
3dogs was faster, but here is a longer explanation (I use it as training for the upcoming university lessons with foreign students - must be held in english):
Different tools with different characteristics are working different. I also like consistency between functions, but this is no end in itself.
-
rectangle:
- click: start rectangle
- click: end drawing rectangle, rectangle finished, tool still active (for next rectangle). ESC stops rectangle mode
-
circle
- click: start circle
- click: end drawing circle, circle finished, circle tool still active (for next circle). ESC stops circle mode
-
arc
- click: start arc
- click: end drawing arc, arc finished, arc tool still active (for next arc). ESC stops circle mode
-
multi-segment tool
- click: start multiline, first segment
- click: continue multiline, ending 1.segment and starting 2. segment. multiline is not finished
- click: continue multiline, ending 2.segment and starting 3. segment. multiline is not finished
- click: continue multiline, ending 3.segment and starting 4. segment. multiline is not finished
- …
- …
- in all these steps you are still drawing (extending) the same multiline. And if you hit ESC during a active operation Kicad kills the complete operation. Note that after ther first ESC the multiline tool is still active, because you stopped only the actual drawing. Only the next (second) ESC would also end the multiline-mode.
Due to the difference in operation (unknown ending of the multiline-tool against exactly ending of rectangle/arc/circle) it’s not possible to the program the exact same behaviour.
You should compare the multiline tool with the rule area tool (schematic or pcb) or the filled zone tool (pcb) or the graphic polygon tool (pcb). Similar requirements (kicad does not know the endpoint) → similar solution (==consistency)
Thanks, though that’s too difficult to me. Which of course will be fixed in KiCad 9.0, so no worries! It’s so far just a tiny bug.
At PCB (V 8.0.6) 3 clicks are needed and it seems better for me as I can make arc as I want it.
At PCB Esc kills only the last (not finished yet) segment of graphic line.
Yeah the tool is inconsistent it works differently in pcb editor and in schematics editor. So ESC works differently in each of the editors.
Also the symbol of the icon should probably be changed to reflect it is a poly line tool not a line tool.
Im still of the opinion that the primary reason for the kicad GUI randomness is that there is no overall design document that would guide and where one could discuss the central design of the UI.
So in summary:
- Line tool is different
- Bezier tool is different (new in kicad 8.99), why oh why
- Arc tool is different
There is simply no reason why it should be.
1 Like
“Im still of the opinion that the primary reason for the kicad GUI randomness is that there is no overall design document that would guide and where one could discuss the central design of the UI.”
Agreed. I have for example also mentioned a few times that the Tab Functions/Order mostly is about chaos. These things, which might seem minor for some, is important to get a “pro” feeling of this application.
I have understood that you mean the Tab key press which goes to next GUI control. That one doesn’t need any discussion or design document. Just someone who is willing to learn how this is done in wxWindows, then edit the dialog files, using one’s own judgement for making decisions about the order. As long as you do this specific thing only, you can’t mess it up or make it any worse than it is now. This doesn’t even need any real programming skills, only finding the correct way to do it in certain kind of text files and then repeating it mechanically, while going through all dialogs in the UI and in the files.
What it needs is large amount of free time, dedication and patience. So much time that it would be waste of precious resources to make one of the main developers do it. They can give much more to the project by developing features and fixing functional bugs.
I don’t disagree on the value of good GUI design, usability and UX. I have contributed to another Open Source project as a main developer, and I re-arranged some tab press orderings. It was in Qt framework, I don’t know how it works in wxWidgets. But you don’t need a “real programmer” for this task, let alone one of the main developers of KiCad.
After writing that in PCB arc works differently I thought a moment and get to my conclusion that function of arc at PCB is for me different than at schematic. At schematic it need only to look correct and nothing more, at PCB in many cases it have for example to have its center in specific point (for example when constructing round coil).
In V5 drawing the L symbol I was not able to use 180° arcs. When I tried to move arc center just between its ends arc jumped to the other side.
How now arcs work in schematic is for me good - I don’t need anything more from it.
At PCB I have a problem that I would like to have one more arc editing mode. I have written it year ago as feature request:
There are two examples - one whole PCB project in zip and second PCB shape shown in my text.
Thanks for your reply, eelik, I’m not a programmer, just a user, and I want Kicad to be better, in many ways. It’s already for sure good and very usable and the progression over the years has been fab, but it can of course get even better!
Goodness me, stop with all the Kremlinology and “just asking questions”.
Without reference to an specific person or comment, all I will say is that any engineer would know that “why can’t they just?” and “how hard can it be?” is the eternal refrain of the under-skilled, under-employed and over-opinionated.
The code is available for inspection, as is unbroken line-by-line history spanning the last 17 years, not to mention the issue tracker, mailing list and a large cadre of people who actively wish to share information about it. The answers to these questions are quite plain if you would only care to look, or even ask properly. Along with, I might add, a idea of how much work by how many people has been put into making it possible to harmonise these specific tools and how close we’re getting/have already gotten in many places. A pattern mirrored in hundreds of places in the project.
And if you can’t manage that, or even the barest minimum of just engaging positively and in good faith, spare us the cycles and go and pay for some software where you can carp to your heart’s content on their forums, safe in knowledge that 1) someone is at least being paid to pretend that they care about another low-effort complaint from That Guy Again, 2) they won’t actually fix it and thus you can just complain forever without even having to make the sad effort of finding something else to moan about when your favorite bugbear is fixed and 3) you aren’t allowed contribute so you have an ironclad excuse to never lift a finger constructively.
1 Like
Ok. I stop. No more stupid questions or so from me.
The thread has run its course.