Cappuccino Cappuccino → 0.5.1

Comments and changes to this ticket

• You flagged this item as spam.
  

  ronin-13570 (at lighthouseapp) September 6th, 2008 @ 10:16 PM

  The ones you've listed will work for me as I use safari but they're not sufficient for Firefox, IE, Opera, etc.

  I think it's very dangerous to presume anything about keystrokes and I'm pretty sure that on IE for example, you can't actually prevent or intercept certain keystrokes such as alt+f.

  Why not just allow unhandled keystrokes to go through to the browser irrespective of what they are? What's the downside?

• You flagged this item as spam.
  

  mickbuddha September 7th, 2008 @ 09:50 AM

  I understand that they are not sufficient for browsers other then Safari, thus the ticket. I am not sure if there is a downside, or if it possible, but boucher has said that they decided upon using a white list. I do not know the inner workings of the key event handler in obj-j, but it may not be possible to check if an event is actually used. Again, I'm not a fan of whitelisting every keystroke we can think of, but I'm saying that there should be more then there is.

  This came out of me checking out 280slides, and trying the change windows. I hit command-and nothing happened. They were not using the command for anything, they had just not though of passing it to the browser.

• 

  Francisco Tolmasky September 8th, 2008 @ 09:59 AM

  I'd like to see a solution that takes into account key equivalents. For example, if there is a menu item that has its key equivalent set to cmd+N, then eat it obviously, if not, don't.

• 

  Tom Robinson September 8th, 2008 @ 10:17 AM

  I think this needs to be changed to "whitelist" everything by default and let the app developer "register" for the keys he's interested in, or at least make that an option. We'll never be able to predict exactly which key combinations are important for each browser and each user.

  For example, in Safari I like to hit command-option-C to bring up the web inspector. This probably isn't common among web users, but I do it all the time and it's maddening to not be able to do it, even though the Cappuccino app most likely doesn't need the command-option-C shortcut for anything. Sure you could whitelist that particular one, but there's dozens of others that other people might want.

• 

  Francisco Tolmasky September 8th, 2008 @ 10:18 AM

  That's the idea behind examining key equivalents. If the developer gives a menu item the command+N key equiv, clearly he wants to receive it. He shouldn't then additionally have to call REGISTER_ON_WHITELIST("N", CPCommandKeyMask);

• 

  Tom Robinson September 8th, 2008 @ 10:25 AM

  Yeah, I think we're using the term "whitelist" differently. I took it to mean "add key combos you don't want Cappuccino to eat to the whitelist" and I think you're saying "add key combos you want Cappuccino to eat to the whitelist".

  Whitelist implies we only let certain ones through, but from which perspective, the browser or Cappuccino? We could be letting them through from the browser to Cappuccino, or letting them through from Cappuccino to the browser.

  Either way, I think we agree that by default all key combos should be let through to the browser, and only ones that are registered explicitly by the app developer, or detected as being a key equivalent in a menu, should be "eaten" by Cappuccino.

  What about simple keypresses (a, b, c...)?

• 

  Francisco Tolmasky September 8th, 2008 @ 10:28 AM

  Simple key presses have to be "eaten" by cappuccino, if not text will never work. You shouldnt have to register for the alphabet in a view that expects keystrokes. It's not a big deal to eat them since they generally don't do anything anyways.

• 

  Ross Boucher September 8th, 2008 @ 02:37 PM

  I've attached the proposed change. Here's the example usage, taken from 280 Slides:

  
      // Set up the keys that we want to prevent defaults for
  
      var characterKeys = ['s', 'o', 'n', 'b', 'i', 'u', 'a', 'e'];
      [[CPDOMWindowBridge sharedDOMWindowBridge] preventCharacterKeysFromPropagating: characterKeys];
  
      var keyCodes = [37, 38, 39, 40];
      [[CPDOMWindowBridge sharedDOMWindowBridge] preventKeyCodesFromPropagating: keyCodes];
  

• 

  Ross Boucher September 8th, 2008 @ 02:38 PM

  Should have noted previously that you can prevent both character keys, and key codes. So, if I want to use command/ctrl + b in my app, I can register for 'b'. If I want to use command/ctrl + left arrow, I can register for the left arrow key code (37).

• 

  Tom Robinson September 8th, 2008 @ 02:45 PM

  Shouldn't you register for combinations of keys? (i.e. with meta, ctrl, etc)

• 

  Ross Boucher September 8th, 2008 @ 02:55 PM

  These only apply to command/ctrl. We capture everything else. it's not worth the effort (at least not right now) to try to do anything more complex.

• 

  Francisco Tolmasky September 8th, 2008 @ 05:10 PM

  • State changed from “new” to “resolved”

  (from [1d5b9e6b7d415d86116ae8f00f899ff5ecf69014]) Stop catching all command keys, instead set up a blacklist of keys to stop.

  [#19 state:resolved] http://github.com/280north/cappu...

• 

  Francisco Tolmasky September 13th, 2008 @ 01:14 PM

  • Assigned user set to “Ross Boucher”
  • Milestone set to “0.5.1”