Return key is used to change cell line. If cell was in edition, the edition is saved before changing line.
Before this change using return key in the last row, if edited, both saved the change and create new row.
After this change, it'll just save the just, and will need a second key press to create a new row.
This adds an icon to the left of the row with an error symbol if the
file can't be found or opened, and shows a tooltip over the icon with
and error string.
Fixes https://gitlab.com/kicad/code/kicad/issues/3815
The accelerator strings really shouldn't be part of the translation,
and some translations have cause the accelerator keys to be incorrectly
handled. It is simpler to make it separate and just join them to the
translated string.
Make all accelerator modifiers use lowercased Ctrl instead of CTRL
to be the same as the other modifiers.
Fixes https://gitlab.com/kicad/code/kicad/issues/5992
While wxWidgets has Navigate() and NavigateIn(), they're not compiled
on GTK because it supposedly has native TAB control. Of course its
native TAB control won't get you out of a grid, so that leaves us in
a bit of a pinch. This implements a poor-man's Navigate() which will
at least get us out of the grid.
Fixes: lp:1810569
* https://bugs.launchpad.net/kicad/+bug/1810569
wxWidgets has several bugs that result in cell editors being closed
right after they're opened. There are two wxWidgets hacks to
partially address this: the SetInSetFocus() hack, and a slow-click
hack. We used to try and work-around these bugs ourselves for
single-click access, but this changelist moves those over to
wxWidget's slow-click hack.
Fixes: lp:1817965
* https://bugs.launchpad.net/kicad/+bug/1817965
For unknown reasons, GTK3 may send resize events when editing grid
fields. This can cause the grid editor to exit, losing the focus and
overwritting the characters at the next input.
We avoid this by filtering the size events when the size doesn't change.
Fixes: lp:1817810
* https://bugs.launchpad.net/kicad/+bug/1817810
NEW: By default a clipboard is pasted to a grid starting from the
cursor position and doesn't matter is a selection of cells present or
not. Often a grid represents the data of a few similar objects like
components, for example. Some number of cells (fields) may have the same
value for a few rows (components). In this case, when filling data we
must copy the range of identical cells from the first row of similar
components and then paste it to every row of the rest components (by
default). From now it may be done easier. We must copy the range of
identical cells from first row of similar components (here is no
changes) and then select rectangular range of cells (for multiple rows)
where must be placed copied data. After pasting copied cells will be
pasted to every selected row.
So in general, we can copy cells from one row and paste it to multiple
rows at a time.
This new feature also makes possible to copy value from one cell and to
paste it to all from the selection.
If copied range of cells is larger than the selection then only the part
of clipboard that matches the selection will be pasted.
CHANGED: On pasting multiple rows from a clipboard to the end of a
grid, the grid is automatically expanding (appended needed number of
rows). In general case the grid expanding on pasting is inappropriate.
Rows must be added by tools like a button or a menu command etc. In some
cases rows cannot be added at all. So we must paste only the part of
the clipboard that fits between the cursor position and the end of the
grid without a grid extending.
CHANGED: First click sets a cursor to the specified cell, second click
activates editor (current realization, where first click activates cell
editor, is very buggy especially with cells selection).
Set cursor on cell of reference on mouse left click in Fields editor of
Eeschema.
Jeff Young
Mike Williams
Lucas Dumont
Marek Roszko
Jon Evans
dana
Ian McInerney
Wayne Stambaugh
Roberto Fernandez Bautista
Jonathan Haas
jean-pierre charras
Seth Hillbrand
Konstantin Baranovskiy
Seth Hillbrand