KiCad OpenGL is painful to use

[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” :wink:

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 :wink:

We’ll enough offtopic on my behalf :slight_smile:

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…

Not automatically resetting DRC on at opening is incredibly dangerous for most users

2 Likes

I think that if I choose to disable it I probably want it to still be off when I pick up where I left. It should be a project specific setting. It gets old pretty fast needing to go in and disable it each time the program crashes, already started doing a few twists and turns on a new track again…

Well lets just say for this (very dangerous) workflow the current implementation is a small inconvenience.
Implementing it so that you are not inconvenienced might lead to a lot of pcbs which are useless because some user forgot that they had disabled drc.
(or at the least lead to a lot of work once this user finally runs a drc check and discovers that everything on their beautifully laid out board violates the drc.)

In my opinion no software should focus on non standard usecases. (Especially if this usecase conflicts with the standard usecases in one way or another.)

1 Like

Staying shy of the f-word I think it is insanely annoying with all the DRC interference before the very last stages of laying my boards down. That option resetting itself is probably my biggest everyday gripe about KiCad. I can tell from the clearance indicators when laying down a track that it is too close to that other track fitting through that passage. I don’t care, just let me put it down, my next step will be to come back and nudge the tracks around a bit. The majority of work is in finding the general routing scheme, after that it’s a much shorter process distributing spacing and aligning stuff up neatly. Then, not so much before, DRC starts being useful. And not running a proper DRC check before calling the design final is simply award worthy. Pulling number out of my ass I’d say 98% of the process is about convenience, 2% about eventually adhering to the design rules.

By the way i just discovered (in horror) that in my nightly builds the allow drc violation box stayed ticked when i closed the software. (It doesn’t even matter which project i open. It stays that way until i change it back.)

(I wonder if newer nightly builds also behave this way. Mine is now 4 or 5 month old because nobody builds new ones for fedora.)

IMHO it would be no biggy to add an extra tick option for the DRC enable/disable option that let’s one chose to ‘keep setting until I change it’ and maybe even a serious warning if you activate that (for noobs).

@bpiphany, if you can’t program yourself either find or pay someone to do it and put it into the code.

It is off-topic, sorry.

I don’t agree with this statement I have read many times. Although most of my work is hardware design, I also program microcontrollers.
As a programmer, I feel happy when people using my programs are happy with them. For me, it is the greatest satisfaction and maybe it is my aim for open source hw/sw.

We should make a big difference between people complaining and demanding features as babies and people pointing out flaws in the code, helping the programmers to make a good more usable tool.

I’m aware I can’t complain for something given open and free. I can only say “Thank you!”

At first, I used to answer people fuming against an opensource program, telling them “if you don’t like it, don’t use it but don’t blame”. Now I just ignore them.

So welcome users helping to improve the OpenGL canvas without loosing legacy features.

Because of everything I explained above…

The option “Magnetic pads - Always” is also broken while laying out tracks in OpenGL. They simply don’t snap as they should, always, literally according to the setting (which I seldom use, but that’s not the point). There are other reasons for snapping than ending a track there as well. I frequently use pads simply for aiming, that way traces fall down evenly spaced.

Now that the new push-and-shove router seem to have most of the functionality from the old canvas it may replace much of the “sketching” work needed to be done before. At least I find most layout work is moving components around drafting tracks all over the place to see what fits and not. Move stuff around some more, making a mess all over the place. 110 times of 100 the DRC is just f****ing annoying. When everything starts to fall into place, I know the overall routing scheme I’m going to use, I have all pin assignments sorted out. That is when DRC begins to play a role.

I’m super grateful for KiCad and the developers working on it. I try to express that, and I understand people have different opinions. I’ll adapt to how the program works, but I’m going to say so if I think something is annoying… Perhaps developers simply haven’t seen things from my point of view.

DRC is freaking annoying at the sketching stage of development. I can’t be the only one who needs to make a big mess out of things before the optimal solution start to crystallize out of it…

I suggest a different approach then… open a new thread and ask how others deal with the problem of having a high pin count bga/qfn/etc. device which offers pin mapping and how people go about developing the layout while being flexible with the schematic connections. :wink:

And my former response was just honesty in regards what could be a solution for you. I’m not a developer for KiCAD, I just help on the forums here and am happy what KiCAD can do :wink:
If you want to try to get the idea noticed with the developers it needs to be filed on the buglist as wishlist item… but for that to get anywhere one would need to drum up some support here and have a lot of supporters - possible that a dev likes it as well and wants it. A more fail safe way is actually providing code that does what one want’s and trying to get that pushed into the software via pull requests and being on the dev mailing list.

3 Likes