When a user clicks on a link in a dictionary or requests translation of
a word by double-clicking or translates selection via the context menu,
at first the article from the highest-priority dictionary is at the top.
Then, after approximately one second, the article from the dictionary,
out of which the translation was requested, becomes current and the view
scrolls down to this article placing it on top, hiding articles from the
dictionaries above it.
Such application behavior is inconvenient in some workflows so that the
user manually navigates to the top dictionary translation when this
automatic scrolling happens.
For example: a user has English->Russian dictionaries and
English->English dictionaries. The English->Russian dictionaries are
higher up in the dictionary order because they provide easier/faster to
understand translations. Some rare words and phrases are missing from
the English->Russian dictionaries however. Thus the user occasionally
reads the English explanation of a word/phrase. When the user
double-clicks on a word or follows a link in the English->English
dictionary article, she would rather see translations from the
preferable English->Russian dictionaries.
The new option allows to disable automatic scrolling and ensure that
articles from higher-priority dictionaries are visible. The option
doesn't affect backward/forward navigation via arrow buttons or
Alt+Arrow shortcuts: these still scroll to the stored vertical position
among articles. This remaining automatic scrolling happens much faster,
is not a problem for the described use case and hopefully for other use
cases.
Those who use GoldenDict to translate long text with Google Translate
or pronounce it with a text-to-speech engine (see a discussion in
comments under #1313) may still want to limit the input phrase length.
But they might prefer a limit greater than the current maximum - ten
thousand symbols. Ten million minus one symbols should be generous
enough. I don't want to increase the maximum further to avoid excessive
widening of spinboxes in the Preferences UI. Besides, a ten megabyte
input phrase freezes GoldenDict's UI with high CPU usage for a minute on
my system.
This speeds up decreasing the default value that is probably too large
for most users. I think that very few users would want to tune this
option's value finer than 10. Those who need such precision can enter
the desired number manually.
When a Wikipedia article is already cached, this change reduces the
amount of sent and received network data almost tenfold.
Setting up a network disk cache in the same way for dictNetMgr does not
noticeably impact the amount of network traffic. Either this network
access manager sends and receives very little data or the data is never
the same. So dictNetMgr does not need a disk cache.
Use QNetworkDiskCache's default maximum size of 50 MiB as the default
network cache size. This size is large enough to accommodate tens of
huge MediaWiki articles. It is also small enough that the user is
unlikely to run out of disk space because of the cache.
Clear network cache on exit by default because most users probably
don't load the same online articles after restarting GoldenDict. Plus
storing the network cache on disk indefinitely by default would be a new
and unexpected to the users privacy risk.
Nikita Moor came up with the idea and wrote an initial network disk
cache implementation in #1310.
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().
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.
This option has effect even when scan popup functionality is disabled -
when the Ctrl+C+C hotkey is triggered. So the scanToMainWindow checkbox
should not be disabled when enableScanPopup is unchecked. Fixes #716.
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.
* add config and GUI support for internal player back end switching;
* make FFmpeg player disabling option consistent with other similar
qmake options by using CONFIG;
* add a new qmake option that disables Qt Multimedia player. This is
useful for GNU/Linux distributions where Qt WebKit and Qt Multimedia
packages depend on different GStreamer versions and don't work
correctly when combined in one application.
The existing FFmpeg+libao internal player back end has a relatively
low-level implementation, which is difficult to understand and improve.
There are at least 3 open internal player issues:
1) many GNU/Linux users have to edit their libao configuration file to
make Goldendict's internal player work (issue #412);
2) libao's pulseaudio plugin does not support 32-bit audio, which
means that many MediaWiki pronunciations don't work with the most
popular GNU/Linux audio driver (issue #949);
3) Ffmpeg::DecoderContext uses deprecated FFmpeg APIs, which causes
compiler warnings and means that this internal player back end
may not compile with a future FFmpeg library version (issue #978).
The Qt Multimedia back end implementation uses the highest-level
Qt audio API and is very simple.
This new back end works flawlessly on my GNU/Linux machine.
I'm not making it the default back end because I don't know how well
it will work on other platforms with different configurations.
