Running MATE desktop 1.16.0 and having problems with a couple of WINE applications I use every day that MATE randomly “loses” the control window of the application as I switch virtual desktops. The application hasn’t crashed and is still running (via ps), but the window is gone and any amount of flipping back and forth, alt-tab, etc. won’t bring it back.
This is a MATE problem and happens to me nearly every day, but as it isn’t “reproducible” by a known series of steps, I don’t feel I can constructively submit it to the developers.
Any ideas??
Hi. Thanks for the suggestion!
It’s a Mate problem, as Wine 1.9 and the new 2.0 also show the same behavior. It has something to do with the way in which windows are handled but the complexity is way too deep for me to understand. There’s also a problem with X windows from remote displays, say one’s ssh’d to a remote machine with X forwarding enabled with the -X switch; such windows will misbehave by becoming sticky like they’ve been signaled to ‘always on top’ although they’re not. That, or the focus on the desktop will get screwed up for a bit-- either the remote X window will steal focus and not let go, or more often, the window will sit on top and never let you apply focus or minimize it, etc. Just something not right, but again, way beyond my understanding of what might be going wrong.
Ubuntu (vanilla) with gnome-session-fallback (instead of Mate) does not have these problems.
1 Like
Mate uses Marco window manager. Flashback uses Metacity WM.
Metacity will run in Mate, I have done this. May be worth a try.
metacity --replace &
https://ubuntuforums.org/showthread.php?t=1709792
and you do need to install metacity first 
1 Like
Excellent. Have installed metacity as per your suggestion and will see if we can narrow this down!
1 Like
An update.
Metacity as a replacement for marco results in a more stable desktop with regards to the misbehaving windows from forwarded X connections. The bad news is my Wine app is still sometimes getting lost, maybe even worse than with marco.
One possible clue I’ve noticed is the Wine app showing up as one of the running applications in the lower panel of the virtual desktops other than the one it’s docked in. If you click on it in one of these ‘ghost’ panel appearances, it doesn’t jump to the other desktop and focus on the app or anything-- nothing appears to happen.
I don’t have a gpu enabled system or would give mutter a try too. (though imagine I’d run into the same?) Perhaps this is just with this particular Winwoes app? (the only one I run…)
The annoyance persists in 2020.
The problem: Certain wine apps disappear from the desktop in which they were launched.
An example: Mate desktop with 4x1 Workspace Switcher and Window Selector.
The wine app can be made visible again by clicking on the app name in Window Selector.
Clicking on the Workspace itself does not restore the app: it remains hidden.
It appears to be a Mate issue, consistently present in Ubuntu 14.04 to 20.04.
If a solution exists rather than the workaround with the Window Selector , then I would like to know about it.
A reproducible instance of the bug: wine 4.0, launch WinEdt.exe from https://www.winedt.com/
1 Like
Hello! Welcome to the Ubuntu MATE Community, and thanks for posting!
I'm also running 20.04 and tried to reproduce this, and wasn't quite able to. Do you think you'd be able to try and show us what happened with some screenshots? Thank you!
2 Likes
Late reply caused by the pandemic. The annoyance is managed with the Window Selector in mate. It affects WinEdt , but not any other common wine apps. Being it
is a mystery that leaves the wine app alive and running, it can be tabled as an issue and the issue closed. The workaround with the window selector could be added to the wine FAQ for WinEdt in particular. If other apps do this, then the question can be opened again.
1 Like
2021-03-14T23:00:00Z
The Mate Workspace Switcher exhibits window vanishing of wine app WinEdt when winecfg graphics is configured to allow the window manager to decorate and control the window but emulate a virtual desktop is disallowed (unchecked box in winecfg).
The settings are made by running winecfg in the directory root used by the wine app WinEdt. Setting emulate a virtual desktop in the graphics section will give the expected behavior in the Workspace Switcher: no vanishing window. See the image for the settings:
winecfg graphics setup
The negative is that wine app launches from WinEdt stay inside the Default - Wine desktop. The container limitation can be resolved by launching in WinEdt a linux shell script which opens a new window outside the virtual desktop.
For example, WinEdt can be in its own Mate window, the Default - Wine desktop, and the linux evince PDF reader can be in a different Mate window, which fits how the mate window manager is expected to work.
Attempts to make windows program sumatraPDF work with forward-inverse search will cause the PDF viewer to be inside the Default - Wine desktop. On a large monitor, the two windows programs WinEdt and sumatraPDF can be resized inside a larger Wine desktop. The wine desktop size is set in winecfg -> graphics, for example 2200 x 1250 with 96 dpi on a 27-inch monitor.
1 Like
