pyface
pyface copied to clipboard
enthought
How can we set the position of a task window on screen?
By default, the task window is opened at the top-left corner of the screen. TaskWindowLayout.position seems to be relevant here - https://github.com/enthought/pyface/blob/7fe4ca7357986e25611151e1a70cc31efc6fd217/pyface/tasks/task_window_layout.py#L29-L30
But, TaskWindowLayout.position is not clearly documented and it is unclear how we can set the position of the task window on screen.
@nicolasap-dm please correct/update the issue title/description as you see fit.
The position trait of the layout is one way (you can also just set the position of the TaskWindow, which is inherited from the base Window class). Tasks memoizes the last position of the window and attempts to open at the same location next time the app opens.
The (-1, -1) position means "open wherever Qt and the window manager thinks is best", which varies from OS to OS. So behaviour differs from OS to OS (and even within different window managers on linux).
The issue that the user was experiencing was resolved in internal channels. It was that a particular Linux window manager was not doing quite what Qt expected in terms of window decorations and so the location was not correct. This is, unfortunately, expected behaviour: https://doc.qt.io/qt-5/application-windows.html#x11-peculiarities
Our issue was as Corran described, and we're not going to fix it at present.
Specifically, on Lubuntu 18.04 (DE: LXDE), a Tasks application was created on the top left corner and subsequently decorated with the OS-specific header, that ended up appearing outside the desktop area (on Gnome, instead, the header is taken into account correctly). Since dragging the header is required to move the window, the window was effectively stuck (workaround: Alt + Drag on any point of the window. After the first session, the memoization ensures the issue doesn't occur again).
Looking at how to solve the issue, I found the "position" trait mentioned in this issue description, but the documentation and the code didn't say much about the units and the expected behavior. It may make sense to specify that the tuple is passed directly to the backend.
