Author Topic: KiCad gripes list - post gripes here  (Read 41822 times)

0 Members and 1 Guest are viewing this topic.

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: KiCad gripes list - post gripes here
« Reply #50 on: June 10, 2015, 05:50:19 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2450
  • Country: gr
Re: KiCad gripes list - post gripes here
« Reply #51 on: June 10, 2015, 05:53:18 pm »
Doesn't bother me that much. I will recompile it with this option added. As I do now.

Alexander.
Become a realist, stay a dreamer.

 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: KiCad gripes list - post gripes here
« Reply #52 on: June 10, 2015, 10:41:29 pm »
- 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.
 

Offline ijsf

  • Newbie
  • Posts: 4
  • Country: nl
    • ijsf.nl
Re: KiCad gripes list - post gripes here
« Reply #53 on: June 12, 2015, 12:01:55 pm »
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.
« Last Edit: June 12, 2015, 12:08:27 pm by ijsf »
Hard- and software (reverse) engineering ahoy.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: KiCad gripes list - post gripes here
« Reply #54 on: June 12, 2015, 12:46:56 pm »
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?
« Last Edit: June 12, 2015, 12:49:34 pm by Circuiteromalaguito »
 

Offline jsquaredzTopic starter

  • Contributor
  • Posts: 45
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #55 on: June 12, 2015, 01:17:23 pm »
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.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: KiCad gripes list - post gripes here
« Reply #56 on: June 12, 2015, 02:36:00 pm »
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.
 

Offline nickoe

  • Contributor
  • Posts: 24
Re: KiCad gripes list - post gripes here
« Reply #57 on: June 12, 2015, 06:08:50 pm »
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.
 

Offline ijsf

  • Newbie
  • Posts: 4
  • Country: nl
    • ijsf.nl
Re: KiCad gripes list - post gripes here
« Reply #58 on: June 16, 2015, 12:11:28 pm »
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.
Hard- and software (reverse) engineering ahoy.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: KiCad gripes list - post gripes here
« Reply #59 on: June 16, 2015, 07:08:12 pm »
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/
 

Offline jsquaredzTopic starter

  • Contributor
  • Posts: 45
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #60 on: June 16, 2015, 07:11:06 pm »
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... 
 

Offline jsquaredzTopic starter

  • Contributor
  • Posts: 45
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #61 on: June 16, 2015, 07:27:51 pm »

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...
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: KiCad gripes list - post gripes here
« Reply #62 on: June 16, 2015, 07:49:35 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Palmitoxico

  • Regular Contributor
  • *
  • Posts: 55
  • Country: br
  • no
Re: KiCad gripes list - post gripes here
« Reply #63 on: June 18, 2015, 12:50:44 pm »
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!
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2450
  • Country: gr
Re: KiCad gripes list - post gripes here
« Reply #64 on: June 18, 2015, 04:08:06 pm »
Become a realist, stay a dreamer.

 

Offline jsquaredzTopic starter

  • Contributor
  • Posts: 45
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #65 on: June 19, 2015, 02:03:09 am »
Kicad "teardrops".

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

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

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 708
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #66 on: June 19, 2015, 04:20:42 pm »
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?" :palm:  although to their credit they did go on to explain the priority thing.

« Last Edit: June 19, 2015, 04:23:15 pm by mark03 »
 

Offline nickoe

  • Contributor
  • Posts: 24
Re: KiCad gripes list - post gripes here
« Reply #67 on: June 22, 2015, 08:49:34 pm »
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. :D

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?" :palm:  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.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 708
  • Country: us
Re: KiCad gripes list - post gripes here
« Reply #68 on: June 23, 2015, 12:32:05 am »
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.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: KiCad gripes list - post gripes here
« Reply #69 on: June 23, 2015, 01:03:19 am »
Do future improvements could provide features from this tool?
http://www.compuphase.com/electronics/kicadlibrarian_en.htm
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: KiCad gripes list - post gripes here
« Reply #70 on: June 23, 2015, 01:49:47 am »
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 ;)
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline nickoe

  • Contributor
  • Posts: 24
Re: KiCad gripes list - post gripes here
« Reply #71 on: June 23, 2015, 06:35:39 am »
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.
 

Offline Tandy

  • Frequent Contributor
  • **
  • Posts: 372
  • Country: gb
  • Darren Grant from Tandy, UK.
    • Tandy
Re: KiCad gripes list - post gripes here
« Reply #72 on: June 23, 2015, 11:22:42 am »
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.
For more info on Tandy try these links Tandy History EEVBlog Thread & Official Tandy Website
 

Offline Red Squirrel

  • Super Contributor
  • ***
  • Posts: 2748
  • Country: ca
Re: KiCad gripes list - post gripes here
« Reply #73 on: July 02, 2015, 06:49:09 am »
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.
« Last Edit: July 02, 2015, 09:23:04 pm by Red Squirrel »
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: KiCad gripes list - post gripes here
« Reply #74 on: July 02, 2015, 05:45:50 pm »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf