Use wxCOL_WIDTH_AUTOSIZE instead of fixed column sizes. This doesn't fix
the initial sizer layout issue on wxWidgets 3.0 but at least resizing the
dialog has better column width behavior.
Delete the copy ctor and assignment operator to start with, but
even then the separate apps each have their own statically allocated
copy of the common actions. So we need to update all of them, which
also means having the kicad manager frame's set of actions on hand).
This changelist also adds a Clear Hotkey Assignment function since
the hotkeys set is now likely to be sparse with respect to the
actions.
For BUTTON_ROW_PANEL::BTN_DEF_LIST, the button definition does not need to be
passed by value, by non-const reference avoids copies and this addresses the
Coverity warnings: 184130, 184134, 184140, 184167.
Also use a unique_ptr to clarify ownership sementics when handing widget
over to WX.
There are lot of places where constants are used in the KiCad UI
as "magic numbers". The most common one is "5", used in many
wxFormBuilder and manual UI constructions as the margin.
This commit provides a place for all UI to look up shared
constants and other functions, to help create a consistent UI using
functions that provide meaning and intent to these magic numbers.
This is in preparation for making this widget optionally read-only.
Major changes:
* Construct panel in code, not with wxFormBuilder. This make's it
easier to conditionally construct elements that won't be used
in a read-only mode (e.g. the buttons).
* Use a generic "button row panel" widget for the buttons, as the
sizing and layout logic is reusable in nearly all dialogs, and
it's simplifies layout in the higher-level dialog widget. This
widget is one example of many possible "reuable widgets".
This separates the "ground truth" store of hotkeys from what is shown
in the dialog. This will allow us to filter the displayed hotkeys
while keeping the same underlying data structures.
Now, the UI data items interact with an intermediate set of data, which
represents the "original" hotkey data, and the "changed" data. The
ultimate aim here is to allow UI elements to come and go, but the
hotkeys that are "in-edit" are preserved.
This also allows us to abstract some bookkeeping complexity
out of the WIDGET_HOTKEY_LIST class into a separate non-GUI
class.