KiCad gripes list - post gripes here

[jsquaredz]

Let's put together a list of gripes about KiCAD.  My intent is to be as comprehensive so I can go through the bugs list on launchpad and make sure all gripes are submitted for evaluation by the new dev project manager for the next release after the new stable is released in July.
I will consolidate the gripes at the top of this post and in a google sheet. This sheet is also editable by all, so feel free to update it and if you know something has already been solved in the current build, then you can note that.

PS  I really like KiCAD, but as many of us users know, there is a lot of potential for improvement.  Lets tell the Devs what we really want and how we want it to work.

https://docs.google.com/spreadsheets/d/1runOkCoLX0lRAS_svmz9kO9Lydj9lR_2YHzMhu6pIQw/edit?usp=sharing

4   No "save as" option in schematic editor, SERIOUSLY??
27   None of the programs remembers last opened file dialog, have to enter same directory each... and... every... time
29   Windows installer doesn't automatically associate file types
30   Windows Version development builds don't have a BZR number, or at least the one I use doesn't. This can be found by looking in control panel->uninstall.
32   Windows Version: When creating a new project the file kicad-dir/share/template/kicad.pro is copied to kicad-dir/noname.pro, this causes an error in windows since file writing is not normally allowed in "Program Files" (install to other folder works fine). Also, this causes all you files to be named to noname
33   Add Delete node hotkey "backspace"
35   Full screen cursor is not working in the current MAC build 5717
36   Ability to create inverted text (text etching on copper layers)

[firewalker]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

[jsquaredz]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

Thanks.  I added it to the spreadsheet.

[Thor-Arne]

This is a good idea. 

Hopefully stuff will be fixed and optimized.

I use the kicad-product-r5640.
Quite happy about this version, but some things are really sluggish (part selection. switching canvas).



Build issue(?):
The development builds doesn't have a BZR number, or at least the one I use doesn't.
This can be found by looking in control panel->uninstall.

Windows installer:
Only main program (kicad.exe) and pcbnew is registerd on the start menu.

