Why ?

To disable the hot corner easily.

But why do you want to disable the hot corner ?

Many users complain that the hot corner is too easy to activate. 

This is becoming more and more of an issue as all the menus are being moved into the global menu at the top of the screen. For example, a user goes up to choose the menu in nautilus, and the overview is activated in error. The position of the hot corner is obviously designed with Fitts' Law in mind to be easy to activate, but many times, it is *too* easy to activate when trying to hit something else in that region. 

Other users have complained that on multi-monitor setups, it is too easy to hit when navigating between monitors.

Even with the recent changes to how sensitive the hot corner is, i personally still activate the hot corner by accident many times in a day.

While this bug is not asking for the hotcorner to be disabled by default, it is just a request to get some standardized control for power users for this feature. Extensions need to be updated every release for changes to the API, and it would be much simpler to have a dconf option and an entry in the gnome-tweak-tool.

There are *many* different extensions that implement the configuration of hotcorners:

https://extensions.gnome.org/extension/151/hide_notification_bar/
https://extensions.gnome.org/extension/422/no-corners/
https://extensions.gnome.org/extension/309/hot-corn-dog/ 
https://extensions.gnome.org/extension/118/no-topleft-hot-corner/
https://extensions.gnome.org/extension/393/distraction-free/
https://extensions.gnome.org/extension/100/remove-activies/
https://extensions.gnome.org/extension/415/disable-corners/
https://extensions.gnome.org/extension/358/activities-configurator/
https://extensions.gnome.org/extension/157/left-message-tray/

Ok, this is a lot more useful information - I think we probably want to explore if we can make the hot corner work better before we just let the user turn it off, though.

One justification I could see allowing to turn off the hot corner is a11y scenarios with limited control of mouse positioning.

There have been some discussions about using pointer pressure for the hot corner once it becomes available (see e.g. bug 663661).

This is really needed now applications use headerbar...

