Messages printed with GD_DPRINTF() are clearly debug messages. They
flood GoldenDict's output with lines like these:
some body finished
one finished.
erasing..
erase done..
one not finished.
====reading 16384 bytes
Messages printed to stderr with GD_FDPRINTF() are more important and
less frequent => leave them in Release builds.
Users can enable or disable av_log() output only by inserting a call to
av_log_set_level() and recompiling GoldenDict. Blink browser engine
shipped with Qt WebEngine sets the log level to AV_LOG_QUIET in
chromium/media/base/media.cc and thus disables all output. So
GoldenDict's custom AV_LOG_INFO messages are always printed in the Qt
WebKit version and never in the Qt WebEngine version.
In contrast, users have many ways to enable or disable QDebug output
without recompilation since Qt 5. Furthermore, GoldenDict's command line
option --log-to-file allows to redirect gdDebug() output to a log file.
The two messages printed via av_log() are clearly debug messages,
because they are printed each time a word or a phrase is pronounced.
Unfortunately the X11 focus workaround that opens the File menu cannot
be simply removed. Without this workaround, when KDE Plasma's Focus
stealing prevention level is set to Low (which is the default) or
higher, launching a second GoldenDict instance doesn't give focus to the
already running instance unless that instance's main window is currently
hidden into system tray or minimized. A workaround of hiding then
showing the main window makes the window flicker. Suggesting GoldenDict
users to set the focus stealing prevention level to None is not right,
because this setting is global and affects all applications.
Emulate a left mouse button click at position (0, 0) instead of (1, 1)
in order to waste 1 rather than 2 pixels to the left of the menu bar.
Introduce a new macro X11_MAIN_WINDOW_FOCUS_WORKAROUNDS to link the X11
focus workaround to the File menu workaround introduced in this commit.
This simplifies disabling all related workarounds at once. When the
focus workaround is replaced with a proper solution, the developer won't
forget to remove all obsolete workarounds if they are linked together.
Fixes #781.
Now double-clicking an image has the same effect in the main window and
in the scan popup. This consistency in no way prevents or hinders using
the popup window as designed (for fast lookup in a small group of
dictionaries), because a user is unlikely to double-click an image
accidentally.
Without this commit, when "Double-click translates the word clicked"
option is on, double-clicking an image in the scan popup translates
currently selected text if the selection is not empty.
Fixes #1279.
There is no benefit in storing the same pointer multiple times in
openedInspectors. This occurred when an article inspector window was
closed then shown again. When the tab corresponding to the duplicated
article inspector pointer was closed, ArticleInspector::beforeClosed()
erased only one pointer from openedInspectors. This left dangling
duplicate pointer(s) in the list and eventually caused a crash when
another inspector's showEvent() accessed a dangling pointer at
openedInspectors.front().
Silently ignore empty or whitespace-only translation requests. It should
be clear to most users why GoldenDict ignores them.
The translated word ends up as the "word" URL query item value, which is
trimmed in ArticleNetworkAccessManager::getResource(). So the added
trimming in MainWindow::translateInputFinished() should be fine.
When a trimmed translated word was empty, InputPhrase::isValid()
returned false, ArticleNetworkAccessManager::getResource() returned a
null pointer and ArticleNetworkAccessManager::createRequest() fell back
to QNetworkAccessManager::createRequest(), which:
* failed silently in the Qt 4 version;
* displayed the
Protocol "gdlookup" is unknown
Failed to load URL gdlookup://localhost?word= &group=4.
QtNetwork Error 301
error page in the Qt 5 version.
Fixes #1179.
An attempt to clone the git:// URL fails on my Manjaro GNU/Linux system
and produces the following output:
$ git clone git://github.com/goldendict/goldendict.git
Cloning into 'goldendict'...
fatal: unable to connect to github.com:
github.com[0: 140.82.121.4]: errno=Connection timed out
128✗
The GitHub UI offers the replacement https:// URL when the green Code
button in the GoldenDict repository is clicked.
Fixes #1561.
This commit fixes broken links in complete saved articles to files whose
names contain reserved characters. An HTML parser decodes a
percent-encoded URL before looking for the referenced file on disk. So
a file with a percent-encoded name cannot be found. Percent-encode only
the URL to fix the bug.
The old code works correctly in Qt 4.8.7. But in Qt 5.15.5
selectedFilter is never equal to either element of filters. So HTML Only
is saved no matter which option the user selects.
This information is going to be especially useful in the upcoming Qt
WebEngine version of GoldenDict. In the Qt WebEngine version only the
words equal to the last found result can be highlighted, not all FTS
matches as in the Qt WebKit version.
The assertion failure can be triggered by full-text-searching for a
common word, selecting a result with many large articles and quickly
selecting text in the first article while the page is still loading.
This reverts commit c936d03fa0.
A default-constructed QRegExp is passed to ArticleView::showDefinition()
when a user navigates from an FTS-result page by clicking a link or
double-clicking a word. QRegExp().pattern() returns an empty string,
which is stored in the "regexp" query item of an URL. When this URL is
loaded, ArticleView::loadFinished() calls highlightFTSResults(), which
then calls closeSearch(), performs multiple string and regular
expression operations and early-returns because the regular expression
pattern is empty. Returning earlier skips useless work in this case.
An alternative optimization is not calling highlightFTSResults() at all
when the regular expression is empty, but that would skip the
closeSearch() call and keep the FTS search frame visible on a page with
an empty regexp.
Since the update to FFmpeg 5.0, when FFmpeg+libao internal player is
selected, most sounds fail to be pronounced. Furthermore, each failed
pronunciation attempt increases GoldenDict's CPU usage. Finally,
GoldenDict continues to hang and utilize the CPU cores when the user
attempts to exit it.
The reason for the issue is: GoldenDict's readAudioData() returns 0 at
EOF but FFmpeg expects the callback to return AVERROR_EOF. As a result,
internal player's threads are busy calling readAudioData() indefinitely.
a606f27f4c
documented the expected return value of the read_packet callback.
252500a78f
removed the code that handled the deprecated 0 return value gracefully.
The relevant deprecation warning
"Invalid return value 0 for stream protocol" had been flooding
GoldenDict's output for years
Fixes #1489.
One issue with the current implementation is that a wrong-cased match
remains selected when the user checks the Case Sensitive checkbox.
Another issue is that the noResults property of searchText is not
updated right away, which means that searchText's background color
remains wrong until next search.
Handle toggling case sensitivity in the same way as editing the searched
text: restart search from the beginning of the page. This improves the
Search-in-page UI consistency.
The current article is saved to pages history user data before any
navigation to another page and before reloading the current page.
Therefore saving it each time the user activates an article is
redundant. This redundancy is not consistent, because when a user
activates an article by clicking on it, the current article changes in
the UI, but is not immediately saved in history as setCurrentArticle()
is not called. The inconsistent redundancy is a waste of CPU time and
can hide bugs.
This variable overrides history user data, which makes the current
article and position restoring code in ArticleView::loadFinished()
difficult to understand.
Encode the same logic in the history user data instead. This should make
the code more straightforward and less brittle in the face of changes.
MainWindow calls ArticleView::reload() when the group list is updated.
This updating may add/remove/reorder dictionaries in the active group.
MainWindow also calls ArticleView::reload() when the display or addon
style changes.
In both of the above scenarios uncontrolled jumps and current article
change can occur (see also the parent commit message).
Move setting articleToJump from above the only ArticleView's reload()
call into ArticleView::reload() itself.
When the first article in the list is current, expanding or collapsing
optional parts results in:
1) uncontrolled jumps due to the content height changes if the scroll
position is not (0, 0);
2) current article change if a non-first article is saved in history
user data (e.g. if a mouse click had made the first article active).
Treat the first current article in the same way as non-first ones.
This change also affects the case when the current article is not
present in the article list. If the current article is simply empty,
then there is no behavior change. If the current article is not empty,
it *must* be in the list, unless something else went wrong.
This way it is clearer that the pages history is updated just before
each navigation to a different page.
The call to ArticleView::saveHistoryUserData() now occurs slightly later
in ArticleView::showDefinition(). I don't think the intervening code can
affect the current article or window position. So the reordering most
likely does not affect application behavior.
Without the added saveHistoryUserData() call, returning back from the
enlarged picture page ("gdpicture") restores the current article and the
window position that were last saved. At this commit the "gdpicture"
behavior is consistent with regular links: returning back from the
enlarged picture page sets the article with the picture as current and
restores the window position at the time of the click on the picture.
https://doc.qt.io/archives/qt-5.5/qtwebkit-bridge.html#internet-security
Qt WebKit Bridge documentation recommends:
When exposing native objects to an open web environment, it is
important to understand the security implications. Think whether the
exposed object enables the web environment access things that
shouldn't be open, and whether the web content loaded by that web page
comes from a trusted source.
The author of Qt WebChannel has said the following in a talk that
introduced this Qt module (WebKit Bridge replacement for Qt WebEngine):
My suggestion here is to write dedicated QObjects with a slim, minimal
API that only have the signals and methods that you deem safe to be
used from the outside.
- see a comment under https://redirect.invidious.io/watch?v=KnvnTi6XafA
The default qmake build output is overly verbose. Adding the "silent"
switch to CONFIG makes it much more concise, comparable to default CMake
output. This way warnings and errors are much easier to find.
Adding CONFIG-=silent to the qmake command line doesn't restore the
verbosity because it is applied before the "CONFIG += silent" line in
goldendict.pro. Add a new CONFIG switch "verbose_build_output" to allow
increasing build log verbosity without editing goldendict.pro.
MainWindow::showTranslationFor() overloads disable the "Pronounce Word"
action, then call ArticleView::showDefinition(). And then immediately
update pronounce availability, Found in Dictionaries list, Back and
Forward buttons. Since ArticleView::showDefinition() loads the requested
page asynchronously, the previous page is still current. Therefore the
"Pronounce Word" action is immediately re-enabled (if the still-current
article has sounds), the other state updates have no effect whatsoever.
Once the new page is loaded, the state is updated again in
MainWindow::pageLoaded() - this time with the desired effect.
So the only effect of the state updates in
MainWindow::showTranslationFor() is to revert the intentional disabling
of the "Pronounce Word" action. Plus waste some CPU time. The
pronunciation-disabling behavior looks better to me and is consistent
with the scan popup's behavior (which immediately hides the
"Pronounce Word" button).
When the current article is set and the user expands or collapses
optional parts (e.g. via the Ctrl+* shortcut),
ArticleView::setCurrentArticle() is called twice from
ArticleView::loadFinished(). Furthermore, the window scroll position is
restored before the second jump. This is wasteful. Move the
higher-priority setCurrentArticle() call up and, if it succeeds, skip
the other call and the scrolling.
I have measured the time spent running the affected code fragment on my
GNU/Linux system before and at this commit. When the loaded articles are
not very large, the performance gain of this commit is only about 1 ms.
However, when one of the displayed articles was huge (the
"United States" English Wikipedia article), the time went from 120 ms to
5 ms.
The wall time of calls to ArticleView::highlightAllFtsOccurences() on my
GNU/Linux system before and at this commit:
allMatches.size() uniqueMatches.size() before(ms) at(ms)
79 1 277 4
98 1 380 4
267 1 16803 65
