Same behavior as I describe below. The symbols and wires move off grid when I hit the G key.
When I go to drag schematic portions using this recent 5.99 build, it will often drag schematic portions off grid. I was using the G hotkey, “50 mil” grid and had not changed the grid for a while.
When it happens, it is always with more than just one symbol. One symbol and a couple of attached wires are enough.
This never happened to me with previous builds.
Yesterday it was happening often and I tried to reproduce it while capturing a .gif using Licecap. But while running Licecap I was never able to reproduce it.
I will almost always use the “greedy select”, dragging a selection box and starting from the lower right. Then, I hit the “G” key and that is the moment when the selected portion will often move off grid.
UPDATE: With my .gif, I now want to report an issue. I am at: https://www.kicad.org/help/report-an-issue/ but that page seems completely static. Clicking on what appear to be links on that page does not do anything. I cannot figure out how to actually search known issues or report mine. I have reported bugs several times over the past few years, so either the page has changed or I have gotten stupider.
In 5.99 you can report a bug from Help -> Report Bug menu item. It just opens the gitlab issues page with a new issue, the version information helpfully prefilled. But you have to login to gitlab.
So it appears to have to do with items being off grid to start with. What position is that R? 499 value that you are picking up?
But yes please create a gitlab issue and we can discuss in detail there. Go to https://gitlab.com/kicad/code/kicad/-/issues to create a new issue (you’ll need to copy and paste the version data from KiCad) or as eelik says, you can get the information pre-filled by doing it through KiCad itself.
My theory is that the value 499 which is the grapping point is off-grid, and the whole selection is moved so that the value is on-grid but the rest off-grid.
EDIT: the challenge is to find out how the grab point is defined. I managed to do that with an on-grid value field, but when I moved that text off-grid and tried again, grabbing grabbed some other point!
Does this help? I have been editing the schematic and may have moved things, but most likely using the 50 mil grid only; not using a finer grid. I just now UPDATED to show the position of the 499 which was grabbed in the .gif.
OK I see your point regarding the grappling point. I will try to watch out for that during my continued editing. I reiterate: I am almost certain this never happened while using earlier 5.99 versions. It looks like my earlier install had been around October 10. It has long been my practice to position component text off grid and have not changed my habits recently. It is not plausible to me that this would be the explanation for the new issue.
Put a link on this forum to the Gitlab report as Eelik has done.
It just saves people searching on Gitlab.
I’ve been trying to replicate your issue to no avail but will keep trying.
I am often trying… just ask her
Maybe it is a windows version of 5.99 problem.
OK thanks. I wonder whether it could be a windoze related issue. The only thing that is unusual about my setup (that I can think of) is that I use a trackball and my mouse buttons are reversed. But that aspect has not changed. This bug…it seems to be consistently inconsistent. I think I have gone a day without seeing it much, but in the situation shown in my second .gif post it happened 100% when I used the greedy window select.
I was messing around with a stupidly consistent inconsistent problem a couple of weeks ago.
The 5.99 footprint editor.
Every so often I would use the D to move lines on different layers and 5.99 just completely crashed…6 times over two hours then nothing for a day and back again the next day.
Perhaps the Developers are trying to be trying also.
Funny I sometimes use D in pcb editor but when you said footprint editor I could not think of the D hotkey. So far as I know, D is defined for dragging tracks attached to a moved track or footprint. But I don’t think that tracks should exist within a footprint (in the footprint editor). When you say “line” do you mean a graphic line? I wonder whether the D hotkey was defined for moving a graphic line. I suspect that bugs crop up when you and I perform actions which the developers did not think of, and maybe that is happening?
When I make footprints I nearly always modify something I have “saved as”.
I find it easier to keep track of the layers and colours and line widths etc. I just increase/decrease the number of pads required on the appropriate coarse grid then go to a fine grid to push around/add/ subtract lines on Silk, Fab etc.
Seems to work.
You don’t need the M key to move, just highlight the line then, with left button depressed, move mouse. Also, both the D & G keys appear to “drag” as long as you use a fine grid and place the cursor at the end of the line and make sure you are on the right bloody layer.
Edit: I take some of the last paragraph back.
Highlight the line (cursor not at an end) then with the left button depressed the line will move.
Highlight the track (cursor at end) then with the left button depressed the line drags.
Also no need to change layers to complete any action with any graphic line.
Hmmm, maybe me using the D,G & M keys caused the crashing of the programme???
It’s good to have a link here, to avoid needless searching and confusion etc. Actual bug reports should be sefl-contained so that all necessary and important information is there without following links. It’s OK to add links for background information and I usually add there a link to a relevant forum discussion so that optionally a developer or a user can find the discussion which was the beginning of the bug report.
Sounds good…thanks. Sounds like it is good to reference in both directions.
I don’t know if you are using KiCad for commercial production but I am not (at least not yet) and I do not use a lot of bloody layers. (A couple of the layers have fairy dust sprinkled around though.) Seriously for example I usually do not set courtyards and sometimes just pads in addition to the default text layers. I am using KiCad often enough so that my use of the M and G keys (and D to a lesser extent) are habitual. But also it seems to me that KiCad should not crash so easily. IMHO your hotkeys should either work or not and should not crash the software. So maybe you have identified a bug?
No, hobby only these days, but I like to match my footprints with kicad library stuff. I’m also spending a lot of time exploring 5.99 both for looking for faults and to get a good working knowledge of the programme.
I learned something new here: don’t need M & D & G keys for moving graphic lines in the footprint editor.
Previously I had always used them out of habit, treating graphic lines as tracks.
Maybe I did also…but I am not sure I will quit using M in footprint editor. But like you, I will generally start with an existing footprint (or symbol) to make a new one.
but will keep trying.
