Change Dialog flag to Window to allow minimize/maximize buttons to be shown

[kitchoi]

Fixes enthought/pyface#802
This is an alternative fix to #1078, i.e. it overrides #1083 partially.

This PR:

• Change the Qt StickyDialog window flag from Dialog to Window. The StickyDialog is the main widget used when configure_traits or edit_traits are called with default settings.

With this, the only difference compared to TraitsUI 7.0.1 is that when resizable is false, the window flag is Qt.Window | QtCore.Qt.WindowSystemMenuHint instead of Qt.Dialog | QtCore.Qt.WindowSystemMenuHint. Before this change, the dialog may not have minimize/maximize buttons in some window managers.

In this part of the code base, there is in fact no information as to whether the window is intended to be top-level or a secondary window. I'd not be surprised if this then brings about other undesirable changes to the visuals on yet another desktop environment, or when one actually wants a secondary dialog-looking window and did so by setting resizable to false. In that case, we shall look into allowing additional information to be passed via edit_traits to select the appropriate setup based on more specific contextual information.

Details:
The issue in #1078 was observed where the first window has a Qt.Dialog flag (because it is not resizable) but the new window has a Qt.Window flag (because it is resizable). This was the original code:

traitsui/traitsui/qt4/ui_base.py

Lines 131 to 134 in c4ee6fd

	if ui.view.resizable:
	flags = QtCore.Qt.Window
	else:
	flags = QtCore.Qt.Dialog | QtCore.Qt.WindowSystemMenuHint

In retrospect, #1083 fixed #1078 by making both windows to have the same flag (out of Dialog or Window flag). CentOS window manager may have decided that "Dialog" should always be on top of "Window" (this is a guess).

Whether the window is actually resizable is handled by the subsequent call to setSizeConstraint(QtGui.QLayout.SetFixedSize), the Window and Dialog flags do not change that. However, a window manager may decorate the window frame differently based on these flags. In Ubuntu default desktop environment, it ignores the subsequent WindowMinimizeButtonHint and WindowMaximizeButtonHint flags if the Dialog flag is active. In CentOS, it similarly excludes the capability to maximize the window by double clicking the frame. Yet some X11 desktop environments (e.g. LXDE) respect these resize button hints and provide the buttons despite the Dialog flag.

On Windows, none of the above had any noticeable effect: Both WindowMinimizeButtonHint and WindowMaximizeButtonHint are respected such that the window can be maximized or minimized.

On OSX, when the Dialog flag is used, the minimize button is disabled, but the maximize button can still be used.

Screenshots for #1078 on Windows with this branch

(Windows has not been affected on #1078 to start with, and is not affected by #1083 nor changes in this PR)

Screenshots for #1078 on MacOSX with this branch

Screenshots for #1078 on MacOSX with master

(Note that the minimize button is disabled.)

Screenshots for #1078 on Ubuntu 18 with this branch

Screenshots for #1078 on Ubuntu 18 on master

(Note the minimize and maximize buttons are not there.)

Understandably, no self-checking tests can be written for this.

[corranwebster]

In this part of the code base, there is in fact no information as to whether the window is intended to be top-level or a secondary window.

I think you can infer this from parent attribute passed into _StickyDialog.init(). If parent is None then this is a top-level window; if parent is anything else, then this window is a secondary window and so we can use this to determine whether it needs to be shown on top of another window and adapt appropriately. But this may be orthogonal to this PR.

[kitchoi]

I think you can infer this from parent attribute passed into _StickyDialog.init(). If parent is None then this is a top-level window; if parent is anything else, then this window is a secondary window and so we can use this to determine whether it needs to be shown on top of another window and adapt appropriately. But this may be orthogonal to this PR.

Thank you!

I realize I might have used the wrong vocabulary here trying to distinguish "top-level" versus "secondary". Sorry about that. Dialog is also a top-level window. I think I should have said is that there is no information as to whether the window is intended to be decorated like a main application window that is more standalone or a dialog intended for small tasks. I guess this is perhaps where window managers apply different interpretations as to what a dialog should look and behave compared to just a window.

[corranwebster]

Ah, OK, that's a but different from what I thought you were saying. Other than erring on the side of assuming that things are decorated as a mainwindow, that sort of intention is hard to get out of TraitsUI. I guess if the window is modal, then it is intended to be short-lived and secondary, but there are non-modal windows that can also be intended that way (eg. a non-model search dialog).

[kitchoi]

Agreed. Thank you.

As an attempt to make sure #1078 has not come back, here is the screenshot for CentOS 8.2 default desktop environment:

Two points to note here for CentOS: (1) The second window is still open on top of the first one (the point of #1078) and (2) one can now double click the second window to maximize the window.