General:
(#2 on your list) When creating a new project the file kicad-dir/share/template/kicad.pro is copied to kicad-dir/noname.pro, this causes an error in windows since file writing is not normally allowed in "Program Files" (install to other folder works fine).
Also, this causes all you files to be named to noname.*.



For your list I have these comments:

3
Not entirely sure what you mean here.
Active libraries comes from the .pro file which is copied from the template upon creation.
IMO this is just fine, all libraries should be there by default, and you just remove the ones not needed for that project.

4
The save-as menu appears if you open eeschema directly, but not if you open it from a project.
It seems like this is a deliberate choice by the developers, why I have no idea.

6, 9, 10, 11, 18, 20, 23, 26,
This works just fine in my version.

12
I don't consider language in a library to be a kicad bug.

14
Moving components (M key) shouldn't preserve wires, use drag component (G key) to preserve connections.

15
Use delete node (no hotkey, should be backspace) to delete part of wire .

24
This is to be expected since the libraries is defined in schematic editor and stored in the .pro file.

[c4757p]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

I actually just submitted a patch that fixes some of that, hopefully it's committed soon.

[c4757p]

12
I don't consider language in a library to be a kicad bug.

It is one though, but not against kicad, against its libraries. Language should be consistent.

[Thor-Arne]

Yes, I agree, language should be consistent.

I'll admit I haven't looked at the libraries on github.

[jsquaredz]

Thanks for your post.  I have incorporated your input and reposted the list.  Also updated the spreadsheet.

The original list wasn't mine, but some items I found in this forum someone was complaining about KiCAD.  I figured there were a lot of the items that would have been solved but hadn't had a chance to check them all yet (believe the person griping was using the latest "stable" build.

This is a good idea. 

Hopefully stuff will be fixed and optimized.

I use the kicad-product-r5640.
Quite happy about this version, but some things are really sluggish (part selection. switching canvas).



Build issue(?):
The development builds doesn't have a BZR number, or at least the one I use doesn't.
This can be found by looking in control panel->uninstall.

Windows installer:
Only main program (kicad.exe) and pcbnew is registerd on the start menu.

General:
(#2 on your list) When creating a new project the file kicad-dir/share/template/kicad.pro is copied to kicad-dir/noname.pro, this causes an error in windows since file writing is not normally allowed in "Program Files" (install to other folder works fine).
Also, this causes all you files to be named to noname.*.



For your list I have these comments:

3
Not entirely sure what you mean here.
Active libraries comes from the .pro file which is copied from the template upon creation.
IMO this is just fine, all libraries should be there by default, and you just remove the ones not needed for that project.

4
The save-as menu appears if you open eeschema directly, but not if you open it from a project.
It seems like this is a deliberate choice by the developers, why I have no idea.

6, 9, 10, 11, 18, 20, 23, 26,
This works just fine in my version.

12
I don't consider language in a library to be a kicad bug.

14
Moving components (M key) shouldn't preserve wires, use drag component (G key) to preserve connections.

15
Use delete node (no hotkey, should be backspace) to delete part of wire .

24
This is to be expected since the libraries is defined in schematic editor and stored in the .pro file.

[Wilksey]

If you run EESCHEMA on it's own it has a save schematic sheet as option.

The BZR version can be added to a version.h otherwise it will default to a "unknown, before may 2015" or something "version", I always add the date and revision number to my version.h before building, that way I can keep portable versions and know what they are.

If you run PCBNEW and EESCHEMA outside of the main KiCAD project editor then you get more options, might be worth looking at if you think something is missing.

Thankfully you can move away from using CVPCB now, and adding the footprints at schematic level, the footprint editor still leaves a lot to be desired, but there has been some decent improvements over the last year or so, and for the price, you can't grumble, I rebuild every week and sometimes see differences, sometimes not.

[Bassman59]

Thanks for your post.  I have incorporated your input and reposted the list.  Also updated the spreadsheet.

The original list wasn't mine, but some items I found in this forum someone was complaining about KiCAD.  I figured there were a lot of the items that would have been solved but hadn't had a chance to check them all yet (believe the person griping was using the latest "stable" build.

Depending on platform, the "latest stable bug" may be quite old indeed.

[c4757p]

Even the latest official stable is ancient, we've been discouraging its use for a while now. Development branch is almost ready for release and will be released soon.

[zapta]

I tried kicad a few months ago, looking for an eagle alternative.  My main qualm was the need to go through a schema export to start the layout. Why can't it has a single repository for the design and having both the schema and layout editors updating the same repository?

I decided to stick with eagle for now. Will sample kicad again next year.

[jsquaredz]

I tried kicad a few months ago, looking for an eagle alternative.  My main qualm was the need to go through a schema export to start the layout. Why can't it has a single repository for the design and having both the schema and layout editors updating the same repository?

I decided to stick with eagle for now. Will sample kicad again next year.

I think that change was just committed yesterday or today. You will see it in the next stable release next month unless you want to check out the development branch today.

[Palmitoxico]

I'm getting segmentation faults with the last revision of kicad (BZR 5717) when I try to open an Pcbnew file. Trying to open Pcbnew with no file makes kicad hangs in a loop.

Code: [Select]

traps: kicad[24070] general protection ip:7fd777d9f558 sp:7fffc80652b0 error:0 in libgobject-2.0.so.0.4400.1[7fd777d7e000+51000]

I'm running Debian experimental on a x86_64 machine.

[c4757p]

Any chance you can get a backtrace? Feel free to submit to the bug tracker.

[Palmitoxico]

Any chance you can get a backtrace? Feel free to submit to the bug tracker.

I'll do some futher investigation before report this bug.

[zapta]

I think that change was just committed yesterday or today. You will see it in the next stable release next month unless you want to check out the development branch today.

Thanks, I will give it a try in a month or two. I would love to switch to kicad and it seems to move fast these days.

[firewalker]

Did we mention proper clipboard (copy-paste) functionality?

Alexander.

[jsquaredz]

Did we mention proper clipboard (copy-paste) functionality?

Alexander.

Can you expand on this?  What are some scenarios you are looking to be able to do?

[Bassman59]

I tried kicad a few months ago, looking for an eagle alternative.  My main qualm was the need to go through a schema export to start the layout.

A schematic is the "source code" for a PCB design. Why you'd want to start laying out a board without a schematic is sort of crazy for anything other than the absolute most trivial design.

Why can't it has a single repository for the design and having both the schema and layout editors updating the same repository?

Because one schematic can be used to make different layouts.

[zapta]

A schematic is the "source code" for a PCB design. Why you'd want to start laying out a board without a schematic is sort of crazy for anything other than the absolute most trivial design.

I was talking about the export step, not about creating a schema.

Why can't it has a single repository for the design and having both the schema and layout editors updating the same repository?

Because one schematic can be used to make different layouts.

A repository can contain more than one layout.  The design flow should be seamless, in both directions.

[Bassman59]

Why can't it has a single repository for the design and having both the schema and layout editors updating the same repository?

Because one schematic can be used to make different layouts.

A repository can contain more than one layout.  The design flow should be seamless, in both directions.

What do you mean by "repository?"

[zapta]

What do you mean by "repository?"

It can be implemented in many ways, for example a data file. The key point is that the user doesn't need to deal with import/export between the various steps of the design. They are all parts of a seamless design process.

[Bassman59]

What do you mean by "repository?"

It can be implemented in many ways, for example a data file. The key point is that the user doesn't need to deal with import/export between the various steps of the design. They are all parts of a seamless design process.

OK, I wasn't clear, because "repository" has a particular meaning in engineering.

What you are asking for is that the software doesn't build a netlist from a schematic which gets imported into the PCB layout program. (Altium does that, it's called "compile.")

Now I understand what you are asking.

I think the "right thing" to have would be a schematic option called "Update PCB from schematic" and it automagically updates the layout based on preset rules.  But I think you don't want that update to be automatic upon each schematic save, because what if you change your mind and need to undo something? Then you have to undo the layout, and that could get messy.

So what I mean is: is the two-step export-netlist/import-netlist mechanism in Kicad really that awful? That said, I think it's on the roadmap to make it the one-step process after the upcoming stable is released.

[firewalker]

Did we mention proper clipboard (copy-paste) functionality?

Alexander.

Can you expand on this?  What are some scenarios you are looking to be able to do?

https://answers.launchpad.net/kicad/+question/162993

[zapta]

But I think you don't want that update to be automatic upon each schematic save, because what if you change your mind and need to undo something? Then you have to undo the layout, and that could get messy.

This is actually what eagle is doing and it works perfectly for me.  Between the undo button and the version control system I have anything I need to recover from mistakes.

[madworm]

Definitely a wishlist item: inverted text on copper layers.

[krivx]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

I actually just submitted a patch that fixes some of that, hopefully it's committed soon.

Any comments on the process? I have been meaning to look at a couple of issues myself, how hard was it to read through the codebase? What was the submission process like?

[firewalker]

Selecting mask color for the 3D viewer. There is already a patch available.

[c4757p]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

I actually just submitted a patch that fixes some of that, hopefully it's committed soon.

Any comments on the process? I have been meaning to look at a couple of issues myself, how hard was it to read through the codebase? What was the submission process like?

Patch committed.

Well, I've been working on KiCad for a couple months now, so I've worked my way into the codebase gradually, but it's not too bad. Could use better organization - you'll want ctags or similar. There are definitely sections of it, depending on age, that are written differently - I'm most experienced with Eeschema, I've been trying to give it some attention since it doesn't get very much.

As for submission - if it's a bugfix, and you've done the fix well, just attach the patch to the bug in the tracker. As usual I'd recommend you start simple before dumping out a thousand line patch and expecting people to take the time to look it over, and before you do anything with substantial changes or add features, ask the devs on the mailing list. This patch came with an added feature, so I probed the mailing list for opinions first. They're generally open to suggestions.

[c4757p]

Selecting mask color for the 3D viewer. There is already a patch available.

Go voice your support for the patch in the tracker. Be aware, however, that there is an official pre-release feature freeze in effect now - features can be added, but they need higher approval than usual and have to be simple.

[krivx]

Schematic and pcb editor without screen leftovers when moving parts.

Alexander.

I actually just submitted a patch that fixes some of that, hopefully it's committed soon.

Any comments on the process? I have been meaning to look at a couple of issues myself, how hard was it to read through the codebase? What was the submission process like?

Patch committed.

Well, I've been working on KiCad for a couple months now, so I've worked my way into the codebase gradually, but it's not too bad. Could use better organization - you'll want ctags or similar. There are definitely sections of it, depending on age, that are written differently - I'm most experienced with Eeschema, I've been trying to give it some attention since it doesn't get very much.

As for submission - if it's a bugfix, and you've done the fix well, just attach the patch to the bug in the tracker. As usual I'd recommend you start simple before dumping out a thousand line patch and expecting people to take the time to look it over, and before you do anything with substantial changes or add features, ask the devs on the mailing list. This patch came with an added feature, so I probed the mailing list for opinions first. They're generally open to suggestions.

Thanks. I have ctags with vim for navigation. Never used bzr, I had thought that most projects were abandoning it. I'll take a look at the mailing lists.

[c4757p]

Most projects are abandoning it, because it fucking sucks. KiCad will in time, but not until after the next release. For now I don't use it, I use git-remote-bzr.

[jsquaredz]

Definitely a wishlist item: inverted text on copper layers.

Inverted not mirrored.  So in other words rotated text?

[madworm]

Inverted as in 'photographic negative' (etched text). Currently the copper pour is removed & normal text is added.

[jsquaredz]

Inverted as in 'photographic negative' (etched text).

gotcha.  Thanks.

[ElektroQuark]

Quote from: madworm on Today at 14:15:04

Inverted as in 'photographic negative' (etched text). Currently the copper pour is removed & normal text is added.

You can do it putting the text in the cooper layer before doing the pour. Or am I missing something?

[madworm]

See the image I posted. It destroys part of the copper pour (positive text in empty box).

[jsquaredz]

See the image I posted. It destroys part of the copper pour (positive text in empty box).

So you want the text etched away completely...

[madworm]

Yup, leave the copper pour alone & etch the text away.

[jsquaredz]

Yup, leave the copper pour alone & etch the text away.

And what to do if there is no copper pour?

[madworm]

Well, normal text of course.

I think this could be an optional thing, per text object via a check-box.

[c4757p]

jsquaredz, if you're going to keep funneling "gripes" into the tracker, can you help us out a bit by tagging them properly?

Preferred example tags:
pcbnew
cern gal - for things related to the GAL/OpenGL canvas in particular
eeschema
libedit - component library editor
modedit - footprint editor
packaging-windows - for things related to the Windows installer
osx

Also, set Importance to Wishlist for feature requests.

Keep in mind, anyone desiring features who has coding experience is welcome to implement them. Just ask first to make sure it'll be accepted.

[AdShea]

Here's a few:

1. Inconsistent hotkeys for block mode in eeschema (Tab v. G for drag, no hotkey for delete block, etc.)
2. No hotkey for paste saved block.
3. No way to add/remove items from a block selection.

[timofonic]

Here's my rant:
- The library manager is a total mess, even worse than Eagle but not worse than DipTrace (nice software, but that shitty library manager makes it useless). Where's advanced taxonomy and tagging like when finding something in Octopart? That's the way to go, and "favorites" and "recent" tags too.

- I find the interface too frustrating to use, I was able to replicate a simple 741 exercise from class in "just" a few hours. It was difficult to move objects and place lines, the lack of back annotation made my n00b mistakes even more frustrating than it already is and made me insa e
- The software forces me to create a project to d something, this is crazy. Their replies are about change your workflow.
- Footprints and parta dont get embedded in the schematic and board files, this makes portability very difficult.
- Lack of interoperability makes things difficult.


They need to go the LibreOffice way:
- Get funds to make a foundation, electronic small/medium companies and education institutions could invest on it. While that would  happens, some nice nerdy devs would provide improvements for more marginal stuff but no less interesting for certain people. You can try crowdfunding, a call for help in EDA sites and such.
- Do a massive code refactorization and analyze the code, just like LibreOffice and many projects did. This can improve development in many ways. I did read from many devs that there's lots of crappy code, specially the legacy one.

- Please develop one ISO standard format for all kind of electronics software. Even for stuff like Sigrok, circuits simulators and such. This needs one consortium and small EDA software companies could be part of it, "just" avoid any kind of negative attitude

[c4757p]

- I find the interface too frustrating to use, I was able to replicate a simple 741 exercise from class in "just" a few hours. It was difficult to move objects and place lines, the lack of back annotation made my n00b mistakes even more frustrating than it already is and made me insa e

Back-annotation is planned. "Frustrating" is not a valid complaint.

- The software forces me to create a project to d something, this is crazy. Their replies are about change your workflow.

So? Create a project and stop whinging. (And you don't have to create one anyway, try again.)

- Footprints and parta dont get embedded in the schematic and board files, this makes portability very difficult.

They don't get embedded in schematic files only. They are saved to a separate library cache file, which you just need to include with your project. I recently added some code to make kicad prefer the symbols in this cache file when there are conflicts.

Footprints have always been embedded. You can modify each instance individually and all that.

- Lack of interoperability makes things difficult.

Interoperability in what sense?

- Do a massive code refactorization and analyze the code, just like LibreOffice and many projects did. This can improve development in many ways. I did read from many devs that there's lots of crappy code, specially the legacy one.

You know what "legacy" means, right? We are doing that.

- Please develop one ISO standard format for all kind of electronics software. Even for stuff like Sigrok, circuits simulators and such. This needs one consortium and small EDA software companies could be part of it, "just" avoid any kind of negative attitude

Yes, it worked so well for LibreOffice. Have you tried opening LO files in other software? Usually they get fucked up badly.

[c4757p]

Here's a few:

1. Inconsistent hotkeys for block mode in eeschema (Tab v. G for drag, no hotkey for delete block, etc.)
2. No hotkey for paste saved block.

Good ideas. The hotkeys definitely need some work.

3. No way to add/remove items from a block selection.

Planned. Eeschema will eventually work the same way pcbnew does, and in pcbnew with the new canvas you can do this easily.

[donotdespisethesnake]

- I find the interface too frustrating to use, I was able to replicate a simple 741 exercise from class in "just" a few hours. It was difficult to move objects and place lines, the lack of back annotation made my n00b mistakes even more frustrating than it already is and made me insa e

Back-annotation is planned. "Frustrating" is not a valid complaint.

So already we have gone from "list your gripes" to "your observations are not valid". This is my meta-gripe : the Kicad devs are not really interested in working out how or why the UX is frustrating for many typical users (the UX always was and still is quite crap), and how to improve it.

Instead, the devs have this "if you don't like it, you're wrong, buzz off" attitude which puts off many users, and will never lead to Kicad improving.

[c4757p]

I'm hardly a dev, I'm a guy who contributes some patches in his spare time. Something I chose to do rather than just complaining about the free software I'm getting. Trust me, we know what's wrong with the UI, and we have limited manpower to fix it. We're working on it FFS, be patient.

And yes, if you can't be bothered to explain what you find frustrating, by all means buzz off. Developers aren't Miss Cleo, you need to tell them what you want.

[firewalker]

The patch for color selection.

https://bugs.launchpad.net/kicad/+bug/1437724

Alexander.

[c4757p]

The patch for color selection.

https://bugs.launchpad.net/kicad/+bug/1437724

Alexander.

Yup. I've got it marked for myself so I remember it, as I like that too - it's not going to go in before release, because of the feature freeze (sadly we're not using version control as efficiently as we ought to, or it could just be merged into a different branch...), but after release I'll poke someone about it if it's not reviewed for merging.

[firewalker]

Doesn't bother me that much. I will recompile it with this option added. As I do now.

Alexander.

[timofonic]

- I find the interface too frustrating to use, I was able to replicate a simple 741 exercise from class in "just" a few hours. It was difficult to move objects and place lines, the lack of back annotation made my n00b mistakes even more frustrating than it already is and made me insa e

Back-annotation is planned. "Frustrating" is not a valid complaint.

So already we have gone from "list your gripes" to "your observations are not valid". This is my meta-gripe : the Kicad devs are not really interested in working out how or why the UX is frustrating for many typical users (the UX always was and still is quite crap), and how to improve it.

Instead, the devs have this "if you don't like it, you're wrong, buzz off" attitude which puts off many users, and will never lead to Kicad improving.

Well, he's not part of the core team. It's okay, but it sounded a bit dry in my opinion.

Yes, I agree about that's not the best attitude. I understand these days the project is mostly guided by volunteers and such, but I would like to provide my feedback. I didn't explain well enough, I don't have enough time to do a more detailed description of my issues with the user interface, but it totally drives me crazy even more than Eagle (it has lots of quirks too, but the command line is a good idea I would like to see in other software).

KiCad UX is very frustrating, I would love someone with real knowledge+experience on it and in EDA could make a depth analysis and suggesting ways to improve it (is it done by the Spanish company or was just an initial analysis?). From the many EDA software packages I tried, KiCad is one of the weirdest to use (well, gEDA is hellish weird too).

There's a common saying about Open Source generally having very bad UX, but are good at scripting and such. It seems it's more true than I used to think.

Are there a possibility that this might happen someday? Seriously, usability is very important for a software like this and very essential to novices too. The learning curve can make people go away.

And if saying you prefer devs instead dumb users, that's elitism that makes the software die. Some of these dumb users could become developers or future developers, and maybe their employers or someone in the company/institution might be interested in contribute.

[ijsf]

I agree with the KiCad UX problems and frustation here. I've had a week long session with KiCad attempting to build a fairly complex board with BGA fanouts, gigabit differential pairs, and I've seen my sympathy of the software drop like a stone in the process.

The software seemed like a very good alternative until the board reached a certain complexity, after which it became extremely cumbersome to use. At a certain point, I didn't feel confident at all I could even produce a board without DRC errors, mostly due to the following bugs:

* Default vias have invalid drill holes. Pretty crucial if your via drills are missing. Really? - https://bugs.launchpad.net/kicad/+bug/1453627
* Many bugs related to zone filling, some even causing short circuits.
* Many OS X bugs related to redrawing and UI just disappearing altogether.

Apart from that I tried to report everything I encountered as an effort to help out the project. The overall reaction, from the development team and KiCad founders, appears to be:

* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331
* "don't open up so many bug reports" and "RTFM" - https://bugs.launchpad.net/kicad/+bug/1464331/comments/11
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292
* "a system without a middle mouse button doesn't seem suited for CAD anyway.." - comment later deleted by author https://bugs.launchpad.net/kicad/+bug/1464245

I am sorry to say that I believe this is just terrible project management and behaviour, even for open-source software. Having been part of a large open-source core development team myself in the past, with a bug tracker that was a lot larger even, I understand the frustration of reports, but this level just astonishes me. But it does fully explain the state that KiCad is in.

[timofonic]

I agree with the KiCad UX problems and frustation here. I've had a week long session with KiCad attempting to build a fairly complex board with BGA fanouts, gigabit differential pairs, and I've seen my sympathy of the software drop like a stone in the process.

The software seemed like a very good alternative until the board reached a certain complexity, after which it became extremely cumbersome to use. At a certain point, I didn't feel confident at all I could even produce a board without DRC errors, mostly due to the following bugs:

* Default vias have invalid drill holes. Pretty crucial if your via drills are missing. Really? - https://bugs.launchpad.net/kicad/+bug/1453627
* Many bugs related to zone filling, some even causing short circuits.
* Many OS X bugs related to redrawing and UI just disappearing altogether.

Apart from that I tried to report everything I encountered as an effort to help out the project. The overall reaction, from the development team and KiCad founders, appears to be:

* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331
* "don't open up so many bug reports" and "RTFM" - https://bugs.launchpad.net/kicad/+bug/1464331/comments/11
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292
* "a system without a middle mouse button doesn't seem suited for CAD anyway.." - comment later deleted by author https://bugs.launchpad.net/kicad/+bug/1464245

I am sorry to say that I believe this is just terrible project management and behaviour, even for open-source software. Having been part of a large open-source core development team myself in the past, with a bug tracker that was a lot larger even, I understand the frustration of reports, but this level just astonishes me. But it does fully explain the state that KiCad is in.

It's a shame, it reminds me of Sun/Oracle OpenOffice issues.

I hope the project management gets solved and arrogance vanishes someday from the project. If not, I fear a fork or an alternative FOSS EDA might happen eventually :/

Are you brave enough to post about this on kicad-users? You are skilled enough, both as doing complex designs and as a developer.

Does KiCad suffer from zealotizm like other FOSS projects?

[jsquaredz]

I agree with the KiCad UX problems and frustation here. I've had a week long session with KiCad attempting to build a fairly complex board with BGA fanouts, gigabit differential pairs, and I've seen my sympathy of the software drop like a stone in the process.

The software seemed like a very good alternative until the board reached a certain complexity, after which it became extremely cumbersome to use. At a certain point, I didn't feel confident at all I could even produce a board without DRC errors, mostly due to the following bugs:

* Default vias have invalid drill holes. Pretty crucial if your via drills are missing. Really? - https://bugs.launchpad.net/kicad/+bug/1453627
* Many bugs related to zone filling, some even causing short circuits.
* Many OS X bugs related to redrawing and UI just disappearing altogether.

Apart from that I tried to report everything I encountered as an effort to help out the project. The overall reaction, from the development team and KiCad founders, appears to be:

* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331
* "don't open up so many bug reports" and "RTFM" - https://bugs.launchpad.net/kicad/+bug/1464331/comments/11
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292
* "a system without a middle mouse button doesn't seem suited for CAD anyway.." - comment later deleted by author https://bugs.launchpad.net/kicad/+bug/1464245

I am sorry to say that I believe this is just terrible project management and behaviour, even for open-source software. Having been part of a large open-source core development team myself in the past, with a bug tracker that was a lot larger even, I understand the frustration of reports, but this level just astonishes me. But it does fully explain the state that KiCad is in.

It's a shame, it reminds me of Sun/Oracle OpenOffice issues.

I hope the project management gets solved and arrogance vanishes someday from the project. If not, I fear a fork or an alternative FOSS EDA might happen eventually :/

Are you brave enough to post about this on kicad-users? You are skilled enough, both as doing complex designs and as a developer.

Does KiCad suffer from zealotizm like other FOSS projects?

While I think there may be an element of that arrogance, I don't think it is in their Leadership anymore.  Since Wayne took over as project lead this project has started moving in the right direction.  There are still some of their contributers that treat users who put in bug reports with disdain, but I don't think its prevalent.  For the most part I have received good feedback from their contributors, and I have filed 9 bug reports in the last week or two.  Some of those reports have already been committed as fixes in the current release, so I think they are doing pretty good. 

If I had one criticism, is that there isn't great communication from them to the masses.  When Wayne presented at FOSDEM 2015, someone asked him if there was a twitter feed for the project, and he just said he was to busy to twitter.  I think this is a mistake, as twitter would be a great place to broadcast the progress they are making.  If its not wayne that does it, someone should.  I suggest that they should do a weekly tweet that points to a blog post that records the weekly progress (digest style) in the development branch.  Also it would be great to see the list of things on their plate before they pull the trigger on a stable release.  I have heard July is the month of the stable release, but users have no insight into what still remains to be completed to get there.

[timofonic]

I agree with the KiCad UX problems and frustation here. I've had a week long session with KiCad attempting to build a fairly complex board with BGA fanouts, gigabit differential pairs, and I've seen my sympathy of the software drop like a stone in the process.

The software seemed like a very good alternative until the board reached a certain complexity, after which it became extremely cumbersome to use. At a certain point, I didn't feel confident at all I could even produce a board without DRC errors, mostly due to the following bugs:

* Default vias have invalid drill holes. Pretty crucial if your via drills are missing. Really? - https://bugs.launchpad.net/kicad/+bug/1453627
* Many bugs related to zone filling, some even causing short circuits.
* Many OS X bugs related to redrawing and UI just disappearing altogether.

Apart from that I tried to report everything I encountered as an effort to help out the project. The overall reaction, from the development team and KiCad founders, appears to be:

* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331
* "don't open up so many bug reports" and "RTFM" - https://bugs.launchpad.net/kicad/+bug/1464331/comments/11
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292
* "a system without a middle mouse button doesn't seem suited for CAD anyway.." - comment later deleted by author https://bugs.launchpad.net/kicad/+bug/1464245

I am sorry to say that I believe this is just terrible project management and behaviour, even for open-source software. Having been part of a large open-source core development team myself in the past, with a bug tracker that was a lot larger even, I understand the frustration of reports, but this level just astonishes me. But it does fully explain the state that KiCad is in.

It's a shame, it reminds me of Sun/Oracle OpenOffice issues.

I hope the project management gets solved and arrogance vanishes someday from the project. If not, I fear a fork or an alternative FOSS EDA might happen eventually :/

Are you brave enough to post about this on kicad-users? You are skilled enough, both as doing complex designs and as a developer.

Does KiCad suffer from zealotizm like other FOSS projects?

While I think there may be an element of that arrogance, I don't think it is in their Leadership anymore.  Since Wayne took over as project lead this project has started moving in the right direction.  There are still some of their contributers that treat users who put in bug reports with disdain, but I don't think its prevalent.  For the most part I have received good feedback from their contributors, and I have filed 9 bug reports in the last week or two.  Some of those reports have already been committed as fixes in the current release, so I think they are doing pretty good. 

If I had one criticism, is that there isn't great communication from them to the masses.  When Wayne presented at FOSDEM 2015, someone asked him if there was a twitter feed for the project, and he just said he was to busy to twitter.  I think this is a mistake, as twitter would be a great place to broadcast the progress they are making.  If its not wayne that does it, someone should.  I suggest that they should do a weekly tweet that points to a blog post that records the weekly progress (digest style) in the development branch.  Also it would be great to see the list of things on their plate before they pull the trigger on a stable release.  I have heard July is the month of the stable release, but users have no insight into what still remains to be completed to get there.

Blog post? They even don't have a news section on their site, their website urgently needs a massive redesign. They are open to contributors to improve it, as some of their developers said.

[nickoe]

If I had one criticism, is that there isn't great communication from them to the masses.  When Wayne presented at FOSDEM 2015, someone asked him if there was a twitter feed for the project, and he just said he was to busy to twitter.  I think this is a mistake, as twitter would be a great place to broadcast the progress they are making.  If its not wayne that does it, someone should.  I suggest that they should do a weekly tweet that points to a blog post that records the weekly progress (digest style) in the development branch.  Also it would be great to see the list of things on their plate before they pull the trigger on a stable release.  I have heard July is the month of the stable release, but users have no insight into what still remains to be completed to get there.

Well, I am not too much into the twitter channel, but it could be a good idea to share newsflashes. But there already is something, but I dont't really know who made it, and seems inactive. I guess it is Ajo, but not really sure about that -- just a guess. See https://twitter.com/kicad_pcb.

Also you might want to vist http://www.kicad-pcb.org/display/DEV/KiCad+Development  to have a look about some of the major things that is happening and has happened.

I agree with the KiCad UX problems and frustation here. I've had a week long session with KiCad attempting to build a fairly complex board with BGA fanouts, gigabit differential pairs, and I've seen my sympathy of the software drop like a stone in the process.

The software seemed like a very good alternative until the board reached a certain complexity, after which it became extremely cumbersome to use. At a certain point, I didn't feel confident at all I could even produce a board without DRC errors, mostly due to the following bugs:

* Default vias have invalid drill holes. Pretty crucial if your via drills are missing. Really? - https://bugs.launchpad.net/kicad/+bug/1453627
* Many bugs related to zone filling, some even causing short circuits.
* Many OS X bugs related to redrawing and UI just disappearing altogether.

You did not state your version of KiCad is this thread, but FYI Jean-Pierre comitted a fix that is likely fixing your second point there. See http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5679.

Do you have a description of the OS X issues there? There are drawing artifacts in the legacy renders, there has been for ages and is being addressed with the introduction of GAL.   But the UI dissapering, I don't know what this issue is.

Apart from that I tried to report everything I encountered as an effort to help out the project. The overall reaction, from the development team and KiCad founders, appears to be:

* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331
* "don't open up so many bug reports" and "RTFM" - https://bugs.launchpad.net/kicad/+bug/1464331/comments/11
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292
* "a system without a middle mouse button doesn't seem suited for CAD anyway.." - comment later deleted by author https://bugs.launchpad.net/kicad/+bug/1464245

Well, thank you for reporting, and rember that reproducing, debugging and fixing issues is an art where good communication is needed. Please don't think everyone is attacking you and then become defensive, co-operate.

And regarding your third point here: The thing is that he did actually not know what a microvia was.

I am sorry to say that I believe this is just terrible project management and behaviour, even for open-source software. Having been part of a large open-source core development team myself in the past, with a bug tracker that was a lot larger even, I understand the frustration of reports, but this level just astonishes me. But it does fully explain the state that KiCad is in.

What large open-source core development team?

Here's my rant:
- The library manager is a total mess, even worse than Eagle but not worse than DipTrace (nice software, but that shitty library manager makes it useless). Where's advanced taxonomy and tagging like when finding something in Octopart? That's the way to go, and "favorites" and "recent" tags too.

You can add keywords to parts...

- I find the interface too frustrating to use, I was able to replicate a simple 741 exercise from class in "just" a few hours. It was difficult to move objects and place lines, the lack of back annotation made my n00b mistakes even more frustrating than it already is and made me insa e

I guess that is a subjective matter. I find it quite easy, but that is most likely because I am used to it. And do you rember this GAL thing comming?

- The software forces me to create a project to d something, this is crazy. Their replies are about change your workflow.

This is simply not true, you can start the applications seperately. And a citation is needed for that statement about the workflow.

- Footprints and parta dont get embedded in the schematic and board files, this makes portability very difficult.

This is again an invalid statement, unfortunately. Footprints _do_ get embedded in the board files.  But correct, the schematic symbols do not get embedded in the schematics yet. For portability, you should either include the libs you use "locally" in the project, or rember to geek the *-cache.lib file, which keeps the schematic symbols used.

- Lack of interoperability makes things difficult.

Haha! "Lack of interoperabiilty", you are quite a comedian.

- Do a massive code refactorization and analyze the code, just like LibreOffice and many projects did. This can improve development in many ways. I did read from many devs that there's lots of crappy code, specially the legacy one.

You don't sound like a developer, so why would you know anything about this? Also, major cleanup is being performed, but the code base is large and resources are limited, so it takes time. And why does the crappiness of legacy code matter? If it is legacy it is to be replaced, no need to spend too much time on that. What is important is to make sure that new commits has good code quality.

- Please develop one ISO standard format for all kind of electronics software. Even for stuff like Sigrok, circuits simulators and such. This needs one consortium and small EDA software companies could be part of it, "just" avoid any kind of negative attitude

Read https://xkcd.com/927/, and then just let the KiCad format be the standard. There is no need for the waste of resources a consortium is.

[ijsf]

Do you have a description of the OS X issues there? There are drawing artifacts in the legacy renders, there has been for ages and is being addressed with the introduction of GAL.   But the UI dissapering, I don't know what this issue is.

Simply too many to mention, largely involving the actual window UI and not the renderer itself which could probably be fixed properly if somebody actually did a test & fix session instead of going through the hassle of bug reports. I saw that the OS X builds are still marked "experimental", so I'll just naively assume somebody is working on this.

Well, thank you for reporting, and rember that reproducing, debugging and fixing issues is an art where good communication is needed. Please don't think everyone is attacking you and then become defensive, co-operate.

I believe the receiving party here should stick to a professional and respectful attitude at all times, which I believe is not happening here and is dragging the project down.

Coming from a professional CAD suite, this was basically me trying to emerse myself into KiCad to see if I could gradually switch over. Now, the bugs aren't the issue here and I do appreciate the speed at which some bugs seem to be fixed. In my brief but complex session I felt I had to contribute back by submitting these reports, but the overall resulting interaction with the project's developing team resulted in my decision to back far away from KiCad, at least for a long time.

What large open-source core development team?

https://en.wikipedia.org/wiki/Multi_Theft_Auto

We've seen a considerable amount of users and bug reports in our project lifetime, and community feedback has always been seen as crucial and constructive instead of unnecessary and annoying.

[Bassman59]

Do you have a description of the OS X issues there? There are drawing artifacts in the legacy renders, there has been for ages and is being addressed with the introduction of GAL.   But the UI dissapering, I don't know what this issue is.

Simply too many to mention, largely involving the actual window UI and not the renderer itself which could probably be fixed properly if somebody actually did a test & fix session instead of going through the hassle of bug reports. I saw that the OS X builds are still marked "experimental", so I'll just naively assume somebody is working on this.

What version of Kicad are you using? I have not seen any rendering issues on OS X in quite some time. As for "OS X builds still marked experimental," unfortunately the web site is updated as often as it should be.

Download nightly builds from here: http://downloads.kicad-pcb.org/osx/

[jsquaredz]

jsquaredz, if you're going to keep funneling "gripes" into the tracker, can you help us out a bit by tagging them properly?

Preferred example tags:
pcbnew
cern gal - for things related to the GAL/OpenGL canvas in particular
eeschema
libedit - component library editor
modedit - footprint editor
packaging-windows - for things related to the Windows installer
osx

Also, set Importance to Wishlist for feature requests.

Keep in mind, anyone desiring features who has coding experience is welcome to implement them. Just ask first to make sure it'll be accepted.

Will do.  Sorry if I have submitted some after you wrote this not following this.  Just seeing this now. I'm not a coder, but I see a lot of people have issues but dont report them in bug tracker, so for the good of KiCAD I thought it was a good idea to do this... 

[jsquaredz]

32   Windows Version: When creating a new project the file kicad-dir/share/template/kicad.pro is copied to kicad-dir/noname.pro, this causes an error in windows since file writing is not normally allowed in "Program Files" (install to other folder works fine). Also, this causes all you files to be named to noname

Looks like this is currently being worked on.  Pretty cool guys.  Your feedback is having a direct impact on the quality of the software...

[c4757p]

Will do.  Sorry if I have submitted some after you wrote this not following this.  Just seeing this now. I'm not a coder, but I see a lot of people have issues but dont report them in bug tracker, so for the good of KiCAD I thought it was a good idea to do this...

Yep, I don't have a problem with it, feedback is good! It's just that you've submitted a significant number of reports recently, so it's a lot easier on us if they are pre-sorted.

[Palmitoxico]

Any chance you can get a backtrace? Feel free to submit to the bug tracker.

I'll do some futher investigation before report this bug.

I've discovered that it was a problem with libgobject-2.0 on debian testing (I've compiled kicad on my server running debian 8 stable and tried to run on a debian testing).

Kicad is getting better and better very fast!

[firewalker]

Kicad "teardrops".

http://blog.elphel.com/2015/04/trying-out-kicad/

[jsquaredz]

Kicad "teardrops".

http://blog.elphel.com/2015/04/trying-out-kicad/

This is awesome. Great work. Is there a current issue in launcher?

[mark03]

I understand there is a lot of work going on "under the hood" which makes some features easier to implement than others, but from a user perspective it is hard to get one's head around the seeming mis-prioritization of the development work that CERN is doing.  For instance, we now have length-matched traces.  That's awesome, and no doubt essential in a professional tool, but given the fundamental usability issues it seems like misdirected effort to me.  My personal gripe list:

1) Vias are still not treated as "first class" objects and there is no roadmap for when this will happen.  It is not clear that the devs agree with the proposition, which is extremely worrying to me.  By "first class object" I mean that vias must be seen as independent objects you will sprinkle around the board, not related to traces in any way.  gEDA, for all its problems, got that right.  The approach taken by KiCAD currently is that vias are, first and foremost, a means to hop a trace from one layer to another, when in reality this is the worst usage of vias in good PCB layout.  (Admittedly all PCB layouts will need to do this, but we try to minimize it.)  Workarounds using fake traces are tiring, and if you don't do it right, KiCAD deletes the trace and its vias forcing you to start over.  This is probably my #1 efficiency killer with KiCAD right now.

2) Filled zones are just weird.  First there is the issue where you cannot have zones inside of other zones, unless you manually tweak a "priority" number in the zone properties.  First of all, why??  And second, who is going to associate the word "priority" without being told that's what it means?  Zone filling and display is also inconsistent, and it's weird that you have to run DRC to see the zone.  Finally, editing the shape of an existing zone on a crowded board is extremely difficult, because there are not well defined and marked control points.  (Lack of clear control points is a deeper problem affecting other objects too, like traces.)  I usually give up and just delete the zone, then create a new one.

3) The abysmal library interface is frequently mentioned, and for good reason.  I don't mean to sound insulting, but there are aspects of the "select a part to edit, edit part, save library" workflow which are so hilariously bad, I honestly cannot fathom how they came to be.  My favorite is when saving, you have to click through three (or is it four?) dialogs to say Yes, I want to save this part, yes I want to save the library, yes, I really mean it, yes, d??? it, yes!!  But whole thing desperately needs a redesign.  The only saving grace is that you can create footprints by hand in a text editor.  Thank god.

4) Standard parts library is just as bad as gEDA.  Completely non-orthogonal, and, 90% of it is bizarre ancient parts no one is likely to use anymore.  This is a huge challenge and I don't have a good answer, but at a minimum it would be nice to have a gatekeeper.  What is already there would become substantially more usable if you just deleted the least-used half of it.  Beyond that, some sort of integration with an online parts database seems like the way forward.  I don't think the github scheme is doing it

