Schematic and pcb editor without screen leftovers when moving parts.
Alexander.
Schematic and pcb editor without screen leftovers when moving parts.
Alexander.
12
I don't consider language in a library to be a kicad bug.
This is a good idea. :-+
Hopefully stuff will be fixed and optimized.
I use the kicad-product-r5640 (http://www2.futureware.at/~nickoe/).
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.
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.
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.
traps: kicad[24070] general protection ip:7fd777d9f558 sp:7fffc80652b0 error:0 in libgobject-2.0.so.0.4400.1[7fd777d7e000+51000]
Any chance you can get a backtrace? Feel free to submit to the bug tracker (https://bugs.launchpad.net/kicad/+bugs?orderby=-id&start=0).
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.
Did we mention proper clipboard (copy-paste) functionality?
Alexander.
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?
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.
QuoteWhy 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.
QuoteWhy 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?"
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.
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?
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.
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.
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?
Selecting mask color for the 3D viewer. There is already a patch available.
(http://i.imgur.com/k4XFfAWs.png) (http://i.imgur.com/k4XFfAW.png)
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.
Definitely a wishlist item: inverted text on copper layers.
Inverted as in 'photographic negative' (etched text).
Inverted as in 'photographic negative' (etched text). Currently the copper pour is removed & normal text is added.
See the image I posted. It destroys part of the copper pour (positive text in empty box).
Yup, leave the copper pour alone & etch the text away.
- 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
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.
- 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 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.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. (https://twitter.com/kicad_pcb.)
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.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. (http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5679.)
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 (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: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.
* bug report is marked "Invalid" for an entirely wrong reason - https://bugs.launchpad.net/kicad/+bug/1464331 (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 (https://bugs.launchpad.net/kicad/+bug/1464331/comments/11)
* "you obviously don't know what a microvia is" - https://bugs.launchpad.net/bugs/1464292 (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 (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:You can add keywords to parts...
- 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 eI 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 attitudeRead https://xkcd.com/927/, (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.
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 (https://bugs.launchpad.net/kicad/+bugs?orderby=-id&start=0).
I'll do some futher investigation before report this bug.
Kicad "teardrops".
http://blog.elphel.com/2015/04/trying-out-kicad/ (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?" :palm: 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.
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: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.
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.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.
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: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.
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
The scrolling mechanism is inconsistent between normal and GAL views though.
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.
This must be a windows thing. Zooming is just F1/F2 for me here, no matter what renderer I choose.
"Edit, delete"? That works. I use BZR5872.
"delete" from a context menu works too (after having selected a footprint).
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.
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.
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.
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.
DISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.
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?QuoteDISCLAIMER: [...] Also note that the old stable is deprecated and a new release is imminent.
On the installing page.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?QuoteDISCLAIMER: [...] 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.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?QuoteDISCLAIMER: [...] 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.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?QuoteDISCLAIMER: [...] 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...
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 ;)
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.
I asked on various forums and got no reply. So I quit as I had a job to do.
No tool to drag and drop a line, introducing a corner ?Kicad can add a corner to a selected line in OpenGL view.