we can't use an event filter on the top level webview, because it
ignores the return value of the filter and leads to Anki thinking
keys have been pressed twice
and if we use an event filter on the focusProxy(), the
keypress/release events are sent even when a text field is currently
focused, leading to shortcuts being triggered when typing in the answer
to solve this, we move away from handling the key press events
directly, and instead install shortcuts for the events we want to
trigger. in addition to the global shortcuts, each state can install
its own shortcuts, which we remove when transitioning to a new state
also remove the unused canFocus argument to ankiwebview, and accept a parent
argument as required by the code in forms/
- key presses while a webview is focused no longer make it to the
main window's keyPressEvent() routine, so AnkiWebView now uses its
event filter to pass the key events to the main window
- move the shared key handling out of keyPressEvent into
globalKeyHandler()
- make sure all key handling routines return true or false to
indicate if an event was handled or not
- remove focus when esc hit in the main window, to retain old
behaviour of allowing esc to clear focus from the type answer box
keyPressEvent/etc no longer work with qwebengineview, so we need to
install an event filter to catch things like ctrl+c. drag & drop
doesn't seem to be supported until 5.7
- a few issues to work out still, and editor changes not done yet
- for communication between webengine and python code, we set window
.location to 'http://anki/<something>' - the leading http is
necessary for qt to call the link handler, which was introduced
in qt5.5
- the designer files now use a promoted qobject to create instances
of AnkiWebView
- we use the css zoom property to alter webengine font size based on
system dpi
- prefs and addons folder stored in new location (at least for now)
Can't automatically prevent the star from being affected by image resize
and other CSS properties, as even weirder things happen to it when we
try. However, this will give users the ability to fix it themselves.
- when answer not correct, show both the given and correct string in separate
markup. we use red/green for the given string to indicate what was correct,
but we use grey rather than red on the correct string to indicate what was
missing, as red is misleading
- colours can now be customized in css with .typeGood, .typeBad and
.typeMissing
- answer now shown in monospace so given/correct lines up; can be customized
with code#typeans
- do away with 'correct answer was' text that people didn't like
Python used to use C-style division, where division of two ints was
truncated, and division involving a float resulted in a float.
This is confusing, because you often can't tell from looking at a
line of code in isolation what sort of division it's supposed to do.
With 'from __future__ import division' Python ensures that division is
always explicit.
// means (floored) integer division
/ means float division
regardless of argument types.
This should make the source a bit clearer now, as well as removing one
obstacle if Anki is ever ported to Python 3.
