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.
Preferences::sanitizeInputPhrase() transforms an input phrase by
removing its whitespace/punctuation prefix and suffix. Translating a
phrase from X11 primary selection or from clipboard, via mouse-over or
from the command line results in such sanitization. This is useful when
a punctuation mark or a space is selected accidentally alongside a word.
This sanitization can be undesirable, however, when an abbreviated word
is selected. For example: "etc.", "e.g.", "i.e.".
This commit implements searching for the input word with the punctuation
suffix preserved as an alternative form of the sanitized word to show
articles for both. For example, when the word "etc." is translated from
the clipboard, both "ETC" and "etc." articles are displayed.
The punctuation suffix is preserved when the word is passed from the
scan popup to the main window and when the translate line text is
refreshed (e.g. when the current group is changed). The suffix is not
stored in history and favorites (doing so would require file format
changes and possibly substantial code changes, this can be implemented
later if need be).
Trim the input phrase once in ArticleNetworkAccessManager::getResource()
instead of verbose trimming in multiple places in
ArticleMaker::makeDefinitionFor().
Closes #1350.
For example, the first audio link in "The United States" English
Wikipedia article - "The Star-Spangled Banner" - ends with ".oga".
Without this commit the audio link is not recognized by GoldenDict:
* it is not pronounced when a Preferences=>Audio=>"Auto-pronounce..."
option is enabled;
* clicking on the link opens it in the default browser instead of
playing inside GoldenDict.
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().
External and internal audio players work similarly now. Fixes #950.
* inherit a new ExternalAudioPlayer class from AudioPlayerInterface;
* use an existing ExternalViewer class to implement ExternalAudioPlayer;
* take (const char *, int) instead of std::vector<char> in
ExternalViewer constructor to fit into AudioPlayerInterface;
* extend ExternalViewer API to let ExternalAudioPlayer stop superseded
audio player processes;
* make AudioPlayerInterface::play() return an error message string to
allow reporting immediate failures from derived classes;
* Document AudioPlayerInterface API;
* Document AudioPlayerFactory::player();
* use the common audio interface exclusively in ArticleView.
* 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.
Internal links in MediaWiki articles don't lead to word definitions,
so the "Definition: " prefix is not correct for them. It also does not
provide any information and is largely useless.
Perhaps the actual footnote text should be displayed in the tooltip,
but this requires distinguishing them from citations/references and
backlinks.
This forces the jump even when the dictionary is already a current/active dictionary.
This is convenient for the following use-cases:
1. User manually scrolls far away from the current dictionary and would like to return.
2. User jumps far away from the current dictionary when doing search (Ctrl+F).
3. User scrolls a huge article and would like to get back to the beginning of it.
