Before: Construst Scanpopup only when both enableClipboardHotkey and enableScanPopup are true
Now: Always construct ScanPopup so that users can freely enable Copy->ScanPopup through navbar or tray
* 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
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.
