Hi, The current Window event handling chain in Lite allows the main application to have callbacks being called before and after a specific box has handled an event (For the sake of simplicity I will only focus on keyboard events, but the same applies to mouse events).
Typically, you can define a keyboard event handler for a specific box: box.onKeyDown = event_cb And you can also use the following code to be called before and after a keyboard event has been processed by the box: lite_on_raw_window_keyboard( window, before_event_cb, user_data ); lite_on_window_keyboard( window, after_event_cb, user_data ); Now, only the first callback to be called has in fact the ability to stop the event to be passed to other handlers by returning DFB_FAILURE (the return values of other CBs are simply ignored, as you can see in window.c). This is an issue for WebKitDFB: The WebKitDFB library displays pages in boxes, and a specific keyboard handler is defined for each box. This handler calls in turn the page keyboard event handler in WebCore. According to the standard, any web page displayed by a browser should have the ability to prevent it from performing any default action by calling evt.preventDefault() on the captured DOM event. The simplest implementation of the preventDefault behaviour is to test the return value of the page event handler and return DFB_FAILURE if evt.preventDefault() has been called (in that case the WebCore function returns true). Now, what happens if the main application using the library has defined an "after_event_cb" using lite_on_window_keyboard to perform extra actions after the event has been handled by the page (like activate scrolling if up/down has been pressed) ? Since the return value of the box event callback is never tested, the after_event_cb will always be called (and the preventDefault flag is thus ignored). And this is _bad_ ... I would therefore suggest an evolution to Lite to actually test the return value of the box event cb, and only call the "after" handler if the result is DFB_OK (just like it is done for the "raw" event cb). What do you think ? Best Regards David Corvoysier France Telecom / Orange Labs Note: In the basic WebKitDFB browser application, it is actually worse, as the lite_on_raw_window_keyboard is used to perform scrolling on up/down, and it swallows the event. As a consequence, up & down keys cannot be used in any web pages ...
_______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
