This moves a fiddly little bit of logic used by a few UI
classes into a central location.
Also means that the paths dialog learns to expand the
first cell when it needs to (like the text variable
panel).
Schematics, symbols, boards and footprints all get the ability to store
files inside their file structures. File lookups now have a
kicad-embed:// URI to allow various parts of KiCad to refer to files
stored in this manner.
kicad-embed://datasheet.pdf references the file named "datasheet.pdf"
embedded in the document. Embeds are allowed in schematics, boards,
symbols and footprints. Currently supported embeddings are Datasheets,
3D Models and drawingsheets
Fixes https://gitlab.com/kicad/code/kicad/-/issues/6918
Fixes https://gitlab.com/kicad/code/kicad/-/issues/2376
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17827
Set a default control so that the escape key closes the dialog.
Select the OK button after the user selects an annotation option. This
allows for keyboard navigation of the dialog and saves an extra mouse
move and click to when choosing an annotation setting.
Note: while we try to omit sizing info from FBP files, the list
controls assume way too wide a minimum width if they're not set.
Furthermore, sizing the dialog ends up leaving them a certain size
and clipping other elements is the dialog itself doesn't have limits
set. Sigh.
For historical reasons, they are stored in mils, but using int create rounding
issues when converting to/from mils to IU in dialogs.
This is a minor but annoying issue.
Fixes#16000https://gitlab.com/kicad/code/kicad/-/issues/16000
Also simplifies the dialog by removing the user grid (now that you
can add as many user grids as you want).
This does mean that you can no longer have an asymmetric grid, but
it gets too complex if we allow everything for everyone.
Don't assume the dialog is mode-less and call Destroy() from within a
dialog method. This will most assuredly crash if the dialog is shown
modally or quasi-modally.
Don't leak memory for mode-less dialogs created on the stack. Make sure
when the parent frame window is closed that all mode-less dialog memory
is cleaned up. Dialogs are not child windows like controls and toolbars
so their memory does not automatically get cleaned up when the parent
window is destroyed.
Do not directly access frame parent window's pointer in dialog destructors.
Apparently the tear down order when destroying mode-less dialogs is not
guaranteed so the parent window may get deleted before the dialog causing
a crash when accessing the parent window pointer from the dialog dtor.
Do not close mode-less dialogs in the parent frame's destructor. This
doesn't guarantee that the dialog(s) will be destroyed before the parent
but it may reduce some careless mode-less dialog event handling in the
future.
John Beard