* There is no difference between those two on Windows and MacOS which only support clipboard (Ctrl+C) scanning
* Q_WS_X11 was defined on Qt4, and it causes the super weird trackClipboardChanges to occur on Windows
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.
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.
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).
