- Changing the style sheets for the selection frame dynamically considerably
slowed down the handling of the mouse events.
Instead two separate widgets with fixed style sheets are now used.
- Recreating the macro segments after dropping a widget took too much
time leading to unresponsive drop operations
This is a workaround to handle random segfaults triggered when using ...
QMetaObject::invokeMethod(this, "RedrawImage", -Qt::QueuedConnection,
Q_ARG(QImage, image));
... from within CheckForMatchLoop().
Even using BlockingQueuedConnection causes deadlocks.
This was done to give some hints which controls will likely need to be
used to avoid mistakenly clicking on the action controls when editing
conditions.
I wrongly assumed that std::deque would guarantee that pointers to
elements in deque would not be invalidated by insert() or erase() but
this is not the case it seems.
""
An erase in the middle of the deque invalidates all the iterators and
references to elements of the deque. An erase at either end of the deque
invalidates only the iterators and the references to the erased
elements.
""
I guess I got lucky noone ran into these sorts of crashes for now?
Previously once a macro segement was selected you could only deselect it
by clicking on different macro segment, thus never allowing the user to
deselect all macro segments
Problem was introduced when adding header info.
To avoid the issue in future forward signals of the main plugin window
via condition and action edit widgets instead of relying on parent()
being the main window.
Almost every macro condition can benefit from having the option to
specify a time constraint.
Instead of adding it to each condition separately add it to all
conditions with the option of excluding it when registering a new
condition type.
Using int is an id was getting messy with more and more conditions and
actions beeing added.
It also made the order of conditions and actions in the respective
comboboxes unchangable as there was a 1 to 1 relation of index and id.
