Desktop mode broken on Mutter

[chobinouche]

On the gnome desktop, the desktop mode is not working properly.

-The overlay is not always in the front, clicking on another window -Drawing does nothing, until you switch to the keyboard or mouse in the panel. At this moment, the mask is redrawn and the drawn lines show up.

I already made a fix for both issues, I will make a pull request shortly with the details.

[watsaig]

Hi, Thanks for the fix, that's great! I'll test this properly in the coming days and integrate it if everything's ok on the various environments currently supported (KDE4, Unity, Cinnamon... all based on X).

[antoine-girard-vallee]

I believe my fix is not limited to X, I did not see LINUX OS macros where I did the modification (there were plenty in the file itself) and did not add any. I do not have a build environment in windows or mac, so I cannot test it.

[watsaig]

Ok no problem, I'll make sure to test on Windows and Mac too.

[watsaig]

So, this works fine on Cinnamon (Linux Mint 18) as well as Windows 10 and OS X 10.11. However it breaks functionality on Unity on Ubuntu 14.04. I haven't tested other environments on 14.04 or 16.04 yet.

It seems I get the opposite effect: when I apply your changes, drawing occasionally does nothing. It updates e.g when I switch to board mode and back to desktop mode.

Any chance you can fix this, maybe by checking for the presence of Mutter/Wayland/Gnome shell?

[antoine-girard-vallee]

Sorry for the delay, I looked in the pull request thread instead of this one. I'll setup a Unity desktop and try to fix the issue.

[antoine-girard-vallee]

@freeheel3r I made myself a vm on ubuntu 14.04 and tried to build the binairies on it but I get issues with your build scripts. It builds but I get a realloc(): invalid pointer error when I start it.

[watsaig]

Huh, that's odd. What's the complete error? And are you on the dev branch? (should be the same either way but you never know)

[antoine-girard-vallee]

Yeah I am. I used the ppa for qt-latest described in the .md of the project. I modified build.sh to point to /opt/qt55 and disabled the clean to avoid rebuilding each time. the Thirdparties were built with qt4 (which I found weird, but the build scripts included asked for qmake4) To be honest, I got the same issue a lot with debian, and ended up using @SamuelLongchamps 's setup. If you have a IRC/skype / whatever to discuss this issue, please tell me to avoid spamming the thread with troubleshooting.

for the complete error, its complete, plus a pointer address, which wont give you a lot of info.

[jarmopi]

