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
