Closed nbolton closed 9 years ago
nbolton
commented
9 years ago I can confirm that when running the 1.3.6-r756 server on Windows 7 x64 and the 1.4.2-r756 client on OS X 10.6.4, that double-clicks are not registered on the Mac side.
nbolton
commented
9 years ago (I have not tested the inverse, however.)
nbolton
commented
9 years ago Same problem here running synergyc 1.5.0 on Mac OS X and server running Ubuntu Linux.
nbolton
commented
9 years ago Happens for me on client.
Server: Windows 7
Client: Mac OS X 10.6
nbolton
commented
9 years ago Same for me on client.
Server: Ubuntu 10.04 /w Synergy 1.3.1
Client: OSX 10.6.4 /w Synergy 1.4.2r-758
running that client version because of modifier keys bug in http://synergy-foss.org/pm/issues/2743
nbolton
commented
9 years ago I've noticed that if you just start clicking away on e.g. a folder icon, it eventually tends to work. Wonder if it's a timing issue of some sort?
Has anyone tried lowering the "Double-Click Speed" to see if that helps? Anyone know how to do this? I'm not much of a Mac-head myself, and can't seem to find the settings for the Synergy Mouse - all that shows up under System Preferences are settings for the Trackpad (on a MacBook Pro), with the Mouse panel saying there's no mouse connected... (And changing the Trackpad double-click settings don't appear to have any effect on things.)
Is there anything we Users can do to help move the investigation along? Any tests we can perform, any data we can collect, ...?
nbolton
commented
9 years ago I have a 13" MacBook (the plastic kind, not the aluminum unibody kind) and a generic windoze box. I'm running a 1.3.6-r756 server on Win7 and a 1.4.2-r756 client on my Mac. With the both machines' double-click speeds on their lowest settings, I still cannot invoke a double-click despite 6-8 clicks per second (which is actually a lot...try it sometime).
nbolton
commented
9 years ago I haven't measured my click-speed, but I can definitely get e.g. folders to open pretty consistently the faster I double-click . . . and not at all if I slow down just a little bit. This is using a 2.60 GHz dual-core E5300, 2 GB RAM machine running 32-bit Win7 as the server (running synergy 1.3.4), and a 15/17" 2.66 GHz Core 2 Duo 4 GB RAM MacBook Pro running OSX 10.6.4 as the client (also running synergy 1.3.4).
Is there a system-wide "double-click speed" setting on the Mac? The only one I could find was on the "Trackpad" System Preferences pane, which appears to be pretty Trackpad-specific. Or is there a special fake-hardware device that synergy creates, that might need to have this parameter adjusted?
I'm fairly convinced at this point that it's a "double-click speed" issue... Based on the Mac clock's second-hand it looks like I'm clicking at around 11-12 clicks-per-second.
nbolton
commented
9 years ago That may be true, but for those of us with laptops with no external mouse, it is difficult to test. If the solution is to adjust the setting, then we're out of luck (which doesn't seem like a solution to me).
nbolton
commented
9 years ago Just to confirm:
No matter how fast or slow i double click, i cannot manage to do it. I use osx 10.6.4 as client and as server.
I user synergy 1.5.0 (r758) on both client and server.
nbolton
commented
9 years ago I have the same problem, running 1.5.0r758. I have an iMac Server and a MacBookPro Client (both running 1.5.0r758). I tried connection a second mouse to the laptop and setting the double click speed to the lowest. This had no effect and I still could not double click, no matter how fast I clicked on the client. Both iMac and MBP running OSX 10.6.4
nbolton
commented
9 years ago I think we're using CGEventCreateMouseEvent incorrectly in the fakeMouseButton function of COSXScreen.cpp
We should be sending the double or triple click count along with the fake event via an included kCGMouseEventClickState. Unfortunately, I don't think the Synergy server actually tries to detect double and triple click events separately, so it doesn't have that data to pass along. Synthesizing it on the OSX client might require rolling our own process to coalesce button presses and some tricky timings, or the events could be injected using a lower-level API and let the OS handles it.
The following thread has some details about CGEventCreateMouseEvent and multi-click issues:
http://lists.apple.com/archives/quartz-dev/2007/May/msg00017.html
nbolton
commented
9 years ago If that is indeed the case, does that mean you'd have to read the doubleClickInterval yourself and generate your own double click event?
Single clicks still get sent though (before), right?
nbolton
commented
9 years ago having the same issue here. i'm running a 1.5.0 client on a 2010 macbook pro (osx 10.6.4) and a 1.3.4 server on gentoo linux (latest stable x86_64).
could it be that the latest mbp's w/ their trackpad doesn't necessarily recognize mouse doubleclicks until you setup a mouse?
nbolton
commented
9 years ago +1
client: osx 10.6.4 synergy 1.5.0
server: osx 10.6.4 synergy 1.5.0
Tried all sorts of mice/trackpad and various double click speeds both client and server, no change unable to double click. I recently upgraded from 1.3.1 where I did not have this problem.
nbolton
commented
9 years ago Update: Double click appears to work with itunes but not finder.
nbolton
commented
9 years ago I have discovered that iTunes does something non-standard in order to detect double clicks. See:
http://discussions.apple.com/thread.jspa?threadID=1665313
http://forums.macrumors.com/showthread.php?t=992864
It is the exception, not the rule (no other app seems to honor double clicks through Synergy).
nbolton
commented
9 years ago +1
Client: OSX 10.6.4 Synergy 1.5.0
Server: Windows 7 1.3.6
Is there any workaround for the time being ?
nbolton
commented
9 years ago just right click and select what would have been the action. e.g. in finder, i right click and select 'Open'.
nbolton
commented
9 years ago No, not "just right click and...."
First, see http://www.c2.com/cgi/wiki?JustIsaDangerousWord and http://fishbowl.pastiche.org/2003/10/07/just_is_a_fourletter_word/.
Second, this is a bug report, not a recommendation for inefficient work-arounds. This needs to be fixed.
nbolton
commented
9 years ago @Chris Brooks,
Was your "+1" in support of a previous comment, or is it in support of fixing this issue? If the latter, then please append your vote (do a search for "votes" on this page and click the number to the right of the header).
nbolton
commented
9 years ago @M B
Sorry it was just in support of fixing the issue.
I voted already, however in my request of a workaround I was referring to running a particular version rather than a shoddy fix.
Ill guess it'll 'just' have to do for now ^^
nbolton
commented
9 years ago My mistake. I was reading J Y's comments as standing alone, but now I understand them in context. My apologies.
nbolton
commented
9 years ago @M B
what a giant a-hole... don't critique my vocabulary usage when you can't even follow a thread correctly. i was offering on how to get around this issue until it's resolved. right click, left click is probably about a fraction of a second slower than double clicking after awhile, and it's faster than swapping input devices physically. however, i agree it's inefficient, but it's the best workaround for now until the bug is fixed in the source.
nbolton
commented
9 years ago Lets not have an argument.
There is a fixed build of 1.3.5 where double clicks work, the command keys work.
Its much better than the unstable 1.5.0 version I was running to have the command keys working.
It wasn't fixed by me and was passed to me by a friend but I have attached it here for your use if you wish!
nbolton
commented
9 years ago fair enough. just annoys me when i'm trying to help and it's met with snarkiness...
@chris: do you have the source code for that dmg build (1.3.5rc) of yours? if i have time, i'll to try and see where the click processing differs between the trunk of 1.5.0 and that build.
nbolton
commented
9 years ago I will try and find the source of the build and get back to you!
nbolton
commented
9 years ago Chris Brooks wrote:
Lets not have an argument.
Confirmed the build below allows for double clicks and command keys.
Server: Ubuntu 10.04 -> Synergys 1.3.1
Client: OSX 10.6.4 -> Synergyc 1.3.5There is a fixed build of 1.3.5 where double clicks work, the command keys work.
Its much better than the unstable 1.5.0 version I was running to have the command keys working.
It wasn't fixed by me and was passed to me by a friend but I have attached it here for your use if you wish!
nbolton
commented
9 years ago This is peculiar, but I actually can't reproduce this bug on my current setup here. I tried running the head of trunk, 1.4 and 1.3, and could not reproduce the issue on any of them.
Here's my setup, so anyone can point out what I am doing wrong here.
WinXP running trunk(r812)
MacOS running trunk(r812), head of 1.4(r752), head of 1.3(r751)
None of these exhibit the perpetually single clicking bug for me.
I have some code waiting to check in that should fix what it sounds like the problem is. I'm flying a little blind simply because I can't reproduce it, but maybe I'll get lucky.
The patches for each of trunk and 1.4 are attached to this ticket.
1.3 uses the older, deprecated CGPostMouseEvent API, which annoyingly provides no way to specify the number of clicks that have occurred so far. It might just be that the old API stopped working, and no one at Apple cares to fix it since its deprecated anyway.
It is worth noting that the COSXScreen in the patch is an Objective-C++ file, since the only place I found to grab doubleClickInterval was from NSEvent. Let me know if that poses problems for people as well.
nbolton
commented
9 years ago awesome ed!
i went ahead and applied the trunk.patch on my r812 1.5.0 and it worked! for nubs sake, the resulting recompiled binaries somehow ended up being the same md5sum on my machine and osx didn't want to copy over the old binaries in my bin dir. i deleted the old ones to allow the copy to proceed.
thanks.
now if only the mouse selection of the running windows would make the menubar update correctly... :/
nbolton
commented
9 years ago I can also verify that the attached patch applied to r812 on 1.5.0 appears to do the trick. I compiled 1.5.0-r812 as is and the bug was still present. I applied the patch and recompiled, and was able to perform double clicks.
Server: Win7 x64 1.3.6-r812
Client: OSX 10.6.5 1.5.0-r812 patched
now if only the mouse selection of the running windows would make the menubar update correctly... :/
J Y, can you explain what you mean by this? I'm not seeing the behavior you describe.
nbolton
commented
9 years ago @Ed, I noticed one odd bit of behavior with your patch. Some applications now register the following as a double-click (on the second event) where they did not before:
Event 1 @ T0:
Event 2 @ T1:
Where, T1 < T0 + double click interval and M != 0 and N != 0.
This can be easily seen in Mail.app. Try COMMAND-clicking two nearby messages in the message list. Make sure the second click is within the double-click interval. If executed locally, that series of clicks will merely select both messages in the list. Over Synergy (with your patch) the messages will be selected AND opened in separate windows.
What's interesting is that the Finder does not seem to exhibit this behavior with similar inputs. I'm assuming the Finder implements special logic to deal with this (kind of like iTunes' custom double-click handling).
nbolton
commented
9 years ago Apparently Redmine doesn't like my notation above. Here's another attempt:
Event 1 T0: [MODIFIER_KEY] + [CLICK X,Y]
Event 2 T1: [MODIFIER_KEY] + [CLICK X + M, Y + N]
Hopefully that makes things easier to read. Please let me know if my previous comment was confusing.
nbolton
commented
9 years ago M B wrote:
now if only the mouse selection of the running windows would make the menubar update correctly... :/
J Y, can you explain what you mean by this? I'm not seeing the behavior you describe.
how to repro on my setup (would be great to get an confirmation)...
i'll gladly open a new issue to avoid confusion if this is reproduceable. i haven't bothered doing a search for exiting issues with this problem description yet.
nbolton
commented
9 years ago @J Y, yes, please open another issue to keep this report clean and to track that issue separately. I can confirm (in part), but I will respond to that issue with specifics once you create it.
nbolton
commented
9 years ago @MB: Ah yes. Sounds like the code needs to be a bit more intelligent when any modifiers are down when the double click occurs. So for Mail.app, a double command-click sounds like it should be the same as two single command-clicks. Are there other apps out there that do something special when command double-clicking is involved. My hope is no, otherwise we start entering the world of special cases and trying to make on-the-fly tunable knobs, which is really quite hard to get right.
nbolton
commented
9 years ago @Ed, yeah, that was my fear. I've been noticing more and more of these. While I intuitively grasped them, I never realized how nuanced double-clicking was in some of these applications (like the Finder). I guess Apple really does put a huge amount of work into their UI design.
I'm not even sure if my original assertion (about changed location for the second click) is accurate. It might be the fact that the second click happens on a separate OBJECT (e.g., line item in Mail.app or on a separate icon in the Finder) from the first. I'm assuming this would be impossible (if not impractical) to detect from synergy.
nbolton
commented
9 years ago (As a side note, even if it was object-based, as I mentioned above, a shift in location between the first and second click might be a good enough proxy....)
nbolton
commented
9 years ago M B wrote:
@Ed, yeah, that was my fear. I've been noticing more and more of these. While I intuitively grasped them, I never realized how nuanced double-clicking was in some of these applications (like the Finder). I guess Apple really does put a huge amount of work into their UI design.
They are nuanced, but in different ways depending on the application, which is kind of annoying (See: the fact that iTunes kept working from an earlier comment). Having a separate set of click behaviors for each app a user clicks in isn't exactly a scalable solution, and I don't know that we'd be able to do that anyway. See below.
I'm not even sure if my original assertion (about changed location for the second click) is accurate. It might be the fact that the second click happens on a separate OBJECT (e.g., line item in Mail.app or on a separate icon in the Finder) from the first. I'm assuming this would be impossible (if not impractical) to detect from synergy.
It might not be impossible, but I think I crosses well into both the land of impractical and unadvised. We'd have to start hardwiring in characteristics about other application's graphical user interfaces. And we wouldn't exactly be behaving like a good OS citizen anyway, because now we're spying on other applications.
We can figure out a target process ID pretty easily, and then we can probably map that back to an application name. But that seems fragile, and would require data on each application available on the clients we support. That would only solve the problem, though, of where applications as a whole consume clicks in an odd way.
Ideas are welcome here. For now, I'll see about committing the patch as it is into trunk. At least it gets us part of the way there.
nbolton
commented
9 years ago @Ed,
I didn't mean to suggest that we should have special code to emulate every application's double-click behavior. I think that's error-prone and intractable. But, one of the most frustrating aspects of life WITH the patch is the quickly command-click two or more objects where the intent is to select them (e.g., in Mail.app or Finder.app), but where the effect is to open them. This reduces the efficiency (and increases the frustration level) of command-clicking by quite a bit. I have alternative suggestions for your patch in order to obviate this frustration:
1) Do not register a double click if any modifier keys are used. I understand this might break some esoteric UIs, but for the most part, there is no meaningful [MODIFIER]+DBL_CLK. This is not STRICTLY true, since CMD+DBL_CLK in the Finder opens the document if the location of the second click is the same as the first, but for the most part, SHFT-CLK or CMD-CLK toggles selections, and disallowing double clicking in the context is probably tolerable (or more tolerable than the patch in its current state);
2) In the alternative, if the location of the latest click is not the same as its predecessor, then do not register a double click, regardless of the modifier key state; or
3) Same as #2, but in addition, do not register a double click if the modifier state of the latest click has changed since the last click. This addition to your patch I believe would most CLOSELY mirror the behavior I've observed in most apps I've tested.
I hope this helps clarify my earlier observations/suggestions. Thanks for all the great work on this, by the way.
nbolton
commented
9 years ago @Ed,
I've been playing around more and more with your patch. There seem to be so many cases that aren't handled correctly, especially when clicking to indicate selection (e.g., of text, items in a list, Finder objects, etc.) that I think this patch may do more harm than good in its current state.
Don't get me wrong, it works completely as advertised, it's just that it seems to override dozens of behaviors that some users may have come to rely on. In addition, I'm concerned that, if this patch is applied, it may be considered "good enough" to not revisit for quite some time (which I think would be the worst result).
This is just my two cents after having had the opportunity to play with it for about a month.
--Matt
nbolton
commented
9 years ago M B wrote:
I didn't mean to suggest that we should have special code to emulate every application's double-click behavior. I think that's error-prone and intractable.
Didn't mean to suggest that you had pushed for that. I was throwing it out as an option that came to my mind, to make sure we have a public record of ideas considered in solving this problem, and why we think certain ones are not worth pursuing further.
But, one of the most frustrating aspects of life WITH the patch is the quickly command-click two or more objects where the intent is to select them (e.g., in Mail.app or Finder.app), but where the effect is to open them. This reduces the efficiency (and increases the frustration level) of command-clicking by quite a bit. I have alternative suggestions for your patch in order to obviate this frustration:
1) Do not register a double click if any modifier keys are used. I understand this might break some esoteric UIs, but for the most part, there is no meaningful [MODIFIER]+DBL_CLK. This is not STRICTLY true, since CMD+DBL_CLK in the Finder opens the document if the location of the second click is the same as the first, but for the most part, SHFT-CLK or CMD-CLK toggles selections, and disallowing double clicking in the context is probably tolerable (or more tolerable than the patch in its current state);
Any idea what these esoteric UIs would belong to? One of the problem with declaring certain UIs as esoteric is that it only seems that way until you commit the interaction patterns to muscle memory. At that point, it stops being esoteric, until some punk comes along and breaks your network-based input device sharing tool -- like me!
Maybe just throw the patch out there, and people let us know what breaks on their end? Maybe try one of other ideas first, and then patch this as well if those don't solve the problem.
2) In the alternative, if the location of the latest click is not the same as its predecessor, then do not register a double click, regardless of the modifier key state; or
I'd probably add some delta factor to how far the cursor needs to travel before we consider the location different, but yeah, this is a good idea. I'll see about tweaking the patch to do this.
3) Same as #2, but in addition, do not register a double click if the modifier state of the latest click has changed since the last click. This addition to your patch I believe would most CLOSELY mirror the behavior I've observed in most apps I've tested.
This is also doable pretty quickly.
If you don't see progress on either of these this week, give me another ping. I might've been roped into other work, but I will at least be reminded of this project.
nbolton
commented
9 years ago Esoteric is probably the wrong word. I think "nuanced" is probably more accurate. The Finder is probably one of the best examples of this, since it involves selection/invocation of different objects in several different settings. Just for fun, play around with different combinations of modifiers (especially COMMAND) and mouse locations between the first, second (and even third) clicks.
Another area to examine is text editing (see Mail.app or Text Editor.app). Single, double, and triple clicking can have different behaviors with different modifiers and if there are different locations between the first, second and third clicks.
I think these behaviors are probably widespread if they are captured in Apple's UI guidelines (although I do not know if they are). That being said, Microsoft Whatever probably breaks some of these conventions.
I like the delta idea. It seems like a decent compromise. I also like the idea of field-testing the patch with anyone who's willing to give it a go before committing it, since I certainly can't guarantee I'm covering all important use cases.
I know this and next week tend to be busy for folks, so I probably won't be so obnoxious as to "ping" anyone until at least after the new year.... :o)
But thank you for your time and attention in this. I realize you're not getting paid and doing it for the love of the thing, and as someone who benefits from your work, I wanted to make sure I said thanks.
nbolton
commented
9 years ago Just wanted to post an interesting discovery. I use Apple Remote Desktop to control dozens of computers at work. I have Synergy server running on my PC (Windows 7) and Synergy client running on my iMac (Snow Leopard). As noted above, double clicking does not work on the iMac. HOWEVER, when controlling a computer remotely through ARD on my iMac, double clicking works FINE.
Not sure what exactly this tells you, but thought it was worth noting.
nbolton
commented
9 years ago Llama Nerds wrote:
... through ARD on my iMac, double clicking works FINE.
You know, that is a very good observation. The open source VNC servers do this too. I dug into Vine Server's source (http://osxvnc.cvs.sourceforge.net/viewvc/osxvnc/) and see that they use the @CGPostMouseEvent@ API instead of the @CGEventCreateMouseEvent@ -> @CGEventPost@ pair. I'll try to do some hacking myself to see if I can get Synergy working with the other API, but that may a very simple and easy fix for this issue.
nbolton
commented
9 years ago @Matt
The reason why we don't use the CGPostMouseEvent API anymore is because it was deprecated as of Snow Leopard (10.6). This means it might vanish when Lion (10.7) is released, and will almost certainly vanish by the time whatever comes after Lion is released.
Even if we went back to using CGPostMouseEvent for the shorter term, which would not be very tricky at all, we would still need to find a solution to this problem for when we are forced back onto CGEventPost, due to the deprecated API vanishing entirely.
I'm sure the VNC guys will have to find a solution to this as well. Maybe they've already discussed it some on the mailing lists there?
nbolton
commented
9 years ago Thanks for the response, Ed.
Immediately after I posted that, I started implementing it and saw all those ugly deprecation warnings. Right you are. But it is terribly unfortunate. The buggy mouse handling in Synergy has been driving me crazy. For my own purposes, I will definitely be using the deprecated code until Apple pries it from my hands. That said, I completely understand your decision to not do so.
Has a RADAR bug report been filed with Apple? At its root, this is an API problem. If you have a RDAR number I will cite my submission as a duplicate. I'd be surprised to see them reverse directions on this, but it's definitely worth formally documenting the issue.
nbolton
commented
9 years ago So I've discovered a rather obnoxious twist on this bug while running synergy on my office box. To reproduce what I am seeing:
So this strikes me as a definitely RADARable bug. Synthesized mouse events should behave the same as non-synthesized. I can live without click counting, but living with hobbled app switching isn't doable.
Thoughts?
nbolton
commented
9 years ago Also: have a updated version of this patch I've been testing for the week that resolves the other couple of issues w.r.t. mouse drift. Will likely post that to this ticket this weekend.
nbolton
commented
9 years ago Ed Carrel wrote:
Also: have a updated version of this patch I've been testing for the week that resolves the other couple of issues w.r.t. mouse drift. Will likely post that to this ticket this weekend.
i mentioned this in note 37 above (http://synergy-foss.org/pm/issues/2763#note-37).
this is true even w/o the patch for me.
Imported issue:
Steps to reproduce:
Expected: Folder will open
Actual: Folder is selected but does not open
Versions (Synergy, OS):
Server: Synergy 1.4.2 r755 Mac OS 10.6.4
Client 1: Synergy 1.4.2 r755 Mac OS 10.6.4