Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Control key unavailability due to 'browser hijack'
andrew_troup
Member, Mentor Posts: 1,584 ✭✭✭✭✭
I wonder if anyone can explain this to me in detail.
I'm puzzled, for instance, why Control-RMB works perfectly well, per the latest "Tips and Tricks" webinar (thanks, OnS!) as an alternative to middle mouse button for Pan;
Control-z and y work as usual,
Control-m gives us mate connectors,
and yet it seems OnS cannot use Control in other contexts, (notably with the left mouse button) to maintain the useful behaviours that we are used to for selection, copying and such.
Incidentally Control-RMB is very handy when doing a drastic reposition, I find. For instance, when rotating a large model, the point of interest soon heads off-screen. "Blipping" the Control key injects brief instances of "Pan", to reposition the model while it rotates.
I'm puzzled, for instance, why Control-RMB works perfectly well, per the latest "Tips and Tricks" webinar (thanks, OnS!) as an alternative to middle mouse button for Pan;
Control-z and y work as usual,
Control-m gives us mate connectors,
and yet it seems OnS cannot use Control in other contexts, (notably with the left mouse button) to maintain the useful behaviours that we are used to for selection, copying and such.
Incidentally Control-RMB is very handy when doing a drastic reposition, I find. For instance, when rotating a large model, the point of interest soon heads off-screen. "Blipping" the Control key injects brief instances of "Pan", to reposition the model while it rotates.
0
Best Answer
-
awk Member, Onshape Employees, Developers Posts: 78The javascript in the web client is at the mercy of the browser environment when it comes to handling keyboard input and modifier keys attached to mouse events. The landscape is unfortunately confusing because it varies between browser and OS combinations - so things that appear to work well in Chrome on Windows may not work well in Chrome on OS X. In the case of the two issues mentioned here the problems are : • The browser interprets control-click combinations as a hardwired alternative to using the secondary (right typically) mouse button. The event the browser receives is a mouse down event for the secondary button not a mouse down with control key down event for the primary button. In the context of single button mice in a world where a secondary click is required this makes sense - but it's annoying that it cannot be overridden or disabled in cases where the user has a two (or more) button mouse. • In the case of Command-Z this key event is 'grabbed' by Safari early on in the keyboard event handling and used for it's own purposes (if I had to guess Safari uses the usual Cocoa menu handling classes and they will grab this event themselves). This in turn means that the key event never makes it to the javascript - the Onshape browser client never even knew that you pressed that key combo. There's not a lot of change in the browser world in this space - 'gaming mouse mode' may help for some mouse interactions (and we're investigating it - but it's not without its own pitfalls). Grabbing significant common command key shortcuts also makes sense if the user and not the javascript/web page is in control - imagine how annoyed you'd be if a web page could prevent Cmd-Q from quitting the browser and you were stuck looking at dancing hamsters and listening to an annoying 8-bit synth pop tune?Director of API, Appstore, and App Partner Technical Support1
Answers
I would certainly buy one
Given what Onshape is poised to do for Mac (speaken as a Mac user since the Lisa, who was eventually driving into the scabby arms of Windows by 3D CAD) it doesn't seem a lot to ask that the Safari developers would add the tiny concession it would take to stop buggering up the Onshape UI.
Couldn't you guys drop into Cupertine with a box of chocolates and a baseball bat or something?
I know that Steve J has been officially sainted, but there were a few things he insisted on which time has proven too limiting, and for me the one-button mouse was always about four buttons short of a picnic. I was in heaven when the Intellimouse Explorer hit the market, and it was about then I started forgiving Bill Gates for MS-DOS. Now I just want Chromebooks to recognise extra buttons and render them programmable, INCLUDING simultating the Escape key
Follow-up question: if those burdens become unduly limiting, and when Onshape takes the world by storm, would it be out of the question to write a stripped-down browser for each popular platform, dedicated solely to doing a really good job of hosting Onshape?
I'm not suggesting OnS be taken in a direction which meant it could not run on conventional browsers, but this might be a way of enabling serious users not to suffer the compromises which proceed from that shotgun marriage.
I use qlikview to see our customers sales, without IE addon it's really clomsy but with addon installed it's really good and there is a lot of functionality that doesn't exist in ajax version (it's the only site I use IE for).
I do understand Ons policy to be same on every platform, but if it was my primary cad I would strongly second Andrew's thoughts on pro users not to suffer from any limitations that policy brings.