I’d definitely prefer not “a tool for a primitive operation” but rather “a tool to perform a task”. E.g. instead of having separate tools (modes) for adding track segment, deleting track segment, adding via etc we should have a single tool (mode) that would allow making a required interconnection between two points. It shall be able to add track segment, delete track segment, add via etc without the necessity to switch tools (modes). It simply makes more sense to me and is more convenient. Most major PCB CADs either have such ability or moving towards having one.
You can make your voice heard here That is if anybody listening there at all. I submitted the bug report a long time ago which the developer in charge of that functionality marked as “Won’t fix”. But who knows. If enough people will mark the bug as affecting them as well, may be it will draw some new attention. Click on the pen graphics next to the words “This bug affects xx other people” at the top of the page and select that it affects you as well.
done & fingers crossed 
Umm guys, you do realize all this stuff is open source? If you don’t like it, you can fork it (or pay someone to fork it) and make it behave any way you want.
You do realize that open source doesn’t necessarily mean - my way (i.e. developer) or the highway. Just like any other product development cycle, it has a feedback loop.
True, but that is true of everything so is rather a redundant thing to say, and unhelpful. It is surely better for developers and users to cooperate and pool effort rather than everyone doing their own thing.
In this case, Kicad invite feedback, so it is bit disingenuous also.
Feedback
Please direct any bug reports, suggestions or new versions to here:
About KiCad document: https://github.com/KiCad/kicad-doc/issues
About KiCad software: https://bugs.launchpad.net/kicad
About KiCad software i18n: https://github.com/KiCad/kicad-i18n/issues
As for the general idea that voluntary effort should be beyond criticism, I have been pondering that. If someone runs a soup kitchen and gives a bunch of people food poisoning, or offers to restore a painting and completely ruins it (monkey Jesus) then they should probably expect some criticism. And it is inevitable that people will find it doesn’t suit their way of working, or will suggest improvements.
I have published some Open Source projects, and there a few people who just say “that sucks!”, but that is the same for any publication and is really the price of Free Speech. Mostly people even if critical are looking to improve the project, and personally if someone says “it’s hard to use” I use that as a starting point to try to find out what specific features could be improved, or whether it is a case of better documentation etc.
Really, it’s quite rare that users want to attack a project out of spite - they are usually people trying the best to do something, and are frustrated when something is near but just out of reach.
All I meant was if you really don’t like what they’re doing then fork the code. Code speaks louder than words.
That would assume we all are SW engineers but we aren’t
As HW engineer I might not know how to fork code and change it but I might have used 5-7 other PCB CAD tools and might have seen all of it: the good, the bad and the ugly (mostly “the ugly”). Therefore I respectfully supply my professional user feedback to KiCad SW developers. I don’t assume they accept it, I know they don’t have to as I haven’t paid for their efforts, but if we all try to use our common sense it might be beneficial for everybody 
1 Like
Technically, you don’t have to be a SW engineer to fork code. You can just pay someone else to do it. But that’s nit picking.
And yes, I totally agree, it is 100% beneficial in every way for everybody if we all use common sense to work together. That doesn’t always mean it will happen. If that’s the case, then forking is the relief valve you can always open. For a classic example, look at the ugly history of xfree86/x.org.
Don’t tell the vi guys that their editor has a silly interaction design (and please don’t start another editor war here…)
I personally can live with changing the editor mode for deleting a track, but not being able to undo a change in the track laying mode is a big hassle. But it seems that is being under consideration now. Using U/I for deletion is a big help, because I was switching modes for deletion until now.
Regarding the OpenGL issue: what card are we talking about in a 4 year old computer? I just checked with NVidia and AMD (for Intel we already got told that they support OpenGL 2.1 for a long time). For AMD, the newest GPU that doesn’t support OpenGL 2.1 is from 2006 (the X1000 series). For NVidia, the GF6 series from 2005 already support 2.1. Under Linux, its about the same. The proprietary drivers all support OpenGL 2.1, for the free ones Mesa3D must be installed. So it seems that either the driver is not up-to-date, or the hardware is really old (older than it should be). Basically each graphics card that you can buy today, even for $5, should support OpenGL 2.1. Personally I would expect that every modern OS already requires such a card to perform.
1 Like
[quote=“Andy_P, post:51, topic:1262”]
once that is done the older canvas will go away
[/quote] That’s exactly what bothers me. If not for that I would just happily continue using “legacy” mode until cows come home. The issue discussed in this thread is one of the most annoying ones with the new mode but unfortunately not the only one. I’m all for progress, but why not keep the things that actually worked and worked well and replace them with some asinine “features”?
From your mouth to God’s ears… From my interaction with developers on launchpad I’ve got a feeling that CERN guys got they own idea of the interface and how it should be implemented and they are not aiming to mimic “outdated” KiCad functionality.
Well, define “CERN guys”
Official list is here: http://www.ohwr.org/projects/cern-kicad
So as I understand neither project manager nor some most active developers are actually work at CERN.
It was more of a reply to @ArtG post. I remember those discussions on bugtracker and I can understand some of his frustration with KiCad developers. But it wasn’t only actual CERN employees who took part in those discussions and “caused” the frustration
We’ll enough offtopic on my behalf
Personally I very much prefer GAL (OpenGL) over the Legacy canvas. And missing legacy features are being gradually ported to GAL which is great. As HW Engineers who have probably used several commercial ECAD tools we can help KiCad SW Engineers to improve it based on our experience. We shouldn’t expect them to accept our common sense but I think overall it’s working out pretty well. I’m eager to see Eeschema in GAL!
Hey man, this is sparta^h^h^h^h^h open source. The developers are in the driver’s seat. Whether you like it or not, if you don’t code or pay someone to code, you’re a backseat driver. You are 100% at their mercy. If the gods^h^h^h^h developers take it upon themselves to pay attention to your pitiful complaints then thank your lucky stars. Life is unfair, deal with it.
I see the bug has been marked as fixed, while very much not being so. Is there another bug report/wish list to sign up on for them to fix these issues?
If a reported bug occurrs again, feel free to reopen it (change status to ‘New’ and add a comment explaining the problem + version information).
I have just tested track removal with the PNS router active and it works fine in the master branch (testing version). I cannot recall if it was ported to the stable branch (4.0.5 version), but it is not very likely. In such case it will be available in the next major release.
Most of these issues seems to have been fixed by now, thank you very much developers =)
There’s perhaps one nag left for me. I often disable the “Enforce design rules when routing” option (why does it ALWAYS have to default to on when restarting the program…). In the OpenGL canvas I’m still prohibited to end tracks on wrong pads. I often do this while routing, and later change the schematic to correspond when I’ve figured out the most convenient routing.
Actually I found that there is tick box in the routing options menu that allows DRC errors. Tracks still don’t snap to pads of a different net. If they did I think that would do away with that last nag of mine.
Because its dangerous to go alone?
I bet more than 90% of users want to build pcbs that follow their design rules. And they don’t want to discover that what they are doing violates theses after they have routed a lot. So it makes sense to never allow tracks that would violate design rules.
What are you doing there. This seems dangerous?!
1 Like
That’s why I use the DRC check tool when I think I’ve got things under control. And then I find where I screwed up…
Fanning out tracks from a controller it’s seldom obvious which will be the cleaner way to assign them. It’s just convenient not to need aborting laying down a track to move stuff out of the way, switch to eeschema to swap a few pins, do the whole dance of exports and imports, over and over again.
There is a time to kick the checking engines in, and there is a lot of time before that when they’re just messing with the process…