The patch for color selection.
https://bugs.launchpad.net/kicad/+bug/1437724
Alexander.
- 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.
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.
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?
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.
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.
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.
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.
- 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
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.
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.
What large open-source core development team?
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.
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.
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
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...
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.
Kicad "teardrops".
http://blog.elphel.com/2015/04/trying-out-kicad/
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.
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.
IIRC you were not good at describing your issue. Please spend more time on your bug reports.
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.
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.