* QShortcut falls down on duplicates. It can have activatedAmbiguously
events, but these happen in arbitrary order and the shortcuts on
menu items just swallow the ambiguous activate so it's not useful.
* Instead we just let MainWindow pick up ShortcutOverride events and
consult a mapping of which shortcuts to use. We can use a smarter
selection method to choose the more 'local' shortcut if two shortcuts
that conflict exist.
There are a few places where the logical 'and' operator
was used to check if a given flag is enabled however
that is not the correct operator.
The binary 'and' operator should be used where
the enum acts as a flag.
* This really isn't ideal as it means the python module will only work
with that specific major.minor version of python, when it could in
theory work with any python version above 3.2 or so, depending on what
features are used.
* Since we're not distributing these modules yet though, add this
linking to support -Wl,--no-undefined.
* Annoyingly although Qt has an internal bool allowUserMoveOfSection0
which does exactly what we want allowing the tree column to be
movable, we can't enable it because it's private. So instead we have
to re-implement section moving ourselves.
* Minor tweak - also made RDTreeWidgets non-movable by default since
usually we don't want to allow it.
* There's a messy order-of-operations thing to deal with various
different themes, as well as a couple of minor problems, but at least
the highlight and selection bars draw fairly consistently and don't
leave an ugly gap over the branches.
* When we add it, if a log is already open that's when we get the
callback to OnLogFileOpened to initialised. If we close afterwards,
we'll be in an inconsistent state.
* This still isn't perfect with some custom style stuff but it's next
to impossible to get working right. In theory we should manually
draw PE_PanelItemViewItem in the gap in drawRow() or so to make sure
we also draw any on-hover highlight over objects, but that doesn't
seem to work.
* It's not entirely clear if this is the intended fix, but otherwise
since we're not running QApplication::exec() the main event loop has
the same 'loop level' of 0 as the event level when it's fired. The
proper functioning seems to be that the posted deleteLater event
should have an event level of 1 which then means it will be processed
when coming back to the exec() loop level of 0, but since we don't get
that, just run it manually after all other events.
baldurk