Most callers of these member functions should escape wildcard symbols in
the `text` argument. Yet nothing in the functions' signatures suggested
such escaping. With the added enum WildcardPolicy argument, the callers
are forced to decide whether or not the wildcards should be escaped.
When not-escaped wildcard symbols are placed in the translate box/line,
word completion can occupy the CPU for seconds. So it is safer to err on
the side of escaping than the other way around.
The missed unescaping in ScanPopup::translateInputFinished() was
inconsistent with the main window. It made escaping in the scan popup's
translate box unusable by attempting to translate e.g. "\*" verbatim.
This dialog can make use of extra horizontal space when there are many
groups, extra vertical space - when there are many dictionaries. Thus
maximizing Dictionaries dialog can be useful.
Currently Dictionaries dialog features the following window buttons in
the top right corner:
* Close button under Xfce on GNU/Linux;
* Context help, Minimize, Maximize and Close buttons under KDE Plasma on
GNU/Linux;
* Help, Close buttons on Windows (according to Internet screenshots).
With this commit the top-right corner window buttons become:
* Maximize and Close buttons under Xfce on GNU/Linux;
* Minimize, Maximize and Close buttons under KDE Plasma on GNU/Linux;
* disabled Minimize button; Maximize and Close buttons on Windows
(thanks to @nonwill for checking this).
I don't think that Minimize button is useful in this dialog. But it does
no harm, so I won't go out of my way to remove it on all platforms.
Interestingly, the Minimize button won't show up under Xfce even if
Qt::WindowMinimizeButtonHint is on. It is difficult if at all possible
to remove this button under KDE Plasma. Fortunately, the Minimize button
works well in this desktop environment: minimizing hides both the dialog
and the main window, unminimizing shows both windows.
@nonwill found that this button doesn't work well on Windows: minimizing
the dialog hides it, but keeps the main window visible with its input
still blocked by the hidden dialog. Therefore it is just as well that
the Minimize button is disabled on Windows.
I couldn't find a UI element in the Dictionaries dialog that features
context help. Therefore the Context help/Help (question mark) button
must be useless. So removing it is an extra benefit of this commit.
I cannot check which window buttons are visible with this commit on
macOS, but I expect them to include Maximize, Close buttons and be
acceptable overall.
Closes #1359.
The geometries of many GoldenDict's dialogs and windows are already
stored in config. Dictionaries dialog can make use of extra horizontal
space when there are many groups, extra vertical space - when there are
many dictionaries. A user can now resize this dialog to her liking once.
Duplicate articles can be shown when the alts collection is not empty
and a MediaWiki site redirects multiple words to a single page. The
alts collection can be populated when:
* option Preferences=>Advanced=>"Extra search via synonyms" is enabled;
* a Morphology dictionary is active;
* a translation of a phrase is requested in a way that makes GoldenDict
pass the input phrase to Preferences::sanitizeInputPhrase().
Steps to reproduce 1:
1. Create and switch to a dictionary group with (1) "English Wikipedia"
and (2) "English (US) Morphology" dictionaries in it.
2. Request a translation of the word "plays" (without quotes).
Steps to reproduce 2:
1. Create a dictionary group with "English Wiktionary" dictionary in it;
switch to this group in the scan popup window (or in the main window
if the Preferences=>Scan Popup=>"Send translated word to main window"
option is enabled).
2. Select the word "i.e." (without quotes) and press Ctrl+C+C (or
whatever hotkey is configured to translate a word from clipboard).
Each of the 3 removed history addition requests follows a call to
ArticleView::showDefinition() with the same phrase/word as an argument.
Each showDefinition() overload adds its phrase/word argument to history.
These duplicate history additions weren't noticeable because
History::addItem() searches for and removes its argument from items to
avoid duplicate history entries. But the extra function calls, signal
emissions, linear searches and QList manipulation wasted processor time.
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.
I have searched for the "<button" string and even for the "<\s*button"
pattern in tens of articles from all 5 default Wikipedia and all 5
default Wiktionary sites. Found none. I assume this pattern is obsolete.
Removing this useless code improves performance by doing less searching.
I have run the following command on directories that contained many
Wikipedia and Wiktionary articles received by GoldenDict:
pcregrep -MrI --buffer-size 20M '<\s*button' DIR-WITH-ARTICLES
This string replacement is 3-5 times faster than the QRegularExpression
replacement in "The United States" and "Paris" English Wikipedia
articles on my GNU/Linux system.
Before fe39fc8a05 the pattern started with
"<a\\shref=" instead of the current "<a\\s+href=", and no related bug
has been reported. I haven't encountered any whitespace character other
than space in this position. I believe that a single tab or a single EOL
character do not make sense after "<a". So a regression is unlikely.
I have searched for a tab or a newline character after "<a" and for a
whitespace character after "<a " in tens of articles from all 5 default
Wikipedia and all 5 default Wiktionary sites. Found none.
I have run the following command on directories that contained many
Wikipedia and Wiktionary articles received by GoldenDict:
pcregrep -MrI --buffer-size 20M "$PATTERN" DIR-WITH-ARTICLES
with PATTERN='<a(\t|\n)' and PATTERN='<a \s+href'.
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.
