No minimize and maximize buttons on a window bar on the latest pyface and linux

[bebaek]

This happens only for my ubuntu 20.04 laptop. Windows VM is fine. Also internal custom app is fine.

The problematic environment has: CPython 3.6.12+2, pyface 7.1.0-1, traitsui 7.1.0-1. Another environment with older runtime/packages seem fine though I didn't test extensively.

Test code:

from traits.api import *
from traitsui.api import *

class Foo(HasTraits):
    bar = Str()

    def default_traits_view(self):
        return View(
            Item('bar'),
            width=400,
            height=400,
            resizable=True,
        )

Foo().configure_traits()

[corranwebster]

This is indeed odd. Which Qt version are you using?

[kitchoi]

I could reproduce this on a Linux machine, and after falling back to traitsui 7.0.1 and pyface 7.0.1, the behaviour still persists, so at least this is not a regression from Pyface/TraitsUI 7.0.1 to 7.1.0

[kitchoi]

The dependencies I used:

Package    Version
---------- -------
pip        19.2.3 
pyface     7.0.1  
Pygments   2.7.2  
PySide2    5.15.1 
setuptools 41.2.0 
shiboken2  5.15.1 
traits     6.1.1  
traitsui   7.0.1

This is on Python 3.8 and Linux.

[bebaek]

This is indeed odd. Which Qt version are you using?

qt 5.12.6-6

I see things are fine in our previous dev env with: cpython 3.6.0+12, qt 5.12.6-5, pyface 7.0.1-2, traitsui 7.0.1-2

[bebaek]

I could reproduce this on a Linux machine, and after falling back to traitsui 7.0.1 and pyface 7.0.1, the behaviour still persists, so at least this is not a regression from Pyface/TraitsUI 7.0.1 to 7.1.0

Somehow, that downgrade to 7.0.1 worked for me.

[kitchoi]

Thanks @bebaek

This is really bizarre. Now I try a Ubuntu 16 (Xenial) VM, and I could not reproduce:

$ edm install traitsui pyqt5
$ python scripts/pyface-802.py

(The script contains the code snippet from this issue)

And I see this:

I wonder if there are other parameters we are overlooking?

Packages:

appdirs            1.4.3-1   enthought/free
distribute_remove  1.0.0-4   enthought/free
freetype           2.10.0-6  enthought/free
harfbuzz           2.6.4-4   enthought/free
icu4c              50.2-2    enthought/free
libjpeg            7.0-5     enthought/free
libpng             1.6.36-5  enthought/free
libxkbcommon       0.9.1-3   enthought/free
libxml2            2.9.7-1   enthought/free
packaging          16.8-4    enthought/free
pip                20.0.2-2  enthought/free
pyface             7.1.0-1   enthought/free
pygments           2.2.0-1   enthought/free
pyparsing          2.2.0-1   enthought/free
pyqt5              5.14.2-3  enthought/free
pyqt5_sip          12.7.2-1  enthought/free
qt                 5.12.6-6  enthought/free
setuptools         41.6.0-4  enthought/free
six                1.15.0-1  enthought/free
traits             6.1.1-1   enthought/free
traitsui           7.1.0-1   enthought/free

I have also exported the EDM environment I used here: edm.bundle.txt

[kitchoi]

Ah the Ubuntu version I used ~is 18~ (edited: was 16), but the issue is observed on Ubuntu 20. I will try again.

[kitchoi]

Upon trying a Ubuntu 18 VM, I am now able to reproduce.

[kitchoi]

I think I could narrow this down to this change in https://github.com/enthought/traitsui/pull/1083

Unfortunately, reverting it will change behaviour for CentOS Linux in another undesirable way, reopening https://github.com/enthought/traitsui/issues/1078 Essentially, we are facing this X11 Peculiarities noted in Qt documentation: https://doc.qt.io/qt-5/application-windows.html#x11-peculiarities

X11 Peculiarities On X11, a window does not have a frame until the window manager decorates it. This happens asynchronously at some point in time after calling QWidget::show() and the first paint event the window receives, or it does not happen at all. Bear in mind that X11 is policy-free (others call it flexible). Thus you cannot make any safe assumption about the decoration frame your window will get. Basic rule: There's always one user who uses a window manager that breaks your assumption, and who will complain to you.

Furthermore, a toolkit cannot simply place windows on the screen. All Qt can do is to send certain hints to the window manager. The window manager, a separate process, may either obey, ignore or misunderstand them. Due to the partially unclear Inter-Client Communication Conventions Manual (ICCCM), window placement is handled quite differently in existing window managers.

[kitchoi]

On the same Ubuntu VM where I could reproduce the issue, I could switch the desktop environment from Ubuntu to LXDE:

And there the WindowMinimizeButtonHint and WindowMaximizeButtonHint are respected such that the maximize and minimize buttons are shown (see code), and the window can be maximized to fill up the screen.

[kitchoi]

In https://github.com/enthought/pyface/issues/802#issuecomment-726720356

I could reproduce this on a Linux machine, and after falling back to traitsui 7.0.1 and pyface 7.0.1, the behaviour still persists, so at least this is not a regression from Pyface/TraitsUI 7.0.1 to 7.1.0

The Linux machine I tried then was a CentOS... whose window manager does not actually do minimize or maximize buttons, I jumped into conclusions. In that particular window manager, the maximize action is achieved by double clicking the window frame. And I can confirm that on Pyface/TraitsUI 7.0.1, such a window can be maximized by double clicking on CentOS, but not any more with Pyface/TraitsUI 7.1.0.