If we pass a COMMIT to a posted action, the COMMIT
may no longer exist when the action is run.
Equally problematic, if another COMMIT is pushed
in between we'd probably also run into trouble.
We still allow the API to do this because we don't
have a better solution at present. But we need
one.
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
ki::any is a standards-compliant implementation, based on the GCC
standard library. However, it uses type_info::hash_code() to check
the validitiy of a ki:any_cast, rather than comparing the type_info
objects directly. This comparison, used in the standard
implementations, is fragile across translation unit boundaries when
built with Clang.
In commit 7cb754dd a call to wxMilliSleep(50) was removed (because it created
lag in editing) but this removal created a 100% CPU core usage.
Using a much small sleep time (1ms) fixes these issues.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17979
There doesn't seem to be a need to actually clear transitions for the
tools when running a handler. This clearing also prevents running
another nested handler from the same tool.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16449
Note that "immediate" doesn't mean quite the same thing: while it will
enter the tool immediately, it won't necessarily finish the tool during
the call if the tool has an event loop. So for something like Rotate
"immediate" and "synchronous" have the same behaviour, but for something
like Move they do not.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/15085
We're getting segfaults in places where this isn't checked. Also, add
some asserts so we can catch bad tool push/pop.
Removes all uses of GetCommandStr() and makes it private.
Without this the event is on the stack, and as soon as the tool calls
Wait(), the event will be deallocated. The aEvent reference will then
point to invalid memory.
These can happen when a tool is active that sends signals when exiting
(e.g. deselectEvent). These may be caught by the active loop in another
tool which might try to update the UI after it has been freed. By
marking all tools as "shutdown", the only event returned to them should
be null. As an extra precaution, we flag the shutdown globally within
the tool manager and check this flag before launching either events or
new tools
Fixes https://gitlab.com/kicad/code/kicad/issues/10698
This is for the out-of-box experience for novice users. It is presumed
that folks with larger more complicated boards will turn it off.
Fixes https://gitlab.com/kicad/code/kicad/issues/6413
Jeff Young