From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 26 Aug 2011 19:05:00 +0200 Message-ID: From: david jeannot To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] plan9port: cocoa programmer needed Topicbox-Message-UUID: 16034cb0-ead7-11e9-9d60-3106f5b1d025 > This sounds very cool. Did you figure out a way > to let acme move the mouse cursor the way it wants > to? Yes: Devdraw's setmouse() is implemented. Yesterday I said: "There is just the bare minimum". I should have said: "There is almost everything if you use OS X Lion". (There is still mouse support, the alt and cmd keys still simulate mouse buttons, etc.) A thing that annoy me since yesterday is that a cut (cmd+x) immediately followed by a paste (cmd+v) leaves a "clean" Acme's window "dirty". We could maybe send a cmd+u instead of a cmd+v when the fingers remain on the tactile device between the left-swipe and the right-swipe, that Acme would interpret as "Undo", if there is no simpler way. Or we could just use another gesture to copy (cmd+c), but there would be no feedback. Another thing that annoy me is that I receive swipe-up and swipe-down events only if I disable the OS X application BetterTouchTool, that I configured to instruct Google Chrome, and Google Chrome only, to create a new tab when I swipe-up, and to close the current tab when I swipe-down. Does anyone know how BetterTouchTool is implemented? A BetterTouchTool-like 9p server might be a good solution :)