We had been maintaining the tree collapse state for "clear" actions
where the user went back to no object search. This was helpful in the
case where we had previous items (e.g. last placed element)
But this causes isses when a sub element was previously select on GTK.
Now we choose safety for GTK over the pretty display
Fixes https://gitlab.com/kicad/code/kicad/issues/8198
So many things can go wrong with this control in GTK. We have to
collapse the tree when updating the search string to avoid a crash when
referencing a child object but collapsing the tree will iterate over
elements and crash when we have deleted a symbol.
The temporary fix for this nonsense is to carefully order the calls.
We only need to collapse the search tree if we are not keeping our state
(in other words if we are fully re-building the tree)
Fixes https://gitlab.com/kicad/code/kicad/issues/6910
(cherry picked from commit 8af4cf88a0)
When preparing for clearing the tree, GTK requires walking through
parents. After calling "Freeze()" to protect against returning bad data
(see #6458 and #4471), we can no longer access Parent() from GTK and the
tree cannot be cleared.
The fix is to collapse the first element if it is open. This prevents
the common case of the history elements being expanded in the tree
Fixes https://gitlab.com/kicad/code/kicad/issues/6102
In some cases, the BeforeReset() will cause an iteration over the tree
elements. If we have deleted an element before doing this, we risk a
corruption/crash.
Fixes https://gitlab.com/kicad/code/kicad/issues/6192
(cherry picked from commit 3bd080b64e)
There is a rendering bug in GTK3, which appears to be
an upstream GTK issue.
This can be worked around by, when filtering, ensuring the
*parent* item of the selected item is visible. This will
not cause the selected item to not be visible, as the selected
item will be the first shown child. So it will be visible, as long
as the list box is greater than a single row high, which it will be
in all practical scenarios.
This is done on all platforms, as it has a beneficial side-effect:
the parent library of the selection is naturally shown to the
user, so they don't need to scroll up to see what library their
current filter selection was in.
Fixes: lp:1804400
* https://bugs.launchpad.net/kicad/+bug/1804400
(cherry picked from commit 10900c918f)
The indent size was estimated by the width of characters. But MSW
indent is substantially different from OSX and Linux. It also cuts off
the middle characters rather than the end leading to poor display if the
width does not fit. This uses the system setting for indent to account
for the indent spacing + 'M' to account for the arrow inset.
Fixes: lp:1815401
* https://bugs.launchpad.net/kicad/+bug/1815401
When filtering, we update the width of the displayed column to ensure
the full text is visible to the user. Check is rough, based on line
width (doesn't completely account for differing char widths) but is
sufficient for the approximate difference
Fixes: lp:1815401
* https://bugs.launchpad.net/kicad/+bug/1815401
Fixes: lp:1788495
* https://bugs.launchpad.net/kicad/+bug/1788495
When the user cancels the footprint load, we should assume they are
canceling the placement of a new footprint. This also adds sanity check
when populating the list
Fixes: lp:1814181
* https://bugs.launchpad.net/kicad/+bug/1814181
Be more intelligent about sorting lib tree items. (Footprint
entries, for instance, come out of an already-sorted list.)
Don't recreate menus twice when laoding Footprint Editor.
More pervasive use of WX_FILENAME to avoid expensive calls to
wxFileName::SplitPath() and string concatenation.
For POSIX kernels do all the work on the file-system side so we
don't have to keep converting back and forth between encodings.