5) This is petty, but some of the terminology in the program needs sanitizing so a typical EE will understand it.  Do they still call footprints "modules" for example?

I am sad to say that my [very limited] experience with the devs on the bug tracker has been similar to that reported above.  I am not sure if they are practicing EEs, based on some of their responses.  When you attempt to explain how the software will actually be used in practice, they can get defensive.  When I asked for help with zones inside of zones, the first response was "Why would you want to do that?"   although to their credit they did go on to explain the priority thing.

[nickoe]

I understand there is a lot of work going on "under the hood" which makes some features easier to implement than others, but from a user perspective it is hard to get one's head around the seeming mis-prioritization of the development work that CERN is doing.  For instance, we now have length-matched traces.  That's awesome, and no doubt essential in a professional tool, but given the fundamental usability issues it seems like misdirected effort to me.  My personal gripe list:

1) Vias are still not treated as "first class" objects and there is no roadmap for when this will happen.  It is not clear that the devs agree with the proposition, which is extremely worrying to me.  By "first class object" I mean that vias must be seen as independent objects you will sprinkle around the board, not related to traces in any way.  gEDA, for all its problems, got that right.  The approach taken by KiCAD currently is that vias are, first and foremost, a means to hop a trace from one layer to another, when in reality this is the worst usage of vias in good PCB layout.  (Admittedly all PCB layouts will need to do this, but we try to minimize it.)  Workarounds using fake traces are tiring, and if you don't do it right, KiCAD deletes the trace and its vias forcing you to start over.  This is probably my #1 efficiency killer with KiCAD right now.

