Closed sanderboom closed 2 years ago
Does it affect only maximized windows?
Also, does it happen only with more than one monitor?
It happens with just one monitor too (laptop display in my case), no special setup. If I change the display resolution and back again to what it was, then maximizing works as expected.
Are you using compiz?
Nope, plain Marco. Interesting bit is that when that happens a maximized window is not represented as occupying a 100% of the space in the workspace switcher, but rather like a quarter of it in the top most left corner of the workspace; same goes for all workspaces.
I'll take a snapshot next time that happens.
Pluma's status bar hiding behind the panel; window size in workspace switcher is not accurate.
+1, me too
I'm also affected, I run Mate on Mint 17.3 "Rosa" x64, with 2 monitors (positioned vertically, top monitor as main), and windows maximize under panel.
I'm using green Mint-X theme.
Edit: per comment on Launchpad, it may be related to using one of Mint-X desktop themes (either with Mate, or with Cinnamon). Is anyone affected using a different desktop theme?
Related:
https://bugs.launchpad.net/linuxmint/+bug/1393209
I realize this is an old thread, but I'm having the same issue on Mate running on CentOS 7, no Compiz, nVidia K1200 with proprietary drivers. Any hopes of a solution?
+1 I am also having the same issue on Mate environment in Parrot OS.
Workaround: I resolved it by moving the panel to the top of the top monitor. The problem went away.
@monsta I've reproduced this. It only happens on multiple monitors on the monitor which is not the primary.
So with 2 monitors side by side and the left most monitor being primary, it will only happen if you place a vertical panel on the right hand monitor on the left of that monitor.
@kocmo I like the old Gnome 2 style of having panels at the top and bottom of the display. The top panel is fine, its the bottom panel that is having this behavior.
@flexiondotorg I have only one primary monitor and yet this issue is observed.
I just noticed this too... and fixed it by changing the Window Manager in MATE Tweak to Marco (Software compositor) from Marco (Compton GPU compositor)
Update: My note above doesn't fix it like I thought.
However, when I toggle Undecorate maximized windows on/off in Mate Tweak it fixes it self.. although I'm assuming this may only be a temporary fix.
Well I have no idea why it happens... I would try changing window manager to Metacity or Compiz and see what happens. Might be something in a WM instead of mate-panel.
Hello, I have exactly the same issue. Ubuntu-mate distro + compiz activated (ccsm & all). Reorganizing displays make the windows maximize correctly, as long as the panel is not "between" two displays. Thanks
Same problem in Linux Mint 18.3 x64 Mate and Ubuntu Mate x64 17.10 I have 2-3 Monitors, but the panels are on only one monitor. When I use more than ONE panel, one of them get ignored by the maximized applications.
I also run different window manager on both machines.
Same problem with mate 1.18.0_1 with dual monitor setup with screens placed on top of one another.
Same problem. My laptop is the bottom monitor and my desk screen the top one. I'd like to keep the laptop screen as the primary monitor, but I can't, windows are hidden by the MATE panel, looking for a solution.
fixed in Ubuntu 18.04 x64 with Mate 1.20.1
@vkareh: can you please take a look at this...?
@monsta - yes, I can confirm this issue. The panel struts size calculation doesn't seem to take into account inside edges (e.g. top of bottom monitor). It's been on my to do list since last year, since it affects me. But I'll re-prioritize, since it seems to affect a lot of people
Thanks!
Great to know that this issue has been re-prioritized. I'm having the exact same behavior described by @Xyrop. Also using Ubuntu MATE (18.04 LTS - MATE 1.20.1).
I have 2 different multi-monitor setups:
I use the Mutiny panel arrangement and there is no problem with my HOME setup. However, in the 3 monitors setup, the maximized windows stretch under the top panel (for appmenu and indicators). Therefore I have either the window decoration or part of the actual application window (depending of Undecorate maximized windows
state) hidden under the panel.
So, it seems, as observed by @Xyrop and taking my use cases, that the problem only occur when the panel is between displays.
Here is a bounty in case more people want to participate:
This issue actually has its own bountysource link, but due to their plugin being buggy, the formatting was screwed up. I've manually edited the first post to make the bounty links appear.
https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472580736
This property MUST be set by the Client if the window is to reserve space at the edge of the screen. The property contains 4 cardinals specifying the width of the reserved area at each border of the screen, and an additional 8 cardinals specifying the beginning and end corresponding to each of the four struts.
The problem here is that this specifications has been written in times when multiple monitors on one screen was not popular thing... It was possible to have multiple screens and each screen had one monitor.
There is simply no way to reserve area in middle of screen... To fix this we need update/extend specification in way that allows to set struts for each monitor not screen with well defined behavior what should happen when wm or toolkit or app does not support updated specification.
Struts are used to calculate workarea: https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472697552
And workarea also is not monitor aware... So also that would need update. After updating you would have to update/fix window managers, toolkits and applications. So not only you would have to fix marco and mate-panel, but also gtk, qt...
@muktupavels - can't this be done with _NET_WM_STRUT_PARTIAL
and specifying the coordinates relative to the full extent of the screen?
Although I guess the math would be equivalent to setting struts in the middle of a screen, and it might break for setups where the monitors are different resolutions...
I don't know, I have not tried to look at this and not sure if I want to do that...
Can confirm this issue is affecting me on Ubuntu MATE 18.04 with Marco as window manager. My setup:
My primary monitor is HDMI-1-1, so when I maximize windows there, the bottom of the window gets hidden behind the bottom bar.
Cinnamon acts way better with multi monitors. If you change your workplace with different monitor configurations, it works too. Even, if you have 2 panels on every monitor.
Maybe someone want to adapt the code.
Cinnamon is a plugin to muffin, forked from gnome-shell which is a plugin to mutter. Mutter was derived from Metacity, but even by the time of Cinnamon there was probably quite a divergence.
In which version is this supposed to land? Currently rocking from a fresh Mint install 1.20.1 and still seeing this.
@awildturtok - not yet, really. I'm striving to finish this feature sometime this year, I want to make sure it lands on 1.22, but this requires changes to both the Panel and Marco, and Marco is currently being reworked to fix a bunch of other issues.
@vkareh Well that is sad response... I was hoping that you will try to implement my idea to see if that is enough or more work is needed...
@muktupavels - I know, I started with your idea, but I ran into some issues with determining the right monitor to assign the panel struts into based on the workarea atom, so I started changing some properties in the atom, and then got busy at work and put it on hold... these days I rarely get enough time to get into a flow working on MATE, so I end up doing more testing than feature development.
I should be able to pick it back up soon, though, and will give you a more detailed answer
https://gitlab.gnome.org/GNOME/metacity/merge_requests/2
@vkareh _NET_WORKAREA_MONITORS
is newest property without using xinerama index... I have not pushed gtk and/or mutter changes yet.
@ParikhMeet "I have only one primary monitor and yet this issue is observed."
(This possibly covers the multi-monitor case, see below, but I only have one.)
I had the same problem, with only one primary monitor, on Linux Mint Debian Edition 3, MATE version. I don't know if this is exactly what fixed it, or if it will work in the multi-monitor case.
Fix: Making sure the primary monitor was set in Start Menu | Control Center | Displays, was probably what fixed it for me. On the Displays GUI, the "Set as primary" button was ungrayed/enabled. I clicked "Set as primary", clicked "Apply system-wide", logged out, and logged back in, and the problem was fixed. A system message stated logging out and logging back in is required for the change to take effect, after the "Apply system-wide" button was clicked. Before clicking "Set as primary", I did click "Detect monitors", but it didn't seem to change anything.
I think I didn't see the problem on a fresh install of LMDE 3, but the problem followed my settings when I copied my home directory, including desktop configuration settings, from an older machine which showed the problem to a new machine with fresh LMDE 3 install that didn't show the problem.
I don't know why the monitor wasn't automatically set as primary when I only had one monitor. Possibly in copying settings between home directories on different machines the monitor change was detected by MATE and it unset the primary-monitor setting. The problem may have shown up when I moved to the older machine from an even older one, and I might not have noticed right away.
Also, maybe the window manager is doing this because it is treating the monitor as a secondary, since it was not set as primary. The WM may be expanding the desktop to fit the entire screen on all monitors except the primary, and on the primary expands it to fit the region above the taskbar. Maybe when sizing the desktop the WM isn't checking monitors to see whether it is supposed to be showing the taskbar on them, but only to see if they are primary. Some people are posting about not being able to configure the WM to show the taskbar on their secondary monitors.
I did try other things, like changing the window manager between Marco+Compositing and Marco, that didn't seem to work. I didn't log out and log back in for those, but I think the "Set as primary" change is probably what fixed it, not the other things.
I don't see a way to unset the primary monitor setting from the GUI to test that error and fix are repeatable. Probably there's a way to unset it from the command line, but the fix is working now, so I don't want to change it.
@hinnantjames I tried it, but my affected monitor is already primary and it applied system-wide (but it does not necessarily have an effect because of LightDM cursor-following feature. Window titles go behind the panel, windows maximize behind the panel. I've got a bottom panel with Win98 style task buttons so I don't lose any control over the windows but it's still frustrating.
so i'm still experiencing this issue on ubuntu 18.04 Mate. Is it fixed in 20.04? :)
same problem on vertical configurations. horizontal multimonitor is fine.
Hello, I confirm, same problem with vertical monitors on Ubuntu Mate 20.04. It's ok with horizontal monitors. Some new ideas to fix it ?
I'm experiencing a possibly related issue with Xubuntu 18.04 and Atril. By default, when Atril opens in maximized mode, it seems to maximize according to my screen size and not take the bottom panel (I have no top panel) into account. I'm using a single 1080p monitor.
On 20.04 Mate I'm seeing this issue with dual horizontal monitors.
My monitors are next to each other, so I have a left and a right monitor. Using the Mutiny panel layout, if the left monitor is primary (so the dock on the left side of the left monitor) the windows maximize and snap without overlapping the dock.
If I make the right monitor primary (so the dock is on the left side of the right monitor, hence at the "seem" between the two monitors) the windows maximize under the dock.
I have tried switching between nvidia-driver-450
and Nouveau
and also between Marco Adaptive
and Marco (No compositing)
but the bug persists.
EDIT: I've tried adding a panel to the right side of the right monitor, and windows maximize correctly with that one, so it really seems to be an issue with the "seem" between the two monitors.
Same as @agude here. Mint 20.1 + Mate. Two horizontal monitors. Any panel added to the seam between the monitors always occludes maximized windows.
The exact same bug @phord experienced is still here on ubuntu mate 20.04. @raveit65 @rbuj Sorry for the mention but this is pretty annoying :/
Can confirm this issue still exist in version 1.24.2.
It seems that the monitors are seen as a single "screen"/strut, thus moving x/y up or down moves the entire view port. Some of the commits above look to be headed in the right direction and seem to have addressed this issue by assigning individual monitors their own strut and drawing in there; see @vkareh and @muktupavels commits.
A workaround for the time being may be to enable the "show hide" property in your panels in order to see the title bar behind them.
Hi! Is the fix already released? I've just encountered this with a vertical monitor layout, in my usual office I have side-by-side monitors and there it works correctly. My guess is that it's because there's nothing below the bottom edge of the primary screen with a horizontal layout?
In certain setups (e.g. dual monitor positioned vertically) I notice that the bottom panel of the top monitor and the top panel of the bottom 'cover' any maximized windows.
It seems that the area that these panels take up are denoted as available space for windows, while it should not.