When checking the design rules in the PCB this happens: the important error message window disappears when clicking on the errors on the PCB. This did not happen in v 6.x. Is this about a setting in v 7.x or a bug?
Update: One more short video made (the third in the list below) where it shows the DRC result window is hiding behind the PCB window and that’s the reason it’s impossible to run the DRC easy and the way it must be. Is this a matter of a setting in KiCad/or suddenly in the OS somewhere (this worked Ok as is in KiCad v6.x)?
Sounds like a bug. Let’s see if team Kicad says otherwise.
I’m not 100% sure I have understood the text (and the videos):
the drc-result-window disappears if you click on the drc-arrows? if yes, that would be a bug.
Doesn’t happen on my installation.
at least necessary to know:
- exact version + OS
- multi-monitor setup
- for all drc-arrows? (or only error or only warning arrows)
The drc-result window jumps under the PCB editor window when clicking the arrows in the PCB editor window. So it’s impossible to see the link/cause between the error report and the PCB. I have to make the PCB window small enough =video 3 about half the screen to drag the drc result window beside the PCB editor window to work with it.
- MacOS 13.2.1
- Single Monitor
- Happens for all DRC errors.
It would be good if you open a bug-report on gitlab. If you use “pcbnew–>Help–>report bug” than the basic required information (kicad + OS-version) is already prewritten in the report.
Thanks mf, I logged in there but as usual it’s a mess for me and I don’t know what to do there, how to type etc without making anyone annoyed. It’s like landing back in DOS is the 80’s.
Type your free text description in the space just before the line “# Steps to reproduce” (you can make as many new lines as you want). Include a description of how the program should work correctly (expected behaviour). Here you can also paste screenshots or files you copy from your system.
In the lines 1. 2. etc. write down the instructions how to reproduce the erroneous behaviour you report.
You can press enter at the end of line 2. in order to make additional points 3. etc.
Go to Help → About KiCad → Copy version information and then paste between the two triple ticks ‘’’ at the end.
You can klick preview tab in order to see what it will look like.
All the pre-existing lines are just there for help and controlling the formatting, ignore them and just add your stuff in the places intended, like I described above.
I’ve also seen this behavior on MacOS 13. Generally speaking, Apple seems to have subtly broken the windowing system for KiCad. Cycling windows does not work consistently and windows that previously were “keep-in-front” are no longer. I haven’t had time to make the report, but I’m happy to give this report a “thumbs-up” if you post the link back here.
Ok Scandey, but as mentioned kicad 6x works just fine in the same MacOS if that says anything I don’t know.
but as mentioned kicad 6x works just fine in the same MacOS
mention that also in the bugreport.
The description from hmk is good.
The prefilled gitlab-form contains already some (at first irritating) formatting, so I understand your reservation:
- Lines starting with #: these form thick formatted headlines to differentiate between the section. There are 3 sections which should be filled:
- reproduction steps (as exact as possible)
- Kicad-version and used OS (prefilled from kicad bugreport-function)
- text inclosed in <> seems to be a comment - I usually delete these lines
I have attached a screenshot from my last issue. As you can see I delete all comment-lines after the #-marked intermediate headers.
If you open the issue I will have a look on that, but I can’t open it myself because that would give false information regarding the OS.
My apologies if this git reporting is not for me, I don’t understand it: what and where to write what, that’s why I make videos which is not so much liked. Why not simply make a html form or something modern to fill in the bugs? I will wait and regret I converted and continued this project in v 7, I should have continued and finished the project in v6 Btw, again, In Cadsoft/Autodesk Eagle it would have been fast and easy to jump straight back with the project to the previous or an even earlier version of Eagle as nothing really happened here. Bitter or backward-looking? You decide.
My apologies if this git reporting is not for me
Happens, that’s real life, sometimes one can’t come to terms with some things.
idea: copy your kicad/OS-version (from kicad–>Help–>About Kicad → than button “copy version info”) into your next reply and I will open the issue. If you want you can than write/add your comments in that gitlab issue.
Btw, again, In Cadsoft/Autodesk Eagle it would have been fast and easy to jump straight back with the project to the previous or an even earlier version of Eagle as nothing really happened here.
That’s only partly true. It works only back until v6 (as the xml-format was introduced). And even then: If I use new added eagle features these are rejected if the board/schematic is loaded in an older version. And some development was also seen in eagle between v5–>v6–>v7–>v9 (autocad), and I have used some of these new features regularly:
- external devices (often used for auxiliary or mounting parts)
- introduced multiline text - these multilines are all ignored. most schematic documentation is lost
- hierarchical design using moduls: ignored in older versions (albeit never used - I feeled that feature was not ready for production)
- 3D-models (added at v8/v9 at autocad time). never used myself (no fan of subscription and fusion360-integration), but got 2…3 projects already from people using the current eagle-version. The 3d-features are thrown away if i load that in my eagle v7.7 (last cadsoft version).
Yes, the list is not that long. Bitter or backward-looking? I don’t know, but I have have made peace with that development and use eagle nowadays only for my legacy projects. Kicad has proved to be a good successor (for my needs).
Thanks for your help mf_… I like KiCad and for sure want to use it and think the development goes in a good direction! Eagle is still used here now and then, an old version, for older projects but no real plans to start new projects with it, the note earlier was just an observation for its forward- AND backward compatibility which I have no idea how difficult it might be to include in KiCad.
Today I also tested version: 7.99.0-535-gad5d3d4eba, release build and the DRC behaviour remains also there… and then also tested the windows version 7.0.1, release build in Mac OS 13.2.1 – via Parallels Desktop – and the DRC part worked fine so a wild guess is that the main problem is not rooted in Mac OS itself.
Btw, I have also tested Kicad 7.0x in OS Big Sur (11.7.4) and Monterey (12.6.1) and they all behave the same in this topic = the DRC checker window does not stay in front of the PCB window, it jumps behind which makes an appropriate DRC a difficult task.
The Schematics electrical rules check (ERC) works fine = the ERC checker window stays in front!
Update: Nope, it doesn’t work in Schematics checker (ERC) either. It did before but not now, hm.
I’ve found this behaviour too. It looks like it’s already been reported on the bug tracker.
Worth an upvote if you are affected (once it’s been accepted as a bug).
Thanks all. How long does it usually take from a a reported “bug” until someone in the develop team starts diving into it/eventually has a solution/new release?
It varies, can’t give any good estimates.
Everything from twenty minutes to years, depending on severity and many other factors.
Crash bugs often get quite good attention, especially before and after a stable release, but even in the nightly development they can get fixed fairly soon.
I see. In this case the application still works withouth crashing, by making the DRC/ERC checked window half the screen size while checking, a bit like a disabled application so it’s still manageable with some workarounds, so this eventual bug is probably not in a hurry to get fixed.