When a long text is accidentally selected or copied while the scan popup
is on, Goldendict spends a lot of CPU time to gradually create a
"No translation..." article. When translation of huge (e.g. 15 MB) text
from the clipboard is (accidentally) requested, Goldendict freezes for a
while. Turning the added input phrase limit option on eliminates this
waste of the CPU time.
I have implemented these options primarily for selection and clipboard,
but they also affect mouse-over translation on Windows and command line
translation requests. This is mostly because I did not bother to limit
the options' scope. I guess hovering over an extremely long text without
spaces (e.g. Base64-encoded) could cause the same performance issue on
Windows. The command-line translation could be requested from a script
that integrates Goldendict with some other application, from which long
text could be sent for translation by accident.
I hope that the default value of 200 characters will be sufficient for
just about any real-world user input in any language. The option is on
by default, because the default length limit is generous and any longer
text is unlikely to be sent for translation intentionally. My personal
preference for the input phrase length limit is 100 symbols.
ArticleView::pasteTriggered() didn't call QString::simplified() on the
text retrieved from the clipboard. I assumed this was an oversight, so
now it *is* called - indirectly, via Preferences::sanitizeInputPhrase().
There is a regression since Qt 5.12.1 that forces the pinned scan popup
window to be always on top of the main window on Linux/X11 because of
its Qt::Dialog window flag. The same issue is present in Qt 4.
The Qt regression is reported as QTBUG-74309, but chances of it being
fixed any time soon seem slim.
The documentation for Qt::Dialog window flag states that it causes a
window to be decorated as a dialog (typically no maximize or minimize
buttons in the title bar). I suppose adding these buttons to
the scan popup's title bar is not an issue.
As a bonus, the Qt::Dialog flag prevented scan popup window tiling when
moving toward the screen edge in Xfce. It works perfectly now.
Before this commit, when group combobox was visible, the Alt+- shortcut
reduced the heights of group combobox and translate line in the main
window, but not in scan popup. These UI elements in scan popup did not
become lower than at the time scan popup was constructed.
Applying the solution from the main window fixes this bug (#1108).
Before this change ScanPopup::applyWordsZoomLevel() was called before
the primary connection to ScanPopup::currentGroupChanged() in
ScanPopup's constructor. This meant that disconnect() had no effect and
connect() established the first connection during the first call to
ScanPopup::applyWordsZoomLevel(). This caused 2 issues:
1. Since the connection happened before the filling of ui.groupList
in ScanPopup's constructor, the current group in scan popup was always
"All" on Goldendict start.
2. Since the connection was not unique, the slot was connected twice
to the same signal, and it was actually called twice.
The bug was introduced in 92e8c85eec.
The article view focus is necessary to navigate a word definition via
keyboard rather than mouse. The shortcut - Ctrl+N - is the same as
the one in the main window for the corresponding action.
When scan popup is configured to appear without any key modifiers
pressed and is active on X11, it interferes with selecting text inside
the scan popup window (or inside the main window if "Send translated
word to main window" option is enabled). It also makes searching text
inside article definition impossible - in the main window and
even more so in the scan popup window.
However, when scan popup is configured to appear only when some keys are
pressed, or when the scan flag feature is enabled, it may work fine
inside Goldendict windows.
It is possible to automatically decide whether to show scan popup when
selection or clipboard inside Goldendict changes. But such logic might
be unsuitable for some use cases. For example, invoking scan popup by
selecting article definition text in the main window works fine.
Therefore this commit makes ignoring selection and clipboard changes
inside Goldendict itself optional. This commit implements one of two
feature requests in issue #606.
This new option could have effect on non-X11 platforms if the hidden
trackClipboardChanges option is enabled. But it is much less useful on
these platforms because scan popup without key modifiers is unusable
there (at least under Windows). Let us show and use the option only on
X11 to avoid cluttering Preferences UI on other platforms.
My tests in many desktop environments and window managers indicate that
no single configuration works perfectly in all environments. There are
also behavior differences between Qt::Popup and Qt::Tool flags, which
are not exactly bugs, so I suppose users might subjectively prefer
different options.
Customizing the flags allows the user to prevent unpinned scan popup
window flickering with Qt5 on Linux. In a way adding these options fixes
issue #645, which is: the scan popup window blinks rapidly, barely
noticeably in some applications, such as Calibre ebook-viewer
and Chromium. In this case the scan popup window usually ends up hidden
when selection ends, unless it was finished with a jerk.
I have tested the new options in 9 desktop environments and window
managers: at least one configuration for each eliminates #645 and makes
the scan popup window work the same as with Qt4 in this regard:
the popup window remains visible, text in the popup's translation line
keeps up with the text selection in the external application,
and the selected text is being translated on the fly.
Moreover, for each tested DE/WM, at least one configuration makes
the scan popup window work perfectly as far as I am concerned.
This issue was partially worked around with a 200ms scan popup delay
timer in the recent commit 58e41fe3ce
for the duplicate issue #854. However the timer solution is incomplete
because it requires the user to select text quickly and without delays.
If global mouse selection does not change for 200ms while the left mouse
button is held down, the user will likely not see the scan popup when
(s)he finishes selection, and will have to try selecting again -
hopefully faster this time.
The 200ms delay is no longer critically important after this commit,
but it is still beneficial: the lookup query changes less often,
which in turn reduces article definition update frequency.
So the delay improves the UI (perhaps subjectively) and performance.
I have verified in numerous desktop environments and window managers
that the workaround does not work with Qt5.
Let us disable it in Qt5 builds to prevent potential issues
and eliminate the small performance overhead.
* add a new interface class AudioPlayerInterface;
* inherit a new proxy class Ffmpeg::AudioPlayer from it;
* partially switch ArlticleView to using the interface;
* expose MainWindow's AudioPlayerInterface instance to all ArticleView
instances;
* add a new AudioPlayerFactory class responsible for creating instances
of concrete classes derived from AudioPlayerInterface depending on
relevant Config::Preferences values;
* increase minimum supported Qt version from 4.5 to 4.6 in README
in order to use QScopedPointer introduced in Qt 4.6.
Controls both context menus, in the dictionary bar and in the article view.
Can be adjusted in Preferences -> Interface -> Context menu dictionaries limit.
By default, it is set to 20.
