Summary: | Color popovers in Area dialog are cutoff, overflow out of display (GTK, Wayland) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Stéphane Guillou (stragu) <stephane.guillou> |
Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | normal | CC: | armlopez, caolan.mcnamara, ilmari.lauhakangas |
Priority: | medium | Keywords: | bibisected, bisected |
Version: | 7.3.0.0.alpha1+ | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=152438 https://bugs.documentfoundation.org/show_bug.cgi?id=153885 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 100156, 103182, 103223 | ||
Attachments: | screenshot of issue |
Description
Stéphane Guillou (stragu)
2024-04-15 14:41:46 UTC
I was unable to replicate this behavior in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded or Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded In both versions, the box opened upwards rather than downwards. There is no great solution in the sense that under wayland you don't really know the position of the toplevel application window on screen. If you take the position of the menubutton within the dialog as an indicator that those at the top half drop down and those at the top half drop up then this example might look better, but format watermark which is generally small enough to fit the drop down over its parent would then drop up and look weird. Maybe we could consider the size of the dialog, and its position relative to the toplevel application frame and the size of that and then fit the calculated popover size against those to see which side is the best fit (In reply to Caolán McNamara from comment #2) > There is no great solution in the sense that under wayland you don't really > know the position of the toplevel application window on screen. Seems like this protocol would solve it: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/156 From a comment: "this is just telling the compositor where a representation of a toplevel is located (e.g. button in a panel)". |