Calling dialog.showMaximized() before dialog.exec() doesn't work as
intended under KDE Plasma and Xfce. In both desktop environments the
Print Preview dialog ends up modeless - the user can interact with the
main window while the dialog is visible. Such a behavior is surprising
to developers, because QDialog::exec() should show the dialog as modal.
In addition, under Xfce the dialog is not maximized, but very small and
also frameless => neither movable nor resizable.
b13b808edf inserted the line
`dialog.showMaximized();` to work around tiny print preview window,
which confirms that the side effects described above are unintentional.
These maximizing issues could be fixed by passing
Qt::CustomizeWindowHint | Qt::WindowMaximizeButtonHint | Qt::WindowCloseButtonHint
as window flags to QPrintPreviewDialog's constructor and replacing the
line `dialog.showMaximized();` with
`dialog.setWindowState( dialog.windowState() | Qt::WindowMaximized );`.
However, saving and restoring the dialog's geometry allows customization
and thus improves usability. This is how more frequently used dialogs
behave in GoldenDict.
Customize the dialog's window flags to show a maximize button.
Maximizing could be useful on a small screen. This also makes restoring
the old appearance on systems, where it worked correctly, easy to the
user: maximize the dialog once and it appears maximized henceforth
(until the user unmaximizes it back). Use the same window flags as in
EditDictionaries dialog - I haven't noticed any complaints since they
were introduced more than a year ago.
Accepting changes in Preferences dialog no longer disables two options
"Ignore words order" and "Ignore diacritics", which are configurable in
Full-text search dialog.
cb6b00d85e set .gdarticle background to
`#fefdeb` in article-style.css, but failed to override it in
article-style-print.css.
Set html background to white as well in order to prevent a thin border
around articles' contents if non-printing article styles set html
background to a color other than white.
Printing color background makes little sense and is wasteful. Users who
prefer the old behavior can override the background color in
<Configuration Folder>/article-style-print.css.
Use `background` rather than `background-color` CSS property in order to
overwrite any background image set by non-printing article styles.
When Search Pane is hidden, Words Zoom level is large and GoldenDict
main window's width is small, translateBoxWidget does not fit into the
toolbar and is hidden behind the toolbar extension button » on the right
side. Reducing Words Zoom level does not automatically make
translateBoxWidget visible until the user presses the toolbar extension
button or types text to be translated.
I haven't noticed any effect of the existing line of code that activates
groupList parent widget's layout whether Search Pane is visible or
hidden. This line was introduced in the commit that implemented
TranslateBox - da13998518. In this initial
implementation navToolbar was the parent of groupList, and
translateBoxWidget did not yet exist. I think that the introduction of
translateBoxWidget in 404a16442b obsoleted
this line of code, and so remove it here.
I have verified that this fix works as intended in the Qt 4 and the Qt 5
version both under KDE Plasma and Xfce.
When the last tab is closed while the article view in it has focus,
Results Navigation Pane acquires focus in the Qt 4 version. This is OK,
because typed text is sent to the translate line and all shortcuts work.
In the Qt 5 version, depending on the value of the "Hide single tab"
option, either no widget has focus or the tab bar acquires focus in this
situation. This leads to issues described in the added comment.
Focus is already transferred to GoldenDict in toggleMainWindow() only
the first time the main window is shown. At all subsequent requests to
show the main window, focus has to be forced with the workaround.
Checking focus asynchronously allows to resort to the workaround less
often.
Under Xfce: the timeout of 0 ms is almost always sufficient in the Qt 5
version, but is never enough in the Qt 4 version. The timeout of 4 ms is
always sufficient in both versions.
Under KDE Plasma: the timeout of 0 ms is rarely sufficient in the Qt 5
version. Unfortunately, with any timeout other than 0 ms, the Qt 5
version does not always get focus, which would be a serious regression,
so no other timeout can be used. The Qt 4 version does not always get
focus both with and without the timeout.
translateLine->internalWinId() always equals 0. When the show/hide main
window hotkey is triggered right after GoldenDict starts to system tray,
`wh` equals MainWindow::internalWinId(). A few more experiments confirm
that XGetInputFocus()'s output parameter `focus_return` is an ID of a
top-level window, not of an embedded widget child.
Limiting input phrase length is disabled by default. The default length
limit value is 1000. The user has to enable the option and lower the
length limit in order to be surprised by missing translation. By making
such configuration changes, the user should become aware of this feature
and its effect.
As the person who has implemented this feature and uses 100 as the
length limit, I am never surprised or disappointed by missing
translation. The only annoyance is this warning that floods my systemd
journal. Apparently I accidentally select overly long phrases way too
often.
According to DSL documentation, closing the [mN] tags is optional:
unclosed [mN] tags affect formatting until the end of a card.
As many dictionaries don't close the [mN] tags, GoldenDict printed
multiple unclosed-tag warnings during each word lookup.
