Settings should be initialized on start-up. This removes the option of
lazily loading the settings from file and instead requires all settings
needed to be loaded on KiFACE start before requesting data from the
settings object
The base class constructor expected a const string, and the other
PGPROPERTY constructors do as well, so make this const.
This was also a compile error when building against wx 3.3.
The spacemouse driver, particularly on Mac, is extremely unstable and
causes crashes even when not being used. This places the interface
behind an advanced config flag to ensure that users can affirmatively
opt-in to the potential for crashes
This reverts commit 33da9b2327 and the
following commit dc08c48f33.
C++17 changed the behavior of static class member variables that are
constexpr defined. Previously this definition/declaration split was
valid for constexpr members, but after C++17 the static constexpr member
variables are automatically inlined, so the declaration is no longer
exported in some compilers (GCC 9/10/11 seem to have problems).
An alternate way of constexpr member variables is putting the
initialization in the class definition, but we can't init a COLOR4D
object when defining the COLOR4D class.
For now, revert this change until we can figure out the proper way of
architecting these colors.
This library is meant to move non-EDA items (language extensions,
library extensions, etc.) into the lowest-level of our dependency chain.
This library should never depend on anyother non-thirdparty code in the
kicad codebase.
This fixes the initialization-order fiasco in the color initialization
sequence, which was originally fixed by making COLOR4D constexpr, but
was then reintroduced when the assert was changed to wxASSERT (wxASSERT
is not compatible with constexpr).
* Add compare method to COLOR4D object.
* Add unit test to validate COLOR4D comparison method.
* Add missing color test in text attribute comparison method.
* Add unit test for text attribute object.
* Remove unnecessary headers from text attribute header.
* Move text attribute code into separate source file.
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.
Seth Hillbrand
Jeff Young
Marek Roszko
Ian McInerney
qu1ck
Mike Williams
Wayne Stambaugh
Ian McInerney
Jon Evans
Nimish Telang
Roberto Fernandez Bautista
Alex