I agree that we should strive to make WebKeyboardEvent look as much like PlatformKeyboardEvent as possible. The fact that it doesn't means that we have an extra layer of platform code (which Evan points out is at the wrong level) to map the fields from one to the other, rather than just being able to copy them one-for-one.
The good news is that WebKit already handles the different kinds of event streams depending on the event types; you just feed it the right type based on your platform and it'll pick the appropriate mechanism to make it work (at least from my minimal tracing through it last month). The key, pardon the pun, is picking the right fields and getting them filled in, which is where we need work done on WebKeyboardEvent. I disagree with Evan's characterization that Mac&Linux are "wrong", but that WKE was primarily done for Win and it's too restrictive to correctly handle the other platforms (at least Mac). One example is in the text stream of characters. WKE (previously, on win) assumed you'd only get 1 character from a message at a time. For Mac, we had to ifdef it to accept a string of characters from a single user event. PlatformKeyboardEvent, thankfully, already has the concept of accepting a string for input so now we just need to adjust WKE to be a String for this member variable, instead of just a single character. So why'd we ifdef the heck out of it instead of doing this in the first place? I recall a couple of us kicked it around a little bit and decided it was too early (esp with Linux not yet having thought much about its event model) to settle on an abstraction that may not have worked, and none of us were familiar enough with the end-to-end processes to guarantee it wouldn't have broken the world. Now that I personally have some more time to think, I like what Darin's suggesting as an approach. On Wed, Nov 12, 2008 at 7:28 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > The intent was for WebKeyboardEvent to mirror PlatformKeyboardEvent such > that conversion between the two was a simple as copying fields directly. > Generation of WebKeyboardEvent would then be done in a platform-specific > manner. > So, ideally event_conversion.cc would end up with zero #ifdefs. > Any problems with this approach? > -Darin > > On Wed, Nov 12, 2008 at 2:59 PM, Evan Martin <[EMAIL PROTECTED]> wrote: >> >> I spent some time studying the keyboard code and talking with various >> people and here's how I think it should work. This discussion also >> likely generalizes to other events. >> >> Some background: keyboard events on different platforms work >> (surprise!) differently: >> - On Windows you get some events when a key goes down, a series of >> events while the key is held, and another when the key is released. >> - On GTK you just have key-pressed and key-released. >> - Mac is surely some third thing. >> >> The stack of data structures and handling works like this: >> 1) At the bottom of the event food chain is the API expected by >> websites: for better or for worse, which events happen and what key >> codes are used are often based on Windows. WebKit internally handles >> forwarding events to the proper JavaScript, etc. handlers. >> 2) WebKit internally uses a PlatformKeyboardEvent structure to >> represent the data necessary for keyboard events. The WebKit ports >> include code to convert their respective platforms' events into the >> PlatformKeyboardEvent structure. >> 3) However, for Chromium we have the IPC system and sandbox: renderers >> don't have access to the platform-native event information. Instead, >> our glue library has a generic WebKeyboardEvent structure that >> represents a platform-generic keyboard event (matching >> PlatformKeyboardEvent), and we have code that knows how to serialize >> those over the IPC layer as well as convert them into >> PlatformKeyboardEvents. The latter conversion code lives in >> webkit/glue/event_conversion.*, and (here's the reason I'm writing >> this email) *should be platform-inspecific*. That is, all of the >> #ifdefs in there for Mac and Linux are in the wrong place. >> 4) Instead, WebKeyboardEvent knows how to convert platform-specific >> events into a plain WebKeyboardEvent. That code lives in >> webkit/glue/webinput_event*, and we already have platform-specific >> files for those. >> >> There's one additional twist particular to the way keys work: on some >> platforms (Windows) you get separate key down/up events and "character >> entered" events, while on others (GTK and I believe Mac) some of those >> are smooshed together. Internally in WebKit there's code to split a >> keyboard event into the two Windows types -- grep the WebKit code for >> "disambiguateKeyDownEvent". Then in >> WebCore/page/EventHandler.cpp:EventHandler::keyEvent it actually will >> split a single key press event into a series of key-down and >> character-entered events. >> >> In summary, our Mac and Linux code are definitely wrong, and I haven't >> yet studied the Windows code enough to verify it's correct either. :) >> >> > > > > > -- Mike Pinkerton Mac Weenie [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
