Bug 406392

Hmm, this is quite delicate situation. According to the source code, it's intended behavior.

> Works correctly if you use Cinnamon as the desktop

IIRC, neither Mutter nor Muffin have dedicated layer for fullscreen clients.

Could we maybe lower the Active layer, so it's between the Dock layer and the Above layer?

It would fix this request, but I would expect we would just get new bug reports going the other way.
It wouldn't be unfeasible to have IRC kept as keep above but still want to watch full screen youtube videos.


From https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER

To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom:

    windows of type _NET_WM_TYPE_DESKTOP

    windows having state _NET_WM_STATE_BELOW

    windows not belonging in any other layer

    windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE

    focused windows having state _NET_WM_STATE_FULLSCREEN

------

So we're following the recommended spec with our behaviour.

As a workaround you can set your fullscreen presentations to have the flag "keep below" set.

The workaround is horrible in the scenario we have:-(
This is the picture:- Teachers have a presentation on either Google Slides or PowerPoint on Office 365. They 'set up' on the teacher machine ( maybe they did the first few slides in another lesson ) and then when they are ready they drag it over to the right hand screen ( which is the interactive tv/whiteboard ) and then go full screen ( Incidentally the same happens if we persuade them to use LibreOffice, once that goes full screen ). If at that point they go 'keep below' OpenBoard is then on top as they would expect. When they drag it back to their screen it is now behind everything. Whilst you could say that all they have to do is uncheck the keep below, teacher are not going to do this. They have enough trouble dragging windows from left to right !!

Background if you are interested 
We have openSUSE on all the student machines and I am now working on getting the teachers to use openSUSE. Currently they use SmartBoard software which isn't available on any distro since about 2011. I have to replace that functionality otherwise I am stuffed. SmartBoard tools always stay in front of everything. OpenBoard does all they need ie write over presentations etc if the blooming thing would stay visible. You have to appreciate that the 'teacher PC' may not be near the interactive tv/whiteboard and once teachers are in 'full swing' with a presentation they won't go back to the PC even if it's a few steps away.

I understand you seem to be doing it how it should work but is there not some way to fix/frig this

Sorry, but works exactly as expected and wanted by the specification as David points out.

(In reply to mal from comment #4)
> The workaround is horrible in the scenario we have:-(
> This is the picture:- Teachers have a presentation on either Google Slides
> or PowerPoint on Office 365. They 'set up' on the teacher machine ( maybe
> they did the first few slides in another lesson ) and then when they are
> ready they drag it over to the right hand screen ( which is the interactive
> tv/whiteboard ) and then go full screen ( Incidentally the same happens if
> we persuade them to use LibreOffice, once that goes full screen ). If at
> that point they go 'keep below' OpenBoard is then on top as they would
> expect. When they drag it back to their screen it is now behind everything.
> Whilst you could say that all they have to do is uncheck the keep below,
> teacher are not going to do this. They have enough trouble dragging windows
> from left to right !!

You could use a script so teachers don't have to set "keep below" manually

    function updateKeepBelowState(client) {
        client.keepBelow = client.fullScreen;
    }

    function trackClient(client) {
        client.fullScreenChanged.connect(function () {
            updateKeepBelowState(client);
        });

        updateKeepBelowState(client);
    }

    workspace.clientAdded.connect(trackClient);

    var clients = workspace.clientList();
    clients.forEach(trackClient);

Created attachment 119339 [details]
script

Even though this bug was closed, please do report back if the script works for you.
Even if we are spec compliant, it's important that real world problems are solved.

There's some other alternatives we can explore with bodging the windowType in window rules. 

For school deployments you may find the "KDE enterprise" mailing list useful.
https://mail.kde.org/mailman/listinfo/enterprise the idea there being to get all the people doing similar big deployments together to answer each other's questions about things they've faced.

Sorry, I don't understand how to do the script. Can you give me some idiot instructions please

Ta

Download archive attached in comment 7 and follow installation instructions in README.md

Sorry, didn't see that.

First quick look and it seems to work a treat.
I will try it in various scenarios next week
and see if I can find tame teacher as well.

I will come back for advice if I find any show stoppers
if you don't mind. In the mean time many thanks.

Ta

Mal