2) Filled zones are just weird.  First there is the issue where you cannot have zones inside of other zones, unless you manually tweak a "priority" number in the zone properties.  First of all, why??  And second, who is going to associate the word "priority" without being told that's what it means?  Zone filling and display is also inconsistent, and it's weird that you have to run DRC to see the zone.  Finally, editing the shape of an existing zone on a crowded board is extremely difficult, because there are not well defined and marked control points.  (Lack of clear control points is a deeper problem affecting other objects too, like traces.)  I usually give up and just delete the zone, then create a new one.

You need to have some mechanism that says something about how the zones should fill over each other. Think, McFly! Think.

Imaging you have two squares where they overlap by a a half edge on two edges or whatever actually.  Theese two zones must not connect.  How would you fill them?

3) The abysmal library interface is frequently mentioned, and for good reason.  I don't mean to sound insulting, but there are aspects of the "select a part to edit, edit part, save library" workflow which are so hilariously bad, I honestly cannot fathom how they came to be.  My favorite is when saving, you have to click through three (or is it four?) dialogs to say Yes, I want to save this part, yes I want to save the library, yes, I really mean it, yes, d??? it, yes!!  But whole thing desperately needs a redesign.  The only saving grace is that you can create footprints by hand in a text editor.  Thank god.

Good to hear that you have some favorite things in KiCad.

