Description of problem: GNOME 3.8 changed the hot corner and edge for Activities and Messages to use "pressure sensitivity" before activating. I believe this is some sort of mouse overshoot detection. This works fine on my system with a direct mouse, but I can't get the pressured activation to work as a synergy client. Version-Release number of selected component (if applicable): client: synergy-1.4.10-1.fc19.x86_64 server: synergy 1.4.12 on Win7 x64 (nothing in the changelog from 1.4.10-12 looks relevant...) How reproducible: 100% Steps to Reproduce: 1. Quickly move the mouse to the top-left corner for Activities. 2. Quickly move the mouse to the bottom edge for the Message Tray. (Note, the pressure required is greater on this one.) Actual results: Nothing. Expected results: 1. The Activities Overview is shown. 2. The Message Tray is revealed. (and both do work with a local mouse) Additional info: This client is configured on the left side, server to the right. I do have "switchCorners = none +top-right +bottom-right" and "switchCornerSize = 50", but removing that makes no difference. It does work if I set "relativeMouseMoves = true", but only while the cursor is locked in the client. Normally I leave it free to go between screens, so this setting is not a complete solution for me. I'm guessing that swapping so GNOME is the server and Win7 the client might also fix it, but that won't fit the way I use my computers. To see where GNOME is setting this, grep for PRESSURE in /usr/share/gnome-shell/js/ui/layout.js. I don't see any configuration to disable this new pressure sensitivity (short of editing that file), but if there's a way that would probably be an ok workaround for me.
I just found that there are fallbacks to earlier GNOME behavior if !global.display.supports_extended_barriers() in layout.js and messageTray.js. But mutter implements this function based on XIQueryVersion() >= 2.3, so I don't see a way to influence that. Maybe the XI_Barrier* events could be generated by synergy somehow?
Having the same issue. Trying to adjust 'hot corner threshold' with the Activities Configurator extension seems to have zero effect. I think if there is a way to disable the pressure sensitivity completely it'd work out better. It's making my workstation that I just upgraded to Fedora 19 harder to use. I'd have to think that remote connections via VNC could also be affected.
Workaround: Super + M brings up notification area on Gnome 3.8.4. Not sure about other versions. However, I agree that the actual issue needs to be resolved.
Right, there's Super+M for messages and Super alone for activities, and both of those still work on GNOME 3.10 too. Plus you can always click on Activities instead of relying on the hot corner, but these are just workarounds.
I tried adjusting the PRESSURE_THREHOLDs to 0 and even moving the barriers onto the screen. With the local mouse this works. I can active the message tray 5 pixels away from the edge of the screen with my hacks. Despite doing this it still doesn't work with Synergy. This leads me to believe that it's not based on mouse position but X server barrier events alone. I don't know much about the barrier support in X11, but maybe there is a way to disable that so it will fallback to the older method?
Based on some insight from comment #1 I found a hack/workaround to get the activities hot corner to work. If you change "!global.display.supports_extended_barriers()" to the constant "true" around line 1124 of /usr/share/gnome-shell/js/ui/layout.js it will bring back the old hot corner behavior which works with Synergy. A cleaner way to do this would be an extension that would add the top-left and bottom-right hot corners back regardless of the XInput version.
I made an attempt to enable a hot corner on the message tray for the bottom-right corner but I don't know enough about how mutter works so it hung the shell. Maybe someone else with more experience has an idea?
I found a workaround for the message tray as well using an extension called "Hi, Jack" from https://extensions.gnome.org/extension/645/hi-jack. It basically sets up PointerWatch callbacks that use just the mouse position. It could probably be adapted to handle the overview without needing the one line hack in layout.js. Maybe someone with more expertise than myself could create a new "Synergy" extension that will work for both corners without the need to change system files.
https://extensions.gnome.org/extension/637/move-free-message-tray/ returns behavior to pre-3.6. I haven't tried this yet as I'm at work, but I will tonight when I get home.
Can you post what you changed? (In reply to Eric Work from comment #6) > Based on some insight from comment #1 I found a hack/workaround to get the > activities hot corner to work. If you change > "!global.display.supports_extended_barriers()" to the constant "true" around > line 1124 of /usr/share/gnome-shell/js/ui/layout.js it will bring back the > old hot corner behavior which works with Synergy. A cleaner way to do this > would be an extension that would add the top-left and bottom-right hot > corners back regardless of the XInput version.
Created attachment 909797 [details] Patch to disable overview barriers The attached patch should disable barries and return hotcorner support for the top-left corner which opens the overview. Based on gnome-shell-3.10.4-5.fc20.x86_64
The patch attached in comment #11 and the hi-jack extension mentioned in comment #8 should allow synergy to work as before. As I mentioned before a new extension based on hi-jack that could also change the overview barrier would be ideal, but I don't have the expertise or time to create such an extension.
Thanks Eric!
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FWIW, while barriers still don't work with synergy on F22, it's less of a problem with notifications in the top panel. There are clickable targets for both activities and messages now.
I created an extension to "workaround" this issue. If you install my GNOME extension from https://extensions.gnome.org/extension/963/disable-barrier-support it will override the check for barrier support and force it to false. Then it simulates a monitor change to enable the old hot corner at the top left. Until synergy supports barriers (my guess would be never), then the best thing to do is to just disable them.
Nicely done, Eric, thanks!
I don't see us (Fedora users) being able to fix this and upstream from what I can tell doesn't seem to think barrier support is important. Given that I've created an extension to workaround the problem I think it's time to finally close this bug.
This bug is already closed, but I just wanted people following it to know that my extension still works on GNOME 3.20 and I've updated the extension page already with the new version. I'm using the latest stable version of Synergy and it doesn't work still without this extension.