The proposed patch (#67) did not work for us when we tried it when we built our test version of OpenBoard in Debian Stretch. The desktop mode was unusable in "vanilla" and patched versions. However, we were able to create a temporary quick-and-dirty fix that worked for us.

The original patched line (958) is:

p.drawRect(mTransparentDrawingView->geometry().x(), mTransparentDrawingView->geometry().y(), mTransparentDrawingView->width(), mTransparentDrawingView->height());

And our fixed line is:

p.drawRect(mTransparentDrawingView->geometry().x(), mTransparentDrawingView->geometry().y(), mTransparentDrawingView->width() - 2, mTransparentDrawingView->height() - 2);

This leaves one-pixel gap in the bottom and right edges where drawing will be invisible, but this probably could be fixed with further adjustments. Like I said, this is a temporary fix.

Turns out that Qt's drawRect() does not clip its coordinates in some cases. If they're larger than the destination image, the function simply does nothing. Because the mask image then only contains transparent pixels, nothing gets drawn on the desktop. The fix was to make the rectangle slightly smaller. This is why the fix is only "temporary"; we're not sure why drawRect() simply does not clip the coordinates. None of us are Qt experts, so we cannot fully fix the underlying problem. As of why the mask image gets drawn correctly when switching between desktop and board modes, we don't know.

We tested this in Mutter version 3.22.2-3 and Qt 5.7.1.

Hopefully this will help others.

[jarmopi]

Another issue we found but what we could not fix happens in gnome3 and mutter. This happens even in our "patched" version (see the previous comment). It does NOT happen in Ubuntu Xenial when using Unity.

In desktop mode, if you open a new program, you cannot draw over its window. The new window makes OpenBoard not receive any mouse events. If you move the window to another location, you can now draw on where it previously was at. If you drag the window under the tool palette, the palette is completely unusable (it ignores the mouse) until you move the window somewhere else. You cannot even drag the palette. The cause for this is unknown.

[SamuelLongchamps]

jarmopi

Another issue we found but what we could not fix happens in gnome3 and mutter. This happens even in our "patched" version (see the previous comment). It does NOT happen in Ubuntu Xenial when using Unity.

In desktop mode, if you open a new program, you cannot draw over its window. The new window makes OpenBoard not receive any mouse events. If you move the window to another location, you can now draw on where it previously was at. If you drag the window under the tool palette, the palette is completely unusable (it ignores the mouse) until you move the window somewhere else. You cannot even drag the palette. The cause for this is unknown.

This should get its own issue. I could reproduce the bug in jessie (mutter 3.14.4). Does this happen when using Cinnamon? It seems like Mutter is quite a hassle to get this feature to work, especially if changes break other compositors.

freeheel3r

Any chance you can fix this, maybe by checking for the presence of Mutter/Wayland/Gnome shell?

If we go down this road, we need to keep in mind cross-platform. I would consider an optional launch argument or configuration file located in a folder ".openboard" in the home folder to select the implementation. The check for the compositor could be made by the launch script specific to the platform/distribution, that way it would be decoupled from the actual software.

[jarmopi]

Does this happen when using Cinnamon?

A quick test shows it does not. In Cinnamon 2.8.6, under Ubuntu 16.04, everything works just fine, even when using the original unpatched binary. I can open new programs, drag their windows behind the tool palette and then use the palette, and even draw over them. Everything seems to work.

Addendum: looks like the patched version I made actually works worse in Cinnamon :-( it makes the bottom launcher bar disappear.

[SamuelLongchamps]

A course of action could be to verify if the issue is still present in Mutter's latest dev version. If not, we could go through the changelog to see that's changed. If it's still present, a minimal code example could be produced (standalone so that we're sure it's not something wrong with some obscure OpenBoard's implementation) and we could look at what Qt does in their source code. From there, we can boil down the problem to Qt's GNU/Linux-specific code and check what are the differences between Mutter and Muffin's implementation for these specific calls. This should give us the answer to why Mutter behaves like this and possibly devise a solution.

[jarmopi]

Apologies for the slow response, we've been quite busy with other things and haven't been able to try the latest development version yet. We'll get around to it... eventually :-)

[htrampe]

90 Same problem - all things not working...

[htrampe]

Ok, so the gitrepo from puavo-os works fine with own build https://github.com/puavo-org/OpenBoard, tried under ubuntu budgie 17.04 gnome desktop

[janklostermann]

The desktop mode is broken on LXDE-pi (with Openbox Window Manager) in Raspian Jessie for Raspberry Pi as well. Drawing on the whiteboard works like a charme. Drawing on the desktop not.

When I switch to Desktop and try to draw with stylus, then the Desktop gets black (OpenBoard toolbars still there) and nothing happens. Switching to brush then allows me to draw on the black surface. Switching back to OB I get my white surface and switching back again to Desktop I see the desktop with the brush drawing, where the drawing has black rectangles below it, covering the desktop. It seems that these rectangles are area of a section of the line that I painted with my finger on the touchscreen. (I saw another post somewhere here commenting on a stylus/brush difference as well, but I cannot find it anymore - maybe it has some relation?)

It would be cool if you could consider the LXDE-Pi on Raspberry Pi as well! Installation of OB works well via the Flatpak package. Compiling it on the RPi I got stuck with some error regarding the OpenSSL stuff that I could not resolve yet.

Thanks for all your efforts on this great tool!

[janklostermann]

Now I found the brush thing that I mentioned in my post above: https://github.com/OpenBoard-org/OpenBoard/pull/67 - but I am not so sure if it is really related...

[siyman]

@janklostermann I had the same issue right now (never tested it before) under LXDE Ubuntu 18.04. My guess worked like a charm: simply install xcompmgr (sudo apt install xcompmgr) and start it right away (autostart it if necessary). The desktop overlay is without any hustle afterwards. I think that OB simply requests 3D acceleration and has no fallback implemented.

Therefore my suggestion is a request to implement such a feature or at least document it somewhere.

[4015-al]

I have the same issue on Ubuntu 20.04. Installing xcompmgr didn't fix it.