4) Standard parts library is just as bad as gEDA.  Completely non-orthogonal, and, 90% of it is bizarre ancient parts no one is likely to use anymore.  This is a huge challenge and I don't have a good answer, but at a minimum it would be nice to have a gatekeeper.  What is already there would become substantially more usable if you just deleted the least-used half of it.  Beyond that, some sort of integration with an online parts database seems like the way forward.  I don't think the github scheme is doing it

Libraries are _NEVER_ perfect.

5) This is petty, but some of the terminology in the program needs sanitizing so a typical EE will understand it.  Do they still call footprints "modules" for example?

You clearly are not using a recent version of KiCad. That has been renamed, mmmm, for ... is that quite possibly -- half a year ago?

I am sad to say that my [very limited] experience with the devs on the bug tracker has been similar to that reported above.  I am not sure if they are practicing EEs, based on some of their responses.  When you attempt to explain how the software will actually be used in practice, they can get defensive.  When I asked for help with zones inside of zones, the first response was "Why would you want to do that?"   although to their credit they did go on to explain the priority thing.

IIRC you were not good at describing your issue. Please spend more time on your bug reports.

[mark03]

2) Filled zones are just weird.  First there is the issue where you cannot have zones inside of other zones, unless you manually tweak a "priority" number in the zone properties.  First of all, why??  And second, who is going to associate the word "priority" without being told that's what it means?  Zone filling and display is also inconsistent, and it's weird that you have to run DRC to see the zone.  Finally, editing the shape of an existing zone on a crowded board is extremely difficult, because there are not well defined and marked control points.  (Lack of clear control points is a deeper problem affecting other objects too, like traces.)  I usually give up and just delete the zone, then create a new one.

