View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016915 | Scribus | User Interface | public | 2023-03-22 01:02 | 2023-03-23 19:29 |
Reporter | Portreve | Assigned To | jghali | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Product Version | 1.5.8 | ||||
Summary | 0016915: Palette windows (Properties, Content Properties, Alignment, etc.) will not dock to Scribus window in a Wayland session | ||||
Description | When one summons palette windows (Properties, Content Properties, etc.) they will not dock to the main Scribus workspace window in Gnome 3.x or KDE (at least 5.x, maybe earlier) when the user is logged in using a Wayland session. Everything works perfectly if logged in using an Xorg or X11 session. Expected Behavior: Open one of the secondary (palette) windows, such as Properties, and drag it either to the left or right edge of the Scribus workspace window. Condition 1: Non-full-screen Scribus workspace window - an animation happens showing the palette is about to become docked to the side, and when the user lets go of the mouse button in that state, the palette window becomes a tabbed, docked palette. Condition 2: Full-screen (maximized) workspace window - same as Condition 1. Actual Behavior: Open one of the secondary (palette) windows, such as Properties, and drag it either to the left or right edge of the Scribus workspace window. Condition 1: Non-full-screen Scribus workspace window - dragging the palette to the edge is not detected (or it is ignored) by Scribus and nothing happens. Condition 2: Full-screen (maximized) workspace window - dragging the palette to the edge is still not detected by Scribus, and then the desktop environment will try to resize the window to take up the right (or left) approximately 1/3 to 1/2 of the desktop. | ||||
Steps To Reproduce | 0. The specific distro does not matter (this behavior is expressed in any Wayland-including distro, particularly openSUSE Leap 15.x and concurrent Tumbleweed releases, and Fedora Workstation 30 series, and in particular 34, 35, 36, and 37) 1. Begin a Wayland session of Gnome 3.x or KDE 5.x. 2. Open Scribus. 3. Open Properties and/or any other sub- or palette window. 4. Drag the window to either the left or right edge of the Scribus workspace (primary) window. | ||||
Additional Information | Assume the user has previously docked the palette(s) of their choice and is now running a Wayland session. The already-docked palettes will remain so and function as one would expect. However, if the user closes any or all of them or attempts to drag-relocate any or all of them, the moment they undock and become independent palette sub-windows, they can not be re-docked without logging out, logging back in under X11/Xorg, re-docking them, logging back out, and logging back in a Wayland session. | ||||
Tags | content properties palette, palette docking, properties palette, wayland | ||||
Patch | No | ||||
|
Known issue and unfortunately there is nothing we can do on our side. This is dependent of Wayland and Qt: https://bugreports.qt.io/browse/QTBUG-87332 Under Wayland, you will also notice that palettes have trouble remembering their position when closing/opening them or between sessions. The responsible here is Wayland because Wayland developers have decided to decide windows positions instead of letting applications do it. |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-03-22 01:02 | Portreve | New Issue | |
2023-03-22 01:02 | Portreve | Tag Attached: content properties palette | |
2023-03-22 01:02 | Portreve | Tag Attached: palette docking | |
2023-03-22 01:02 | Portreve | Tag Attached: properties palette | |
2023-03-22 01:02 | Portreve | Tag Attached: wayland | |
2023-03-22 19:37 | jghali | Assigned To | => jghali |
2023-03-22 19:37 | jghali | Status | new => resolved |
2023-03-22 19:37 | jghali | Resolution | open => not fixable |
2023-03-22 19:37 | jghali | Note Added: 0050043 | |
2023-03-23 19:29 | jghali | Status | resolved => closed |