When translate line is wider than 1000 pixels, its right end is not
aligned with its completion list. This looks ugly and complicates
scrolling through completions after clicking on Drop-down arrow.
For example, looking up "United States" in my local dictionaries, then
pressing Ctrl++ to increase zoom factor from 1 to 5 takes 4 seconds with
this change and 25 seconds without it. The same scaling takes 6 seconds
with this change and 45 seconds without when I enable English Wikipedia,
which has a particularly large "United States" article.
There is a workaround that speeds up zooming: look up a nonexistent
word, scale to the desired level, then go back to the large articles.
But this is tedious if large articles are open in scan popup or
in case of many tabs in the main window.
Let us use consistent horizontal size policies in scan popup's and main
window's GroupComboBox and TranslateBox. MinimumExpanding in scan
popup's TranslateBox allows it to stretch horizontally along with
horizontalSpacer when the width of popup window increases.
Before this commit, the Alt+- shortcut reduced the heights of group
comboboxes in the main window and scan popup, but not their widths.
These comboboxes did not become narrower than at the time of their
construction.
Fixing the height of a group combobox to that of a line edit in
MainWindow's and ScanPopup's eventFilter() is still useful after this
commit - to avoid the ugliness of a few pixels-higher combobox.
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).
* #undef Bool with Qt4 as well as with Qt5.
* #undef min, #undef max from <X11/Xlibint.h>.
* #include <fixx11h.h> just after hotkeywrapper.hh. Unfortunately this
header can not be included in hotkeywrapper.hh directly because
some of the undef-ed words are actually used in hotkeywrapper.cc.
* #include <fixx11h.h> after <X11/Xlib.h> in mainwindow.cc just in case
hotkeywrapper.hh stops including this Xlib.h header in the future.
These changes should make future compilation errors less likely.
For example, without "#undef min" in hotkeywrapper.hh, including
<iomanip> in mainwindow.cc after the mainwindow.hh include resulted in
the following GCC 8 compilation error:
/usr/include/c++/8.2.1/bits/locale_facets_nonio.tcc:945:22:
error: expected unqualified-id before ‘(’ token
__minlen = std::min(__minlen,
^~~
Before this change ScanPopup::applyWordsZoomLevel() was called before
the primary connection to ScanPopup::currentGroupChanged() in
ScanPopup's constructor. This meant that disconnect() had no effect and
connect() established the first connection during the first call to
ScanPopup::applyWordsZoomLevel(). This caused 2 issues:
1. Since the connection happened before the filling of ui.groupList
in ScanPopup's constructor, the current group in scan popup was always
"All" on Goldendict start.
2. Since the connection was not unique, the slot was connected twice
to the same signal, and it was actually called twice.
The bug was introduced in 92e8c85eec.
Executable icon could be a security risk. Closes #823.
This commit eliminates one of the 2 non-critical "make install" errors
described in #1001. Fixing the other error requires removing executable
bit from goldendict.desktop, which may cause issues to some users.
Examples of code that could access the destroyed log file object:
* a destructor of a local object declared before logFile in main();
* a destructor of a global object;
* termHandler() invoked after logFile was destroyed either normally
or because of an uncaught exception.