You need to have some mechanism that says something about how the zones should fill over each other.

The zones have already been assigned to nets at this point.  If one zone fully encloses the other (the most common situation), and the nets are distinct, then the answer is obvious: the smaller zone is like a really big pad surrounded by the enclosing zone.  If the zones only have partial overlap, it's like windows in a desktop GUI: which window gets drawn on top?  to which one obvious answer would be, the last one drawn.

Think, McFly! Think.

I try to put myself in the shoes of the developers, and imagine what it is like getting all these complaints.  But at the same time, honestly, it is attitudes like this which are not helping.

IIRC you were not good at describing your issue. Please spend more time on your bug reports.

You are referring to this report: https://bugs.launchpad.net/kicad/+bug/1418637
Anyone still following along can draw their own conclusions.

[timofonic]

Do future improvements could provide features from this tool?
http://www.compuphase.com/electronics/kicadlibrarian_en.htm

[c4757p]

Think, McFly! Think.

I try to put myself in the shoes of the developers, and imagine what it is like getting all these complaints.  But at the same time, honestly, it is attitudes like this which are not helping.

I get the feeling that was meant to be tongue-in-cheek. BTTF is kind of an in-joke here

[nickoe]

2) Filled zones are just weird.  First there is the issue where you cannot have zones inside of other zones, unless you manually tweak a "priority" number in the zone properties.  First of all, why??  And second, who is going to associate the word "priority" without being told that's what it means?  Zone filling and display is also inconsistent, and it's weird that you have to run DRC to see the zone.  Finally, editing the shape of an existing zone on a crowded board is extremely difficult, because there are not well defined and marked control points.  (Lack of clear control points is a deeper problem affecting other objects too, like traces.)  I usually give up and just delete the zone, then create a new one.

