[Libreoffice-bugs] [Bug 153920] Windows not opening in default / primary monitor
https://bugs.documentfoundation.org/show_bug.cgi?id=153920 Stéphane Guillou (stragu) changed: What|Removed |Added CC||stephane.guillou@libreoffic ||e.org --- Comment #2 from Stéphane Guillou (stragu) --- I could not reproduce, from LO 7.2 through 7.5.1.2 to a recent trunk build. Splash screen and window open on the main display if the pointer is there too. However, when the main monitor is on the left, I can often see the LO splash screen pop up on the right screen even though the window opens on the left and the cursor stays on the left. So there is an inconsistency there. Other apps like Lollypop, QGIS, Zotero will open as expected on the active, main display. On the other hand, I could see Electron apps like RStudio and Element open in the wrong display. I am using Ubuntu 20.04 with GNOME 3.36.8 on Wayland. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 44837a12d12be3e525fa48b37c3dd2553cc97d94 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 153920] Windows not opening in default / primary monitor
https://bugs.documentfoundation.org/show_bug.cgi?id=153920 V Stuart Foote changed: What|Removed |Added CC||glo...@fbihome.de, ||qui...@gmail.com, ||vsfo...@libreoffice.org --- Comment #1 from V Stuart Foote --- Since LibreOffice vcl composes to a virtual display with left most 0,0 on the left display it is not surprising that launching on non-primary monitor happens. You can look at the user profile for the ooSetupFactoryWindowAttributes for each module and follow along for changes for LO launch with different display configurations and module use. Losing content off display probably shouldn't happen. But seems an issue for the backend vcl to get the LO Start Center and modules to adjust onto the correct "default" display when secondary monitor is not available. Either translate, or fall back to single display defaults. @Jan-Marek would multi-head display testing be something more needed with the vcl::WindowPosSize work? -- You are receiving this mail because: You are the assignee for the bug.
