Testing on platforms shows we don't need this differentiated case between toolbar and non toolbar icons. Since we don't start with an small base bundle icon for the icons that probably had issues before.
wx infobar generic will wrap text, changing the stored label data on
instantiation. Since we might expand the infobar later, this presents
an issue as the newlines are then baked into the string.
We do two things here: keep a copy of the original string to make sure
that we can reset it on update and do a hard calculation of the minimum
height for the infobar to ensure we are displaying the full text string
Fixes https://gitlab.com/kicad/code/kicad/issues/19799
wxBitmapBundle assumes the smallest bitmap added is the intended "original" size for a particular use case.
And generally that is probably true. However, we re-use icons in some places where we intend for them to start at 16
or start at 24. This is problematic when GetPreferredBitmapSizeFor is called for calculations because it'll return the
16*scale number instead of 24*scale number. So let's just allow passing in a min height restriction to KiBitmapBundle
for when we reuse bitmaps.
The controls were visible momentarily when clicking on cells, at least on MSW.
The wxStyledTextCtrl is still visible, but is not multi-line with scrollbars.
This implements the wxWidgets fix for KiCad. We can't wait for distros
to update their wx libs so until then, we'll roll our own.
Nicely, this also implements the MacOS setting that was an ifdef
previously
Fixes https://gitlab.com/kicad/code/kicad/-/issues/19506
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
The smart pointer was only used to pass the pointer into the function,
and the pointer was being kept in multiple places, so it just made the
API surface a bit convoluted.
Assert message:
Assertion failed at C:\jenkins\workspace\build-windows-kicad-msvc-8.0-stable\.build\kicad\common\widgets\widget_hotkey_list.cpp:309 in WIDGET_HOTKEY_LIST::getExpectedHkClientData: hkdata != nullptr - No hotkey data found for list item
Fixes KICAD-7NV
Crash was because a C-style cast was used to attempt to traverse
a virtual object hierarchy. In this instance, I think we do need
to use a dynamic_cast to get the right type out.
The call to FOOTPRINT_LIST::GetInstance( aKiway ) returns
a null pointer when it fails, rather than throwing. So this
wouldn't actually catch a KiWay failure and avert a segfault.
And no other caller of ReadFootprintFiles is in a try - so either
this function won't throw, or if it does, all callsites need
updating. For now, go with the majority.
Includes zoom to selection, and pan to selection (which
centres the result but doesn't change the zoom).
I'm not sure this is the perfect solution to search pane
settings, but it's near to the action, but not taking up
too much space, doesn't need to open a modal to mess
with it, and has room for more options in future.
I haven't made toggling these options into full-blown
TOOL_ACTIONs, but they could be if a hotkey to toggle
these is desirable - it's an ACTION_MENU, so it should
just slot in..
Fixes: https://gitlab.com/kicad/code/kicad/-/issues/16192
Then you can just toggle back and forth with '/'.
One day, these frames should use a tool manager for this
kind of thing (also for the ruler tool, but lots of other
things on top), but for now just bind a char hook.