You need to have some mechanism that says something about how the zones should fill over each other.

The zones have already been assigned to nets at this point.  If one zone fully encloses the other (the most common situation), and the nets are distinct, then the answer is obvious: the smaller zone is like a really big pad surrounded by the enclosing zone.  If the zones only have partial overlap, it's like windows in a desktop GUI: which window gets drawn on top?  to which one obvious answer would be, the last one drawn.

This is still problematic, because how can you tell it to do the opposite? FWIW the same functionality is used in Eagle where they just call it rank. What other packages call it, is up to you to investigate and tell me. But no matter how you see this, there has to some form of z-index to address this issue. It would be bad if I had to redraw my hundred nodes polygons just because the drawing order was not as I actually indended it to be in the first place.

[Tandy]

The main annoyance for me is working with a trackpad on a Mac. The default behaviour should really be using 2 fingers to scroll and zoom using the pinch gesture. Apparently there is a patch if you are able to compile it yourself but not an option on a pre-compiled version.

The number of preferences in KiCAD is very limited, I would prefer to see a more comprehensive preferences panel where options like this could be set.

[Red Squirrel]

Version: (from about dialog)
Build 2013-jul-07 stable
wxWidgets 2.8.12 Unicode and boost C++ libraries
64bit GNU/Linux
(OS is Linux Mint 17.1)
------

I keep trying to learn it as I eventually want to make PCBs and it's one of few programs that run in Linux, but I have a few gripes myself:

1: Navigating is just so awkward.  Like any other program you'd be able to right click and drag and scroll to zoom in and out or what not, but it seems you HAVE to use the scroll bars.  It just feels unintuitive

2: Mass operations are hard.  I want to be able to just select a bunch of parts, drag them somewhere else, or delete them etc.   On similar note, if I want to make an array of say, 10 parts by adding one, then pressing control and dragging it to create copies.  Lot of standard stuff like this that lot of other graphic/editing type programs have that kicad does not have.

3: Too many shortcut keys that you have to just know.  Those options should be in menus, and the shortcut keys should be specified within the menu for each option like most programs do like office programs etc.  This is something a lot of open source programs suffer from.  Why do they expect people to learn all these shortcut keys by heart? It should still have menu options and specify the shortcut so you can learn them as you're using the program, without needing to have a cheat sheet on a secondary monitor at all times.

[Bassman59]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

[nickoe]

I keep trying to learn it as I eventually want to make PCBs and it's one of few programs that run in Linux, but I have a few gripes myself:

1: Navigating is just so awkward.  Like any other program you'd be able to right click and drag and scroll to zoom in and out or what not, but it seems you HAVE to use the scroll bars.  It just feels unintuitive

You don't HAVE to ues the scroll bars. You can navigate by zooming out and in, I use that quite a lot. Very easy. Also you can use the shift and ctrl modifiers for the scrollwheel to pan, as you can in almost all applications with such a canvas.

2: Mass operations are hard.  I want to be able to just select a bunch of parts, drag them somewhere else, or delete them etc.   On similar note, if I want to make an array of say, 10 parts by adding one, then pressing control and dragging it to create copies.  Lot of standard stuff like this that lot of other graphic/editing type programs have that kicad does not have.

This is also possible. Use the array tool. (Only in pcbnew and the footprint editor, not ported to eeschema yet)

3: Too many shortcut keys that you have to just know.  Those options should be in menus, and the shortcut keys should be specified within the menu for each option like most programs do like office programs etc.  This is something a lot of open source programs suffer from.  Why do they expect people to learn all these shortcut keys by heart? It should still have menu options and specify the shortcut so you can learn them as you're using the program, without needing to have a cheat sheet on a secondary monitor at all times.

This comment is very useless as is. What hotkeys do you think is not mapped to the menu? Please list them all.

[krivx]

I keep trying to learn it as I eventually want to make PCBs and it's one of few programs that run in Linux, but I have a few gripes myself:

1: Navigating is just so awkward.  Like any other program you'd be able to right click and drag and scroll to zoom in and out or what not, but it seems you HAVE to use the scroll bars.  It just feels unintuitive

You don't HAVE to ues the scroll bars. You can navigate by zooming out and in, I use that quite a lot. Very easy. Also you can use the shift and ctrl modifiers for the scrollwheel to pan, as you can in almost all applications with such a canvas.

The scrolling mechanism is inconsistent between normal and GAL views though.

[madworm]

The scrolling mechanism is inconsistent between normal and GAL views though.

What nonsense!

Panning with middle mouse button works the same for classical view and GAL. Scrolling left/right (ctrl+mouse-whell) works the same, Scrolling up/down (shift+mouse-wheel) works the same.

Either you guys are trolling deliberately, or use terribly outdated versions.

[krivx]

The scrolling mechanism is inconsistent between normal and GAL views though.

What nonsense!

Panning with middle mouse button works the same for classical view and GAL. Scrolling left/right (ctrl+mouse-whell) works the same, Scrolling up/down (shift+mouse-wheel) works the same.

Either you guys are trolling deliberately, or use terribly outdated versions.

I'm using a recent build from here, the About windows says BZR 5754 (http://www2.futureware.at/~nickoe/). I am using a laptop trackpad that has a button for activating a mousewheel. In standard mode dragging with the mousewheel pans. In GAL it does nothing.

[madworm]

Works on my laptop just fine. Of course I don't use windows.

Maybe mouse wheel emulation is broken on your system.

[krivx]

