It's often useful to view the text behind the dialog box by moving the dialog box out of the way. Other VCL toolkits allow this such as Windows and SAL_USE_VCLPLUGIN=gtk. Other GTK3 apps allow child dialog boxes to be moved.
I use resizing as a workaround, but it's a bit of a hacking solution as it causes the whole main window to restore and limit your ability to resize.
is it happening with an specific dialog? or with all of them?
Build ID: d3ff66999d924e832f8219c65ced0526f1a67f82
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
I can move the dialogs...
Most of them. Make sure you're using the gtk3 backend. Steps to reproduce.
1. SAL_USE_VCLPLUGIN=gtk3 ./libreoffice
2. New text document
3. right click -> paragraph
I could reproduce this problem with Fedora 25 with both wayland and xorg.
Created attachment 130602 [details]
Example of a dialog box blocking information
Are my instructions really that hard to follow? Maybe pictures will help.
Created attachment 130603 [details]
With GTK2 backend, I can move the dialog out of the way
With Windows, gtk2, and other native gtk3 applications such as Gnumeric and gedit can all move dialogs.
Not being able to see the content that your dialogs are supposed to be editing is a major real-world usability issue for an office suite.
This seems to be a GNOME specific bug. I could reproduce this on:
* Fedora 25 with GNOME
* Arch with GNOME.
I could NOT reproduce this with:
* Arch + KDE
* Ubuntu Unity
It is using a modal dialog under gtk3.
This is not a bug, or at least, not our bug and not behavior specific to LibreOffice, you'll see the same in other gtk3 applications. Its "attached modal dialogs"
You can disable it for the desktop with gnome-tweak-tool and the "windows" tab and toggle off "attached modal dialog" which is on by default on gnome 3.
Many native gtk3 applications such as gnumeric and gedit do not have this issue. Is it something that can be controlled on the application side?
*** Bug 113522 has been marked as a duplicate of this bug. ***
Filed https://bugzilla.gnome.org/show_bug.cgi?id=789838 as folowu-up bug.
*** Bug 114267 has been marked as a duplicate of this bug. ***
*** Bug 135598 has been marked as a duplicate of this bug. ***
Caolán: Sorry, but I think we should do something to improve this. Dialogs should be set "modal" only if there is a reason to freeze other windows (e.g., waiting for user input while we do not want the user to change the content in other windows). If there is no such a reason, we should not set it as "modal".
At least I have found that using Glade, there is a option "modal" to the dialog, and I have successfully set the "Format Cells" dialog as non-modal. Will submit a patch on gerrit for this dialog then. For instance:
In sc/uiconfig/scalc/ui/formatcellsdialog.ui, if I change the following:
then this dialog is movable again.
Have done a few of them:
Caolán: would you please review and provide your thoughts, before more dialogs to be set this way?
You can't just flip that bit safely. If its modal you can't interact with the window underneath the dialog, if its not modal then you can and generally the application isn't prepared to handle that and its possible to change the document that the dialog will operate on in ways they don't expect. Or the user can spawn new dialogs and other interactions which will crash the app.
Its an unfortunate side-effect of being modal that gnome will attach the dialog to its parent in a way that its not movable. There is a global option, available under "Windows" in gnome-tweaks, to turn off Attach Modal Dialogs. There isn't an intrinsic need for modal dialogs to be not movable, but a gnome-level default feature that is making that happen.
(In reply to Caolán McNamara from comment #15)
Understood. I will abandon those patches then. Thank you Caolan.