Imported issue:
THIS IS NOT FOR SUPPORT, PLEASE USE
"http://groups.google.com/group/synergy-plus":http://groups.google.com/group/synergy-plus
NO NEED TO SUBSCRIBE TO THE GROUP TO RECEIVE ANSWERS.IMPORTANT: Please research your problem thoroughly before opening
a new ticket. The following tips are provided to help you.Tips:
- Please ensure that all labels below are correct.
- It may be useful to attach debug output ("http://tinyurl.com/y9w4t5h":http://tinyurl.com/y9w4t5h )
- Have you searched for an existing or similar issue?
- If you have a question, please post on the mailing list.
- Have you selected the correct issue template?
Note: You can delete the above text block before posting.
What list of steps will reproduce the problem?
Install & run synergy on two mac os x 10.6
What version of operating system, and Synergy+ are you using?
server - Mac OS X 10.6.4
client - Mac OS X 10.6.3
What is the expected behaviour, and what happens instead?
The horizontal scrolling appears kinda 'inverted': when scrolling to the left on the server machine, picture or anything else scrolls to the right on the client and vice versa.
Server machine is a MacBook with multitouch touchpad which supports scrolling in any direction.
Is there a way of temporarily working around your problem?
I've not found it
Would you like to solve the problem yourself and submit a patch?
I do not know how
Forget to mention, Synergy+ version 1.3.5, running with SynergyKM
Sounds like a weird bug. More info needed though.
Please ignore this update. Just cleaning up issue status list.
Same issue still exists with both machines running Mac OS X 10.8.4 and Synergy 10.4.12 Beta.
Marking this as an Enhancement because I believe this should be an option. I don't think this should be forced one way or the other.
I think this issue should be marked as a bug since it still exists and it has nothing to do with Mac OS X's 'natural' scrolling option. If the 'natural' option is toggled the vertical scrolling direction changes on the client as well (as expected) but the horizontal direction switches as well, so again: it scrolls in the opposite direction as it does on the server.
Server
iMac 27" 3.5GHz i7 / 8GB RAM / 500GB SSD (Late 2013)
Mac OS X 10.9.3
Synergy Pro 1.7.2 (without SSL encryption because that does not work)
Apple Magic Mouse / Apple Mighty Mouse / Generic Mouse
Client
MacBook Pro 15" Unibody 2.53GHz Core 2 Duo / 8GB RAM / 2x 500GB SSD (Late 2008)
Mac OS X 10.8.5
Synergy Pro 1.7.2
Apple Mighty Mouse / Built-in Apple Trackpad / Generic Mouse
I'm experiencing this too. Since the horizontal scrolling doesn't behave like the vertical scrolling, at least from a UX perspective I agree with @ruudwelten in calling it a bug.
This is definitely 100% a bug. No reason to make it an option, control is had through the 'natural scrolling' option.
I too am experiencing this, is there any update on potential fix ?
Caving in to the pressure and changing the status to "bug" :)
This has just started happening to me as well. Not sure what caused it. Yesterday it was working, today it's not :/
reintstalling synergy on both machines didn't fix it
Anyone find a fix?
bug. no need for option. just please put a negative sign in there and make a new build?
Ditto on the problem. iMac Late 2015 (server) to rMBP Late 2013 (client) using magic mouse. Synergy version 1.8.2-stable-36cd521 built 2016 September 02.
Facing the same problem. I've been building Synergy on OS X from source locally; on the v1.8.2-stable branch, I made these changes and distributed to clients - this seems to have fixed it for now, but like others, it wasn't previously a constant problem for me, so grains of salt and all. I'll update if it later fails.
@davecotter - more like remove some negative signs ;)
diff --git a/src/lib/platform/OSXScreen.cpp b/src/lib/platform/OSXScreen.cpp
index a216dc1..b85b3ab 100644
--- a/src/lib/platform/OSXScreen.cpp
+++ b/src/lib/platform/OSXScreen.cpp
@@ -671,7 +671,7 @@ OSXScreen::fakeMouseWheel(SInt32 xDelta, SInt32 yDelta) const
CGEventRef scrollEvent = CGEventCreateScrollWheelEvent(
NULL, kCGScrollEventUnitLine, 2,
mapScrollWheelFromSynergy(yDelta),
- -mapScrollWheelFromSynergy(xDelta));
+ mapScrollWheelFromSynergy(xDelta));
// Fix for sticky keys
CGEventFlags modifiers = m_keyState->getModifierStateAsOSXFlags();
@@ -1022,7 +1022,7 @@ OSXScreen::handleSystemEvent(const Event& event, void*)
}
if (xScroll != 0 || yScroll != 0) {
- onMouseWheel(-mapScrollWheelToSynergy(xScroll),
+ onMouseWheel(mapScrollWheelToSynergy(xScroll),
mapScrollWheelToSynergy(yScroll));
}
}
I'm still running into this issue, and it's pretty annoying.
Also having this issue... and as its been bugged for 2.5 years its kind of frustrating that its not fixed (and hasn't been updated for 6 months)... sorry for being that guy #sorrynotsorry
Installed 1.8.4 and still have the issue. Is the fix for this more complicated that just inserting a minus sign in the right place?
+1 hoping this can get fixed
On Thu, Mar 9, 2017 at 8:27 AM James Mason notifications@github.com wrote:
Installed 1.8.4 and still have the issue. Is the fix for this more
complicated that just inserting a minus sign in the right place?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/617#issuecomment-285402331,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAyb-0g3vHviZGmHXla1t5JHtnZ4xqP2ks5rkCiGgaJpZM4Ct1S8
.
Still an issue in 1.8.7-stable. Server/Client both running macOS Sierra 10.12.3.
Appears to always follow the inverse of the 'natural scroll' setting on the server. Client 'natural scroll' setting has no effect.
+1
+1
+1 for this feature as well. This is pretty much a show stopper for daily use if you are a Mac user.
2010-07-24 is the first date in this thread... It's been redefined as a bug over two years ago! How is this still not fixed? I've bought multiple versions but am still having this issue.
it's not fixed because this app is abandoned by the developer
I don't understand why this bug has been closed. I purchased this product two days ago and still has this issue ( version 1.11.1)
@nbolton please re-open this bug, it has been here for ages, has gotten dozens of complaints. just because no dev ever took it up does NOT mean users don't want it fixed!
Same issue here.
Same issue here!
Same issue also here :-) OMG this was first mentioned 7 years ago ?
Same issue here, really disrupts my workflows 😔
The fix for this problem is in progress, it will be included in 1.14.1
SYNERGY-988
Most helpful comment
I don't understand why this bug has been closed. I purchased this product two days ago and still has this issue ( version 1.11.1)