Mouse wheel emulation works in standard view, not in GAL (it also works in all the other software I use). This is clearly an inconsistency between renderers. I have no idea why input handling would be coupled to graphical code but it seems to be the case. Different keyboard shortcuts in different views seems to confirm this e.g. F1/F2 for zooming in standard but ALT+F1/F2 in GAL.

I don't have linux installed on this machine to compare, I may have to try it on a livedisk or VM. I did look into fixing this a couple of weeks ago but the winbuilder project was broken and apparently has been for a couple of months.

[madworm]

This must be a windows thing. Zooming is just F1/F2 for me here, no matter what renderer I choose.

[krivx]

This must be a windows thing. Zooming is just F1/F2 for me here, no matter what renderer I choose.

F1 in GAL is "find footprint".

This is a little annoying, I had assumed that the Windows version was as mature as the Linux one. I hadn't read anything to recommend the Linux version over Windows, though I guess the GAL developers are running Linux as their youtube demos look like it. I'll have to try a VM.

In case you have a copy open, are any of the other GUI bugs isolated to Windows? For example, I can't select the "Delete" tool in GAL, I get a "Not implemented yet" dialog. I can just delete things by using the delete key though.

[madworm]

"Edit, delete"? That works. I use BZR5872.

"delete" from a context menu works too (after having selected a footprint).

[krivx]

"Edit, delete"? That works. I use BZR5872.

"delete" from a context menu works too (after having selected a footprint).

Sorry - I meant the sidebar, where the trashcan icons is. Like on the right side of this image:
 

[c4757p]

krivx - the CERN / GAL developers are indeed using Linux - but Windows is popular among the other devs, so any Windows issues should probably get attention if reported.

[krivx]

krivx - the CERN / GAL developers are indeed using Linux - but Windows is popular among the other devs, so any Windows issues should probably get attention if reported.

I'll throw in some reports so.

[Red Squirrel]

Edited my post.  2013 seems kind of old... is there a newer version?  I wonder if the issues I mentioned actually got fixed.  I recently did an apt-get upgrade though but apt repositories can be far behind sometimes.

[timofonic]

Edited my post.  2013 seems kind of old... is there a newer version?  I wonder if the issues I mentioned actually got fixed.  I recently did an apt-get upgrade though but apt repositories can be far behind sometimes.

There's a PPA...

https://code.launchpad.net/~js-reynaud/+archive/ubuntu/ppa-kicad

[Icchan]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

[nickoe]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

Is this good enough?

DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.

[timofonic]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

Is this good enough?

DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.

Where's that? I can't see it at the top of the site...

[nickoe]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

Is this good enough?

DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.

Where's that? I can't see it at the top of the site...

On the installing page.

[timofonic]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

Is this good enough?

DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.

Where's that? I can't see it at the top of the site...

On the installing page.

Oh. Nice. Why not put it in the home page too?

Another "gripe":

I know I'm not so polite and sometimes a bit asshole, sorry (I'm working on tuning my broken brain)...

But that 2012 date in the site makes people think the project is outdated too.

I know maintaning a website is hard and you are all busy doing the very much needed code polishing, but the site gives the feeling of an outdated project.

Is it easy to put a top frame feeded from the RSS of the code commits with something like "We are busy coding to provide you a new stable release soon"? I think that would make people understand this great project is still active

[Bassman59]

WHEN GRIPING:

Please indicate which version of Kicad you are using.

Some of the complaints here are based on the old so-called "stable" releases, and a lot of them have been addressed in newer revisions.

Thank you.

I would recommend that with greatest of urgency, update the web pages to tell the people going there, that the old stable is "deprecated" or something those lines, and they should use nightly builds if possible.

Is this good enough?

DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.

Where's that? I can't see it at the top of the site...

On the installing page.

Oh. Nice. Why not put it in the home page too?

Another "gripe":

I know I'm not so polite and sometimes a bit asshole, sorry (I'm working on tuning my broken brain)...

But that 2012 date in the site makes people think the project is outdated too.

I know maintaning a website is hard and you are all busy doing the very much needed code polishing, but the site gives the feeling of an outdated project.

Is it easy to put a top frame feeded from the RSS of the code commits with something like "We are busy coding to provide you a new stable release soon"? I think that would make people understand this great project is still active

For the record, the devs know that the website is outdated. Some of the discussion on the dev mail list today was  specifically about updating the front page of the website to reflect the upcoming stable release, its features and all of that.

[c4757p]

Indeed, in fact one of the CERN guys had a nice-looking demo that I was rather fond of. Seems it'll be replaced soon.

[Watth]

3: Too many shortcut keys that you have to just know.  Those options should be in menus, and the shortcut keys should be specified within the menu for each option like most programs do like office programs etc.  This is something a lot of open source programs suffer from.  Why do they expect people to learn all these shortcut keys by heart? It should still have menu options and specify the shortcut so you can learn them as you're using the program, without needing to have a cheat sheet on a secondary monitor at all times.

This comment is very useless as is. What hotkeys do you think is not mapped to the menu? Please list them all.

Many are not mapped nor mappable; still true for the current version (4.0.3).
One simple example: "Cleanup Tracks an Vias" I often use it and wish I could do something in PReferences>Hotkeys>Edit Hotkeys. But nope.

EDIT: Same thing in 4.0.4

[Wilksey]

FYI KiCad is now on 4.04

[technotronix]

Last I have used is Kicad 4.0

[Tibby]

I have not read through all on this post so don't know if mine is here or not. I tried Ki Cad as an alternative as it is really really time to get away from my old Tango which I can drive blindfolded and with one hand behind my back.

However the first project, a simple board, required cutouts in the corners. I was damned if I could do this easily on the board outline. Short of actually calculating each corner co-ordinates and then tracing the outline accordingly. No tool to drag and drop a line, introducing a corner ? I asked on various forums and got no reply. So I quit as I had a job to do.

To me that was PCB cad 101, any improvements in this area ?

[s8548a]

 

I asked on various forums and got no reply. So I quit as I had a job to do.

https://forum.kicad.info/

Did you tried here ?

KiCad has developed a lot these days...the nightly builds are awesome.

[Thor-Arne]

You are in the old (obsolete) default canvas.
Switch to OpenGL, F11 or select it from the view menu.

[PCB.Wiz]

No tool to drag and drop a line, introducing a corner ?

Kicad can add a corner to a selected line in OpenGL view.
You can then mouse select and drag corners to mitre as needed, or enter the XY exactly.

Kicad has no direct 'mitre a corner' command, and has polylines only for Fill areas.
Other drawing entities like edge cuts, are line segments only.

[bson]

I tried to get it to build on both OS X and Win10, to no avail.  I wanted to add a component wizard that lets me easily create any JEDEC compliant pad-based IC part by simply entering a few standard measurements from the data sheet, like pad width.  Basically, create from eeschema the component including pins, the footprint, and a 3D model - and make it project specific.  For each part.  Eventually, if feasible, maybe save the parameters for it in the schema file and auto-generate everything actually missing when the project is loaded.  At some point permit multiple alternative footprint and pinouts, remembering old ones as they're change (to permit side-by-side comparison).  This would greatly simplify many things including keeping designs in git, moving between Windows and Unix like systems, reduce footprint errors, eliminate the need to have predefined libraries for every freaking package variation (which isn't feasible, or would be utterly humongous), make it quick and easy to copy-and-paste components and parts since all that's needed is the instantiation vector.  Not only that, but I could paste the vector in a post here, you could grab it and simply stick it in your project; straightforward and simple if the exchange format is something like base64 encoded json.

Oh, and another simple thing I wanted to add is when creating a new project it auto creates a .gitignore for *.bak, *~, etc.

And, rethink the cache to break out truly reproducible, cached data from project-local copies, then .gitignore the actual cache while managing the project-local copies.