Disabling the hot corners for fullscreen applications would result in unpredictable behavior. When does it work, when not? Why doesn't it work when I move my mouse there?

There are more applications than video players and games which use fullscreen. For such usecases it is important to have the corners activatable. Also for two screen usecases, there is no need to disable the corners. I often use one screen to watch TV and work on the second screen and switch applications with Present Windows and/or Desktop Grid through screen corners while a fullscreen app is open.

The only way to have a consistant user interface which does not act random is to have the corners always enabled. If the user triggers the corner unwillingly he will understand why it was activated and will in future remember to not trigger them when using a fullscreen app.

I am sorry to say, but I do not consider to implement your wish.

Whenever you're running a fullscreen application and feel like there should be no cornereffects, you actually don't want to run a composited "desktop" at all at that time, that's (one reason) why you can rule it away from 4.7 on (and atm. can eg. just suspend it)

If you've use for compositing, you should have use for the managing effects (like desktopgrid, present windows) as well (or have to explain why yes but no :-)

just as a remark (correction) to what Thomas just said: there are corner actions independent 
from compositing state such as lock screen or show dashboard.

In general games do nasty things like grabbing the screen and raising the window to the top of 
all windows and will always be above the screen corners. It's not supposed to be like that but 
many games actually do that.

(In reply to comment #1)
> Disabling the hot corners for fullscreen applications would result in
> unpredictable behavior. When does it work, when not? Why doesn't it work when I
> move my mouse there?

Unpredictable? If fullscreen it doesn't work, otherwise it does... to me this seems rather predictable. And the other question is: does the user actually expect corners to work at all when running a fullscreen app? Anyway...

> 
> There are more applications than video players and games which use fullscreen.
> For such usecases it is important to have the corners activatable. 

For instance? This is an honest question, I can't think of anything which doesn't fall into the entertainment/presentaion category like video, photo slideshow, presenstation, games? Even in case of a fullscreen highly serious business presentation I don't want to reveal my desktop to the audience by accitently hitting a corner.


> Also for two screen usecases, there is no need to disable the corners. I often use one
> screen to watch TV and work on the second screen and switch applications with
> Present Windows and/or Desktop Grid through screen corners while a fullscreen
> app is open.

Well then corners should remain enabled on the second screen, of course. For the other screen I don't know.

> 
> The only way to have a consistant user interface which does not act random is
> to have the corners always enabled. If the user triggers the corner unwillingly
> he will understand why it was activated and will in future remember to not
> trigger them when using a fullscreen app.

Huh?! I surely understand why the actions are activated and surely don't want to trigger them. But it happens never the less! For instance as a game requires to push the mouse at the edges in order to move the map. Don't tell me you can play such a game and avoid to move the mouse into the corner (even if you try). And sorry, playing fullscreen games is a perfectly valid use case, too! So a solution sould be found to avoid interruption by Dashboard, Present Windows and the like.

(In reply to comment #3)
> just as a remark (correction) to what Thomas just said: there are corner
> actions independent 
> from compositing state such as lock screen or show dashboard.
> 
Right. I even tried to manually susend compositing, just to be really sure. But some are still there, in my case Dashboard.

On Sunday 24 April 2011 13:24:57 Michael Reiher wrote:
> https://bugs.kde.org/show_bug.cgi?id=271607
> 
> 
> 
> 
> 
> --- Comment #4 from Michael Reiher <redm gmx de>  2011-04-24 13:24:56 ---
> (In reply to comment #1)
> > Disabling the hot corners for fullscreen applications would result in
> > unpredictable behavior. When does it work, when not? Why doesn't it work when I
> > move my mouse there?
> 
> Unpredictable? If fullscreen it doesn't work, otherwise it does... to me this
> seems rather predictable.
You imply that the user knows about the concept of fullscreen applications and that the user 
recognizes that a fullscreen application is in active. I would not be sure about that.
> 
> > 
> > There are more applications than video players and games which use fullscreen.
> > For such usecases it is important to have the corners activatable. 
> 
> For instance? This is an honest question, I can't think of anything which
> doesn't fall into the entertainment/presentaion category like video, photo
> slideshow, presenstation, games? Even in case of a fullscreen highly serious
> business presentation I don't want to reveal my desktop to the audience by
> accitently hitting a corner.
Let's see:
* browser
* IDE
* Virtual machines
* Remote Desktops
* Any other application I can set to fullscreen
For all those I want to be able to use corners
> 
> 
> > Also for two screen usecases, there is no need to disable the corners. I often use one
> > screen to watch TV and work on the second screen and switch applications with
> > Present Windows and/or Desktop Grid through screen corners while a fullscreen
> > app is open.
> 
> Well then corners should remain enabled on the second screen, of course. For
> the other screen I don't know.
No that does not make sense. Consider my TV application runs on screen 1 and is the only 
application on screen 1. All other windows are on screen 2. I want to use present windows 
which activates only on screen 1, but does not affect the TV application.
> 
> > 
> > The only way to have a consistant user interface which does not act random is
> > to have the corners always enabled. If the user triggers the corner unwillingly
> > he will understand why it was activated and will in future remember to not
> > trigger them when using a fullscreen app.
> 
> Huh?! I surely understand why the actions are activated and surely don't want
> to trigger them. But it happens never the less!
You can change the settings for activation to make it more difficult to hit it accidentially. In 
case you hit it by playing the game you can also consider changing the sensitiveness of your 
mouse. In general for games you want to be as precise as possible. You should never miss 
your target and the screen corner is a pixel which cannot be used by games in any useful 
way.

(In reply to comment #6)
> You imply that the user knows about the concept of fullscreen applications and
> that the user 
> recognizes that a fullscreen application is in active. I would not be sure
> about that.
Well, I'd think so. After all they look fundamentally different. At least they have no titlebar, no frame and often they have distinct usages like playing a movie, a slideshow, whatever. And second the user usually has to enable it with a special button or menuentry.

> > For instance? This is an honest question, I can't think of anything which
> > doesn't fall into the entertainment/presentaion category like video, photo
> > slideshow, presenstation, games? Even in case of a fullscreen highly serious
> > business presentation I don't want to reveal my desktop to the audience by
> > accitently hitting a corner.
> Let's see:
> * browser
> * IDE
> * Virtual machines
> * Remote Desktops
> * Any other application I can set to fullscreen
> For all those I want to be able to use corners
Ok, running things like browser or IDE, or PDF viewer for that matter, in fullscreen would belong in to the presentation category for me. As written in my original report, I found this to be mainly a bit strange for these apps. However I would agree to not disable corners for "normal desktop" apps. Even though it might be wanted to for offical presentations, where the audience should not see your open windows or what funny applets you have on your dashboard ;)

As for remote desktops or VMs, when running them fullscreen I actually expect them to take over the screen corners, too and handle them within the VM and not in the host. This is actually what I run at work, a fullscreen VM with KDE permanently on a second screen. So this particular example actually falls into the same category as games, where the corners should belong to the app and not to the window manager/host.

> No that does not make sense. Consider my TV application runs on screen 1 and is
> the only 
> application on screen 1. All other windows are on screen 2. I want to use
> present windows 
> which activates only on screen 1, but does not affect the TV application.
Ok, I see. This is of course a perfectly valid use case as well.

> You can change the settings for activation to make it more difficult to hit it
> accidentially. 
Well, I have them set up in a way that is optimal for my usual way to use the desktop. (Actually on this system they were still on default by now, so actually not exactly easy to hit. Still I triggered them in the game.)

> In 
> case you hit it by playing the game you can also consider changing the
> sensitiveness of your 
> mouse. In general for games you want to be as precise as possible. You should
> never miss 
> your target 
Sorry to tell you that, but my mouse is setup perfectly fine for me and I don't expect developers to tell me which settings of my mouse I want ;) This is not a solution.

> and the screen corner is a pixel which cannot be used by games in
> any useful way.
You have to explain that one. Most stragety games use the corner to scroll diagonally so how is it not useful?

So basically after thinking more about it, it boils down to that you can have certain situations where you simply want to disable active screen corners (and probably edges). Not in general for all fullscreen apps, but for certain apps or situations. For me this would be:

Games: generally
Remote desktop/VMs: on demand (e.g. when on separate screen)
Presentations: on demand (e.g. in a presentation profile)

Perhaps kwin could be told to disable corners on a per app basis (only fullscreen of course)? Like all wine apps, or you could manually apply it to a VM window, or the presentation profile (which also disables screen locking and stuff) could set it.

I just checked with OS X, which also features active corners. Corners are triggered for fullscreen apps like DVD player and such, however not for games. So my wish doesn't seem to be too exotic ;)

Please consider that other users are not as experienced as you and that their use cases 
might differ from your usecases.
> > You imply that the user knows about the concept of fullscreen applications and
> > that the user 
> > recognizes that a fullscreen application is in active. I would not be sure
> > about that.
> Well, I'd think so. After all they look fundamentally different. At least they
> have no titlebar, no frame and often they have distinct usages like playing a
> movie, a slideshow, whatever. And second the user usually has to enable it with
> a special button or menuentry.
Have you ever seen the netbook interface? And I doubt that users notice that they enter 
fullscreen mode. They are not as experienced as you are.
> Ok, running things like browser or IDE, or PDF viewer for that matter, in
> fullscreen would belong in to the presentation category for me.
For you using a browser is a presentation. I don't use it that way and I don't think many use it 
that way.
> As written in
> my original report, I found this to be mainly a bit strange for these apps.
Again that is how you see it. For me it is a totally valid use case to use Present Windows 
during a presentation. In fact I make regularly use of it and see presentations making use of it 
(or of Expose).
> As for remote desktops or VMs, when running them fullscreen I actually expect
> them to take over the screen corners, too and handle them within the VM and not
> in the host. This is actually what I run at work, a fullscreen VM with KDE
> permanently on a second screen. So this particular example actually falls into
> the same category as games, where the corners should belong to the app and not
> to the window manager/host.
To me a VM or a remote desktop is just another window running one application I need to use 
and therefore should be like a window. Again your usecase differs.
> > In 
> > case you hit it by playing the game you can also consider changing the
> > sensitiveness of your 
> > mouse. In general for games you want to be as precise as possible. You should
> > never miss 
> > your target 
> Sorry to tell you that, but my mouse is setup perfectly fine for me and I don't
> expect developers to tell me which settings of my mouse I want ;) This is not a
> solution.
It might have been. Misconfigured hardware is very often the reason for wishes and bug 
reports.
> 
> > and the screen corner is a pixel which cannot be used by games in
> > any useful way.
> You have to explain that one. Most stragety games use the corner to scroll
> diagonally so how is it not useful?
I rather doubt that games make use only of the rectangle (0, 0, 1,  1). If you move your mouse 
into it KWin will instantly move your cursor back.
> Perhaps kwin could be told to disable corners on a per app basis (only
> fullscreen of course)? Like all wine apps, or you could manually apply it to a
> VM window, or the presentation profile (which also disables screen locking and
> stuff) could set it.
I'm sorry to say but this sounds a little bit too complex for such a case. Your "problem" is not 
a generic one. In fact that is the first wish for it or bug report about it since we introduced the 
functionality more than three years ago. I understand your need but it is not something I 
would say we should spend time on it.

If that makes it easier to discuss, I could restrict myself to the use case of fullscreen games and forget the other possible use cases for now. Anyway...

(In reply to comment #9)
> Please consider that other users are not as experienced as you and that their
> use cases might differ from your usecases.
I'm very well aware of that.

> Have you ever seen the netbook interface? And I doubt that users notice that
> they enter fullscreen mode. They are not as experienced as you are.
I admit I have never used the netbook interface up to now. I was only talking about desktop usage. Perhaps for netbook interfaces things would need to be handled differently. But desktop usage is not exactly a corner case.

> > Ok, running things like browser or IDE, or PDF viewer for that matter, in
> > fullscreen would belong in to the presentation category for me.
> For you using a browser is a presentation. I don't use it that way and I don't
> think many use it that way.
I don't use fullscreen browsers or IDEs at all. Only maximized. I was just trying to categorize things. But ignore it.

> > As written in
> > my original report, I found this to be mainly a bit strange for these apps.
> Again that is how you see it. 
Indeed, that's what I meant.

> For me it is a totally valid use case to use Present Windows 
> during a presentation. In fact I make regularly use of it and see presentations
> making use of it (or of Expose).
Agreed. That's why I agreed to not simply disable corners on all fullscreen windows. However I can imagine some people might not like it.

> To me a VM or a remote desktop is just another window running one application I
> need to use 
> and therefore should be like a window. Again your usecase differs.
Sure. I didn't claim my way of doing things has to fit everybody. But so doesn't do yours. But for me there is a point to leave the corners to the VM. In my example case at work I treat it as a separate machine. On a single display computer I would probably keep corners to the host. That's why I wrote "on demand" in my summary at the bottom.

> It might have been. Misconfigured hardware is very often the reason for wishes
> and bug reports.
Sure. It just sounded like you were telling me "I won't fix it, change your way of working!", which is never a good approach.

> I rather doubt that games make use only of the rectangle (0, 0, 1,  1). If you
> move your mouse into it KWin will instantly move your cursor back.
Does that matter? As a matter of fact pushing the mouse into the corner scrolls differently than on the edges, i.e. diagonal. What ever exact pixels are responsible for that. And it's likely to trigger Kwin corner actions.

> > Perhaps kwin could be told to disable corners on a per app basis (only
> > fullscreen of course)? Like all wine apps, or you could manually apply it to a
> > VM window, or the presentation profile (which also disables screen locking and
> > stuff) could set it.
> I'm sorry to say but this sounds a little bit too complex for such a case. 
Well, I was thinking along the lines of window rules (although it probably doesn't directly affect the game window itself here). They also cover corner cases, still they are there. A more userfriendly way would of course be welcome, ideally automatic detection, as not every user is as experienced as me ;)

> Your "problem" is not a generic one. 
Here however I disagree. It is in so far generic one, as it applies to (at least) all map based games (stategy) in combination with kwin and corner action. 

> In fact that is the first wish for it or bug report about it
> since we introduced the 
> functionality more than three years ago. 
Allways someone has to be the first :) Also I started really using corner actions just now that I have a system capable handling that well (in terms of general speed and a proper graphics card. Waiting seconds for the dashboard or present windows is not really usable.). Also gaming on Linux is also not always a pleasure. Especially with Wine it highly depends on the right graphics card and drivers. And you know the state of drivers better than me. But as we expect Linux/KDE to expand really soon the number of affected user will increase ;)

> I understand your need but it is not something I 
> would say we should spend time on it.
Well, at least Apple considered it to be a problem and saw the need and added means to disable corner actions in their system. So I'm probably not alone with that.

well a window rule might be possible, so I reopen

> Well, at least Apple considered it to be a problem and saw the need and added
> means to disable corner actions in their system. So I'm probably not alone with
> that.

Apple did nothing,
*Sane* games just grab the pointer (esp. when run in fullscreen mode - we're not talking about kpat) as well as the keyboard (to prevent you from accidentally alt+tab) what they do as well on *nix or windows - and then there's no screen corner effect because the pointer never reaches the screen corner but remains "inside the game".

Stupid question: is this a wine issue?

(In reply to comment #11)
> well a window rule might be possible, so I reopen

Thanks :)

(In reply to comment #12)
> Apple did nothing,
> *Sane* games just grab the pointer (esp. when run in fullscreen mode - we're
> not talking about kpat) as well as the keyboard (to prevent you from
> accidentally alt+tab) what they do as well on *nix or windows - and then
> there's no screen corner effect because the pointer never reaches the screen
> corner but remains "inside the game".
Hmm, this sounds reasonable.. and indeed, various keyboard shortcuts fall in the same category... I didn't run any native Linux games recently so I don't know how it works there.

> 
> Stupid question: is this a wine issue?
If the situation is as you say then probably wine should grab mouse and keyboard. I'll try and file a report there. We'll see. Still enabling the user to override Wine is not a bad idea. Because who knows when this will be implemented.

window specific overrides are a good idea. Also a global shortcut to disable active edges would make sense. Neither would be too hard to implement an neither has to have values set by default, so no user would get confused by this added feature.

The question is:
what do you aim to fix and is a window specific override for the edges actually sufficient and do you actually /have/ to _workaround_ a problem by a shortcut or rule or can it be fixed in a sane and more convenient way?

It makes few sense to override screen edges if the client should actually grab pointer and kbd - you'd rather pass it the pointer and kbd then. (if the client is unwilling or unable to to that itself)

the review request (https://git.reviewboard.kde.org/r/108513/ ) contains a patch to no longer trigger screen edges (but still corners) if there is an active full screen window on the same screen as the window.

Git commit ce4e3a66be365f90bd2e6b3a98290c9a6a61edc8 by Martin Gräßlin.
Committed on 31/01/2013 at 17:25.
Pushed by graesslin into branch 'master'.

Screen Edges may belong to fullscreen windows

Corners are still ours (it's a valid use case to still be able to switch
window through e.g. Present Windows even when running a fullscreen app).

How is it done? An Edge can be blocked and does no longer trigger if it
is blocked. For WindowBasedEdges the edge windows get unmapped in the
blocking case and mapped again when the blocking condition is no longer
valid.

The blocking is so far connected to:
* changes of active window
* changes of fullscreen windows

Whenever one of the events occurs it is checked whether there is:
1. an active client
2. it is fullscreen
3. on the same screen as the edge

If this is the case the edge will be blocked, otherwise unblocked.
FIXED-IN: 4.11

M  +42   -0    kwin/screenedge.cpp
M  +11   -0    kwin/screenedge.h
M  +4    -0    kwin/workspace.cpp

http://commits.kde.org/kde-workspace/ce4e3a66be365f90bd2e6b3a98290c9a6a61edc8