Web is just unusable, as soon i want to click on previous button, i activate hot corner :-(

*** Bug 709566 has been marked as a duplicate of this bug. ***

I seem to recall that Jim Hall observed a fair amount of accidental hot corner triggering during his user tests. The problem, of course, is that:

1. A setting doesn't really solve the problem (since everyone who finds the hot corner to be troublesome will not turn it off). 

and 

2. Many users value the hot corner and use it a lot.

(In reply to Florian Müllner from comment #6)
> There have been some discussions about using pointer pressure for the hot
> corner once it becomes available (see e.g. bug 663661).

Mouse pressure could possibly be a good solution, depending on how it's calibrated. However, throughout the applications I use on my desktop, there are a lot of menus and buttons that appear near the top-left corner of the screen, so I imagine it would be hard to get it right. Mouse pressure would need to both avoid making the hot corner too easy to trigger accidentally, *and* avoid making the hot corner action feel slow. It's worth testing, but I don't think this should be something where the user feels like they need to be cautious about how quickly they move the mouse.

Personally, I find accidentally triggering hot corners too irritating, and don't see much advantage over *clicking* the Activities button instead, so I prefer to just disable them -- but I can see why some might like it. In Unity, and I think in some other desktops, you can configure multiple hot corners to do different things, which I guess is pretty neat. I think configuring (or disabling) hot corners should be an option in GNOME, rather than something that requires installing a shell extension.

I would rather see this as an option in GNOME Tweak Tool though, not dconf.

So, has there been any progress in the last year? I just tried disabling the No Hot Corner extension, and it seems like the Shell's hot corner behavior is the same as always.

Created attachment 353392 [details] [review]
layout: Make the hot corner optional

Whether people love or hate the hot corner depends in large extents
on hardware sensitivity and habits, which is hard to get right
universally. So bite the bullet and add an option to enable or
disable hot corners ...

There is a typo in the patch:

+      <summary>Enabale hot corners</summary>

Created attachment 353430 [details] [review]
layout: Make the hot corner optional

Thanks for the catch!

*** Bug 783571 has been marked as a duplicate of this bug. ***

Florian, your 353430 patch works for me (tested on gnome-shell 3.24.2). Since there is only one hot corner, should the gsettings schema be singular: enable-hot-corner ?

Ubuntu developers are interesting in disabling this feature especially because they may leave all the window control buttons on the left.

(In reply to Jeremy Bicha from comment #16)
> Since there is only one hot corner ...

Nope: https://git.gnome.org//browse/gnome-shell/tree/js/ui/layout.js#n354


(In reply to Jeremy Bicha from comment #16)
> Ubuntu developers are interesting ...

That's not a strong argument (neither for or against an option) to be honest. We've turned down requests from Fedora in the past when we didn't see them fit for upstream, I don't see why Ubuntu should get any special treatment just for being Ubuntu.

(In reply to Florian Müllner from comment #17)
> That's not a strong argument (neither for or against an option) to be
> honest. We've turned down requests from Fedora in the past when we didn't
> see them fit for upstream, I don't see why Ubuntu should get any special
> treatment just for being Ubuntu.

I don't think I was arguing that it ought to be done just for Ubuntu, only that there are Ubuntu developers who would appreciate this added option so thanks for considering it!

Would be great to remind Ubuntu developers that they were going to ship the upstream gnome experience...

(In reply to Matthias Clasen from comment #19)
> Would be great to remind Ubuntu developers that they were going to ship the
> upstream gnome experience...

To be fair, a popular-extensions internet poll they did was what triggered the discussion, but what convinced me that an option maybe would be the best option after all was:

 - Jakub's confession that the corner does get in his way more often than not
 - Carlos' reminder that a common feedback we get is that users out of habit
   throw the pointer into the top-left corner when not using GNOME

So this really is a love-it-or-hate-it feature, and I don't think we can come up with pressure thresholds that

 - don't trigger accidentally for people who hate it
 - don't make it overly hard to trigger for people who love it
 - work well with varying sensitivities of different mice/touchpads

I'd be happy if someone proves me wrong on this and the values can be tweaked to work for everyone (or at least most), as Allan's concerns in comment #9 are of course still valid ...

As a data point, Mac OS allows to configure hot corners (and disable them) from the system settings, and we also provide such an option on Endless, where we actually disable it by default (even though we have it in a different position).

(In reply to Allan Day from comment #9)
> The problem, of course, is that:
> 
> 1. everyone who finds the hot corner to be troublesome will not turn it off
> 
> 2. Many users value the hot corner and use it a lot.

Maybe a workable approach could be along those lines:

 1. add an option to enable the hot corners, off by default

 2. always add the hot corners, but don't make them trigger
    the overview when disabled

 3. when it looks like the users tries to use the hot corner
    while disabled (say, it is triggered twice in 10 seconds),
    ask them whether they want to enable hot corners via a
    notification

Of course if 3) is a one-off action (I imagine it would be, though maybe with the right heuristics it doesn't have to be?), the user is left a bit in the cold if they missed the banner the first time - and of course when they change their mind at a later time. Although at least they would know that an option exist they can start looking for ...

The problem with "off by default" is that existing installations on upgrade will get their hot corners disabled, because we don't have a mechanism to say "the default is off only on new installations".

I'd be in favor of leaving it on by default but easily disabled via tweak tool or maybe eventually in control-center.

(In reply to Emmanuele Bassi (:ebassi) from comment #23)
> The problem with "off by default" is that existing installations on upgrade
> will get their hot corners disabled, because we don't have a mechanism to
> say "the default is off only on new installations".

Oh, that's why the attached patch defaults to enabling the hot corner. IMHO "off by default" is only an option if we try to detect that the user intends to use the hot corner, and offer them to enable the option.

Thinking about it, we could also try to detect that the user triggered the hot corner accidentally, and offer them to turn it off.

You people should think about moving hot-corner to bottom-right. Bottom-right is pretty insensitive and almost nothing happens there. There no chance to trigger anything accidentally there.

Also letting user choose the corner will be nice too...although tweak-tool would be proper place for that.

No, separating the hot corner from the activities button doesn't make sense, so unless the button moves, the corner will stay where it is.

I received comments from users that the Activities Configurator was broken in a recent daily of Ubuntu 17.10 in the Ubuntu session.  In a 17.10 Gnome session it worked properly.  I set up 17.10 on a test system and verified their findings.  I looked at the patch provided in this bug report and found the hot corner is not built when the hot corner is disabled.  This broke my extension which has options to disable the hot corner or to increase the barrier pressure threshold to reduce inadvertent toggles of the overview.  From previous experience I believed the hot corner is needed to allow drag and drop from the desktop through the hot corner to the overview to an application in a different workspace.  I examined the code in layout.js Gnome Shell (3.25.91) and confirmed handleDragOver in the HotCorner class is needed to drag into the overview.  The patch breaks that ability.  As far as the breakage to my extension, it is fixable but messy with no hot corner existing when the hot corner is "disabled".

I have looked at the patch and believe it could be improved.  The problem is stopping the overview toggle only when called by the 'trigger' signal and the hot corner is disabled.

In layout.js var HotCorner = new Lang.Class...

@@

-   this._pressureBarrier.connect('trigger', Lang.bind(this, this._toggleOverview));
+   this._pressureBarrier.connect('trigger', Lang.bind(this, function() {
+       this._toggleOverview(true);
+   }));

@@
_toggleOverview: function(honorDisable) {
    if (this._monitor.inFullscreen)
        return;

+   if (!global.settings.get_boolean('enable-hot-corners') && honorDisable) {
+       return;
+   } 

    if (Main.overview.shouldToggleByCornerOrButton()) {
        this._rippleAnimation();
        Main.overview.toggle();
    }
},

@@
handleDragOver: function(source, actor, x, y, time) {
    if (source != Main.xdndHandler)
        return DND.DragMotionResult.CONTINUE;

-   this._toggleOverview();
+   this._toggleOverview(false);

@@
_onCornerEntered : function() {
    if (!this._entered) {
        this._entered = true;
-       this._toggleOverview();
+       this._toggleOverview(false);


You don't need:
+    global.settings.connect('changed::enable-hot-corners',
+                            Lang.bind(this, this._updateHotCorners));
+

You don't need:
+    if (!global.settings.get_boolean('enable-hot-corners')) {
+        this.emit('hot-corners-changed');
+        return;
+    }
+

Please consider these changes.  I did not make a patch to test.  The changes seem straight forward, but as always I could have missed something.

Norman L. Smith

(In reply to Norman Smith from comment #28)
> From previous experience I believed the hot corner is needed to allow drag
> and drop from the desktop through the hot corner to the overview to an
> application in a different workspace.

The super key still works, so the functionality isn't completely unavailable. It's clearly less convenient, but arguably that's always the case when disabling hot corners (move vs. move+click).

In general, I think that "turning off hot corners disables the hot corners" makes more sense than "turning off hot corners disables the hot corners except when dragging something".


> -   this._pressureBarrier.connect('trigger', Lang.bind(this,
> this._toggleOverview));
> +   this._pressureBarrier.connect('trigger', Lang.bind(this, function() {
> +       this._toggleOverview(true);
> +   }));

I'm not a fan of magic booleans - to figure out what "doSomeAction(true);" does, you have to jump to the function definition and look up the meaning of the parameter. So if we wanted to half-disable hot corners, this would be a better option:

this._pressureBarrier.connect('trigger', () => {
    if (this._settings.get_boolean('enable-hot-corners'))
        this._toggleOverview();
});

But then as mentioned above, I'm not convinced that keeping the hot corners partially enabled when turned off is a good idea ...

(In reply to Florian Müllner from comment #29)

Thanks for your reply to Comment #28.

>In general, I think that "turning off hot corners disables the hot corners"
>makes more sense than "turning off hot corners disables the hot corners except
>when dragging something".

The axiom "If it is not broke don't fix it." should be considered.

The issue with the hot corner is false switches to the overview.  I know of no
complaints concerning the ability to drag and drop via the hot corner. When
someone speaks of disabling the hot corner I think stopping the false switches
to the overview is the issue they want fixed.

>I'm not a fan of magic booleans - to figure out what "doSomeAction(true);"
>does, you have to jump to the function definition and look up the meaning of
>the parameter. So if we wanted to half-disable hot corners, this would be a
>better option:

>this._pressureBarrier.connect('trigger', () => {
>    if (this._settings.get_boolean('enable-hot-corners'))
>        this._toggleOverview();
>});


Consider.

-   this._pressureBarrier.connect('trigger', Lang.bind(this, this._toggleOverview));
+   this._pressureBarrier.connect('trigger', Lang.bind(this, function() {
+       this._toggleOverview(true);  // true, no toggle if hot corner disabled 
+   }));


handleDragOver: function(source, actor, x, y, time) {
    if (source != Main.xdndHandler)
        return DND.DragMotionResult.CONTINUE;

-   this._toggleOverview();
+   this._toggleOverview(false); // false, always toggle hot corner


_onCornerEntered : function() {
    if (!this._entered) {
        this._entered = true;
-       this._toggleOverview();
+       this._toggleOverview(false); // false, always toggle hot corner

Comments should expose the magic needed to not break what does not need
to be fixed.

Before you make a final decision please ask for the opinion of some of your
peers.

This patch seems like a good idea to me - I personally find the hot corner annoying (particularly the fact that extensions don't seem to be able to disable it properly).

Although dragging and dropping is probably not the action being done when users are annoyed, it seems surprising to me that users who disable the hot corners would try to drag and drop things through them. Pressing the windows key to activate the activities panel is what I usually do if I want to access the overview, and that works fine while dragging and dropping.

After 3 years using GNOME Shell, I changed my mind and disabling is not a solution for me.

>and don't see much advantage over *clicking* the Activities button instead

I just jump my mouse pointer to top left corner and go back to center of the screen to activate overview, no need to click anything, it's fast and cool to use...

But the accidental activation problem exists, no idea how to fix it.

I think pressing the windows button on the keyboard is a much simpler and faster thing to do than making the mouse go into the corner of the screen, so I never want to use a hot corner instead, although I know many users probably don't have this habit.

The reason I think I find it particularly annoying though is because I use more than one monitor. Typically my external secondary monitor is on the left of the primary display. This means that it has no status bar at the top of the screen, so if I run chrome maximised in that screen, its natural to expect that if I move my mouse to the top left corner of the screen I can click on the leftmost tab in chrome. Instead, the activities menu opens. Even now that I have mostly taught myself to avoid this, I often overshoot when trying to move the mouse towards the leftmost tab, or move my mouse around to find the cursor or to move paper out of the way of the mouse. Always I'm surprised and distracted when I hit the hot corner, and whatever I was reading or doing disappears until I work out what just happened.

Its also natural to expect that if I move my mouse from the primary monitor in the general direction of the secondary monitor, the mouse will go onto the secondary monitor. But there is a trap in the top left corner which will open the activities window. (perhaps it is a separate issue that this trap exists).

Anyway, I think the option to disable the hot corners would be a simple solution to a problem that is causing significant annoyance to many people (if the number of comments here is anything to go by: https://extensions.gnome.org/extension/118/no-topleft-hot-corner/)

*** Bug 705778 has been marked as a duplicate of this bug. ***

Comment on attachment 353430 [details] [review]
layout: Make the hot corner optional

Moved patch to gitlab:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/45