GNOME Bugzilla – Bug 161972
Workspace switcher not fully visible in split-screen mode
Last modified: 2020-11-06 20:08:08 UTC
-Launch gnopernicus magnifier in split-screen mode -<Ctrl><Right Arrow> to move to the workspace to the right -Notice the 'workspace switcher' always appears in the center of the screen when you move between workspaces. -Because it is in the center, the magnified screen obscures half to this dialog - so the user does not get to see which workspace they have moved to. The Workspace switcher dialog appears but it is partly obscurred by the magnifier window. The dialog cannot be dragged, meaning that the user does not get to see which workspace they have moved to. The dialogue should automatically go to where there is space for it
See bugster bug #6197169, and similiar bug #6182510
If the magnifier is override redirect then this is not a metacity bug. The window manager has no knowledge of override redirect windows. You can check whether it's override redirect with xwininfo.
actually I'm pretty sure its a DOCK that sets a strut. Theoretically we could just manage the workspace window.
We can just make metacity's popups appear on top of docks, but I really thought they already were on top of docks, thus the question about override redirect. We can't manage metacity's popups - metacity will get really confused if it tries to manage its own windows. That's why metacity-dialog is in a separate process.
The workspace-switcher popup does appear on top of the magnifier window (which is of type dock and no override redirect). The actual problem is that in split-screem mode, the other half of the popup window which is above the magnifier is not visible to the magnifier. Also as the popup window cannot be moved the full magnified view will never be seen. Attaching a screenshot depicting this problem.
Created attachment 35158 [details] Screenshot with magnifier and workspace-switcher poppup window.
We could make the switcher avoid docks (as long as there's enough space to do so anyway)
Havoc: I think all centered windows should avoid docks if possible. This would resolve a significant number of similar bugs about "window foo obscured by magnifier" or "window foo obscures magnifier", etc. Does this seem acceptable?
sounds fine to me. Just be sure to handle the case where there isn't enough space between the docks for the centered window, then overlap will be required.
Popups are not managed by metacity, hence the fix to constrain popups needs to be in GTK+. Moving the bug to gtk+.
Attaching a patch which constrain the popups within the workarea only if a11y is ON. To get the workarea I am making use of _NET_WORKAREA atom, if set. The constrain code is as follows. 1. If the popup 'x' < 'workarea x', then set new 'x' to 'workarea x'. 2. If popup 'x' + popup 'width' > 'workarea width', set 'x' such that the widget fits within workarea. If new 'x' is now less than 'workarea x' set it to 'workarea x'. 3. Even after this, if popup 'x' + popup 'width' > 'workarea width', then the popup 'width' needs to be altered such that it fits within workarea. Same applies for y calculatios. In short popup widget's x, y, width, height are altered to fit within the workarea. Kindly comment.
Created attachment 48763 [details] [review] Patch to constrain popups within workarea.
- Positioning of popup windows is up to the person popping them up ... and cannot be done in the generic GtkWindow code. - I can't see *any* justification for turning on special "avoid docks" behavior when accesibility is enabled. (Accessibility may be enabled purely for scripting or testing purposes. It certainly has no relationship to whether a magnifier is running)
Owen - we've had similar patches to apps/etc. rejected with the reasoning that any WORKAREA awareness should be taken care of in gtk+. Given a choice between fixing something in one place and fixing it in 100, 'one place' seems almost always to be the right choice. Constraints placed on windows are a fact of life, it is correct for window placement to be subject to constraints for practical reasons. Nobody AFAIK contests this for managed windows. But for unmanaged windows, the toolkit or app has to do the work. I believe that the toolkit is the right place for this particular constraint. The toolkit isn't deciding on the entire placement policy, it is only trying to ensure that the application's placement request is sensible in the context of the current DE, i.e. the available screen/WORKAREA. I fully agree that this should not depend on whether the 'accessibility' key is true or false - however a "constrain popups to WORKAREA unless the parent is a DOCK" policy seems entirely correct to me.
If you want to submit a patch to GTK+ that adds a new API to constrain a window to the workarea, that might be OK. An API to retrieve the workarea probably is OK. Starting to constrain POPUP windows without explicit app API is not compatible, and will not be accepted.
I've filed bug 329491 about adding gtk+ API for constraining popups. Although as the window manager we could just use the code we have for constraining managed windows to avoid docks, that wouldn't fix this for the other apps so I'm marking this bug as depending on that one.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
*** Bug 339898 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.