[webkit-dev] need help with adding javascript commands to browser.
Hi there, I've generated WebKit/Source/WebCore/page digiplayer.cpp digiplayer.h and digiplayer.idl The idl file looks as follows module window { interface [ LegacyDefaultOptionalArguments, OmitConstructor ] digiplayer { void videoSetup(in DOMString url, in boolean play_immeadiately, in boolean eject_on_finish, in long x, in long y, in long width, in long height); }; } will LegacyDefaultOptionalArguments support the 7 arguments or will I need to do a Custom argument handler. I'm using the browser in an embedded mips linux platform. The code is linking to build/WebCore/libwebcore_efl.a but not managing to do the final link to build/WebKit/libewebkit.so Any help would be greatly appreciated God bless. D.J. Barrow Linux kernel developer email: dj_bar...@ariasoft.ie Mobile Ireland: +353-86-1715438 www.travelsmart.ie, everyones favourite carpool website, works beautifully on the apple iphone www.warehog.com, you thought ebay was good www.ariasoft.ie, See my GPL contributions___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote: Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819) --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 96818) +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 96819) @@ -113,6 +113,14 @@ ZeroedInStopLoadRequest, ZeroedInNotifyFinished, } m_cachedScriptState; + +// We grab a backtrace when we zero m_cachedScript, so that at later crashes +// we'll have a debuggable stack. +enum { +MaxBacktraceSize = 32 +}; +int m_backtraceSize; +void* m_backtrace[MaxBacktraceSize]; }; This appears to increase the size of each ScriptElement instance by 256 bytes. I don’t know how bad a performance hit this is in real-world use, but it is most certainly not something all vendors would like to include in their releases. The way this change was made, however, it is almost inevitable that a vendor would end up unknowingly shipping this performance regression. This change was made on trunk, it is unconditionally compiled in, and there is nothing obvious tracking undoing this change. I think this is the wrong way to incorporate diagnostic code into WebKit.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
Dan, You're right. I'm adding #if PLATFORM(CHROMIUM) to this change shortly. - Gavin On 6 October 2011 13:07, Dan Bernstein m...@apple.com wrote: On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote: Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819) --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 96818) +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 96819)@@ -113,6 +113,14 @@ ZeroedInStopLoadRequest, ZeroedInNotifyFinished, } m_cachedScriptState;+ +// We grab a backtrace when we zero m_cachedScript, so that at later crashes +// we'll have a debuggable stack. +enum { +MaxBacktraceSize = 32 +}; +int m_backtraceSize; +void* m_backtrace[MaxBacktraceSize]; }; This appears to increase the size of each ScriptElement instance by 256 bytes. I don’t know how bad a performance hit this is in real-world use, but it is most certainly not something all vendors would like to include in their releases. The way this change was made, however, it is almost inevitable that a vendor would end up unknowingly shipping this performance regression. This change was made on trunk, it is unconditionally compiled in, and there is nothing obvious tracking undoing this change. I think this is the wrong way to incorporate diagnostic code into WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
I agree that this seems like something to #ifdef. Out of curiosity, did you just stumble upon this, or did you actually notice a measurable performance regression from this? -Darin On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein m...@apple.com wrote: On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote: Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819) --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 96818) +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 96819)@@ -113,6 +113,14 @@ ZeroedInStopLoadRequest, ZeroedInNotifyFinished, } m_cachedScriptState;+ +// We grab a backtrace when we zero m_cachedScript, so that at later crashes +// we'll have a debuggable stack. +enum { +MaxBacktraceSize = 32 +}; +int m_backtraceSize; +void* m_backtrace[MaxBacktraceSize]; }; This appears to increase the size of each ScriptElement instance by 256 bytes. I don’t know how bad a performance hit this is in real-world use, but it is most certainly not something all vendors would like to include in their releases. The way this change was made, however, it is almost inevitable that a vendor would end up unknowingly shipping this performance regression. This change was made on trunk, it is unconditionally compiled in, and there is nothing obvious tracking undoing this change. I think this is the wrong way to incorporate diagnostic code into WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
On Oct 6, 2011, at 10:12 AM, Darin Fisher wrote: I agree that this seems like something to #ifdef. Out of curiosity, did you just stumble upon this, or did you actually notice a measurable performance regression from this? I just noticed the patch go by. -Darin On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein m...@apple.com wrote: On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote: Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819) --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 96818) +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 96819) @@ -113,6 +113,14 @@ ZeroedInStopLoadRequest, ZeroedInNotifyFinished, } m_cachedScriptState; + +// We grab a backtrace when we zero m_cachedScript, so that at later crashes +// we'll have a debuggable stack. +enum { +MaxBacktraceSize = 32 +}; +int m_backtraceSize; +void* m_backtrace[MaxBacktraceSize]; }; This appears to increase the size of each ScriptElement instance by 256 bytes. I don’t know how bad a performance hit this is in real-world use, but it is most certainly not something all vendors would like to include in their releases. The way this change was made, however, it is almost inevitable that a vendor would end up unknowingly shipping this performance regression. This change was made on trunk, it is unconditionally compiled in, and there is nothing obvious tracking undoing this change. I think this is the wrong way to incorporate diagnostic code into WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Always-on diagnostic code Re: [webkit-changes] [96819] trunk/Source/WebCore
On Oct 6, 2011, at 10:11 AM, Gavin Peters (蓋文彼德斯) wrote: Dan, You're right. I'm adding #if PLATFORM(CHROMIUM) to this change shortly. Thank you. - Gavin On 6 October 2011 13:07, Dan Bernstein m...@apple.com wrote: On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote: Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 = 96819) --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev 96818) +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev 96819) @@ -113,6 +113,14 @@ ZeroedInStopLoadRequest, ZeroedInNotifyFinished, } m_cachedScriptState; + +// We grab a backtrace when we zero m_cachedScript, so that at later crashes +// we'll have a debuggable stack. +enum { +MaxBacktraceSize = 32 +}; +int m_backtraceSize; +void* m_backtrace[MaxBacktraceSize]; }; This appears to increase the size of each ScriptElement instance by 256 bytes. I don’t know how bad a performance hit this is in real-world use, but it is most certainly not something all vendors would like to include in their releases. The way this change was made, however, it is almost inevitable that a vendor would end up unknowingly shipping this performance regression. This change was made on trunk, it is unconditionally compiled in, and there is nothing obvious tracking undoing this change. I think this is the wrong way to incorporate diagnostic code into WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
Hi Anders, Thanks for your reply. Yes, you are correct. This padding would be between the content and the overhang area. Thanks, Fady On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.com wrote: Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
Do you envision this being useful on overflow:scroll regions as well or is it just frames? If it's just frames, then it seems like something we could keep in ScrollView? (I haven't looked at the patch yet). - Anders On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote: Hi Anders, Thanks for your reply. Yes, you are correct. This padding would be between the content and the overhang area. Thanks, Fady On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.com wrote: Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)
Hi Anders, At this point in time, we see no reason to allow for non-zero padding in overflow:scroll regions because you can always just move the page into a unobstructed area and then scroll through that overflow region. Thanks, Fady On Thu, Oct 6, 2011 at 1:43 PM, Anders Carlsson ander...@apple.com wrote: Do you envision this being useful on overflow:scroll regions as well or is it just frames? If it's just frames, then it seems like something we could keep in ScrollView? (I haven't looked at the patch yet). - Anders On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote: Hi Anders, Thanks for your reply. Yes, you are correct. This padding would be between the content and the overhang area. Thanks, Fady On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.comwrote: Hi Fady, so if I'm understanding correctly, in the context of rubber-band scrolling, this padding would be between the content and the overhang area? As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and just have two scroll functions, one that constrains to the content edge and one that doesn't. - Anders On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote: Hi all, We'd like to provide a general mechanism in WebKit for embedders to scroll page content so that it is not hidden by embedder-provided UI elements that overlap the page. In some cases, if a floating UI element overlaps the edge of the page, we'd like to allow the embedder to scroll beyond the edge of the page to allow the hidden content to move to an area that isn't overlapped by UI elements. This feature is orthogonal to rubber band scrolling. One approach we considered taking is to allow the platform to set scroll padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of the page. As a more concrete example, one can imagine a persistent Chromium extension that floats above the edge of the page. A link may lie behind the floating window. That link would be inaccessible unless the page is allowed to scroll beyond its edge. An experimental and incomplete implementation of this idea can be found here: https://bugs.webkit.org/show_bug.cgi?id=68184 After some additional consideration since this patch was posted, I don't believe scroll padding should interact with ScrollView::constrainsScrollingToContentEdge the way it does in the patch. Instead, I feel that scroll padding should be ignored if constrainsScrollingToContentEdge is false. That way rubber band scrolling is not affected at all by this. What are your thoughts and suggestions? Is this feature sufficiently general to be implemented in WebCore? What are your thoughts about its interaction with ScrollView::constrainsScrollingToContentEdge? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.com wrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov a...@webkit.org wrote: I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? Would you mind raising this concern in the relevant standards body (in this case, webevents-pub...@w3.org seems to be relevant)? Debating issues with standards on webkit-dev is unproductive - it does not include all parties who have an interest, in particular other browser vendors and web developers, and it does include a lot of WebKit developers who probably aren't interested. - James - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov a...@webkit.org wrote: I share Simon's concern that that providing low level access to every possible controller creates fragmentation, with purportedly HTML content that only works on a few devices. There is no clear cut border here - it's been mentioned that even touch events can be seen as rare - and then I advocate that adding more mouse specific events is a bad idea for the same reason. Isn't a balance of usefulness vs fragmentation vs trusting developers? When touch events are exposed, I'd expect that developers who care about having a board appeal will have alternatives for users without a touch interface but having a web page be able to respond to touch events seems useful for web pages to do to shine in that context. (In fact developers are inclined to provide this other interface to have the broad appeal.) Doesn't the same thing apply to these other cases? dave As we add joystick/gamepad support, should steering wheels be next on the agenda? 3d mice? - WBR, Alexey Proskuryakov 06.10.2011, в 10:01, Darin Fisher написал(а): This proposal has matured somewhat, so an update is in order. FYI: http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html http://www.w3.org/2010/webevents/charter/2011/Overview.html We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is also building a prototype of this API. We are doing development on the trunk (disabled by default) so that we can more easily solicit game developers for feedback using our existing Chrome distribution channels. This feature should have a very light touch on existing cross platform code. We encourage folks to share feedback on the API design to webevents-pub...@w3.org. Regards, -Darin On Wed, Aug 24, 2011 at 9:19 AM, Simon Fraser simon.fra...@apple.comwrote: I think it's too early to implement this. We should wait until it's a W3C draft at least. window.addEventListener(MozJoyConnected..), really? Simon On Aug 24, 2011, at 8:36 AM, Scott Graham wrote: Hi, I wanted to let everyone know that I propose to add a new feature flag, JOYSTICK. http://webkit.org/b/66859 This flag will enable an API and events for accessing joysticks and related devices. There's a prototype effort happening in Mozilla also (https://wiki.mozilla.org/JoystickAPI), and the design is intended to be similar. As it will not necessarily make sense for all ports, nor be implemented immediately in all ports, a feature flag seems appropriate. Please let me know if you have any concerns or comments. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Reading from Object
In RenderBlockLineLayout.cpp, I'm trying to read face of the font from pointer to a structure named f below: RenderText* t = toRenderText(o); const Font f = t-style(firstLine)-font(); the data I need exist in: f.m_fontlist.m_ptr-m_cachePrimarySimpleFontData-m_platformData.m_face I have tried all the ways I could think of but either I got errors when adding headers to the above file or couldn't read the face value or the m_ptr being private. Can you please show me a way to reach there? It might be my lack of knowledge of C++ Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
06.10.2011, в 11:12, James Robinson написал(а): Would you mind raising this concern in the relevant standards body (in this case, webevents-pub...@w3.org seems to be relevant)? Debating issues with standards on webkit-dev is unproductive - it does not include all parties who have an interest, in particular other browser vendors and web developers, and it does include a lot of WebKit developers who probably aren't interested. My interest is in avoiding immature and/or harmful specs in WebKit. Investing work into improving specs is not the only possible outcome of discussing them on webkit-dev - for example, we can just decide to not take them, or to work with another W3C working group. 06.10.2011, в 11:14, David Levin написал(а): Isn't a balance of usefulness vs fragmentation vs trusting developers? Yes, certainly so. As I see it, the reasons for Web apps popularity and even continued existence are: - Opening Web apps is easy and safe, users and sysadmins don't need to take precautions associated with installing native applications. - One can access any Web app from any browser. As we all know, neither of these is achieved with anything close to absolute fidelity today, but these are nonetheless platform strengths. I don't want to take a particularly strong stance against Joystick/Gamepad specifically, but I see codifying input device fragmentation in Web specs and APIs as a move in a wrong direction. When touch events are exposed, I'd expect that developers who care about having a board appeal will have alternatives for users without a touch interface but having a web page be able to respond to touch events seems useful for web pages to do to shine in that context. (In fact developers are inclined to provide this other interface to have the broad appeal.) Myself, I've been annoyed a few times when visiting some phone specific sites using a desktop browser. It will likely become more common. That said, there is a difference. Touch events are fundamental and usable for many kinds of interfaces. Game oriented input devices are meant for much fewer uses, so there can be hope of getting a meaningful universal API for them. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] need help with adding javascript commands to browser.
I'm not sure Digiplayer is some sort of web standards we want to implement in WebKit project. See http://www.webkit.org/contact.html, this kind of question should have been sent to webkit-help first. -- Ariya Hidayat, http://ariya.ofilabs.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 11:50 AM, Alexey Proskuryakov a...@webkit.org wrote: I don't want to take a particularly strong stance against Joystick/Gamepad specifically, but I see codifying input device fragmentation in Web specs and APIs as a move in a wrong direction. Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. I could be misinformed, but it would be nice for you to be concrete about precisely what parts of the spec are currently problematic. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 1:42 PM, Alexey Proskuryakov a...@webkit.org wrote: 06.10.2011, в 13:23, Peter Kasting написал(а): Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. If accurate, that could be a great resolution to the dispute. I do not know enough about these devices to say whether wheels and 3d mice (as an example) are covered. The spechttp://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html explicitly states that it's about gamepad devices (also known as joysticks). Spec section 3 states: This allows support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. It excludes support for more complex devices that do motion sensing, depth sensing, video analysis, gesture recognition, and so on. It seems to me that this is an appropriate line to draw. Devices like the Kinect seem categorically different from most classical game input devices and I think it's reasonable to exclude them from the first version of the spec, as long as it covers the other types of things fairly well. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
Hi Alexey, The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. This is based on a somewhat generic treatment of axes and buttons that are exposed as normalized floating point values. There has been some discussion of attempting to further generalize but in an attempt to limit to a tractable scope to start with, the WG felt it was best to push broader generalization to a potential v2 spec. Regards, Scott 2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:23, Peter Kasting написал(а): Why are you convinced there is input device fragmentation here? My understanding is that the spec as proposed already handles multi-axis digital and analog controls so things you mentioned earlier like wheels and 3d mice would all just work along with gamepads and joysticks. If accurate, that could be a great resolution to the dispute. I do not know enough about these devices to say whether wheels and 3d mice (as an example) are covered. The spechttp://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html explicitly states that it's about gamepad devices (also known as joysticks). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I think you should send these comments back on webevents-public@w3.orginstead as James pointed out. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov a...@webkit.org wrote: 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I hate to repeat myself but this feedback really should go to the working group defining the specification. - James - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature flag proposal: Joystick API
2011/10/6 Ryosuke Niwa rn...@webkit.org 2011/10/6 Alexey Proskuryakov a...@webkit.org 06.10.2011, в 13:49, Scott Graham написал(а): The first revision of the spec (from the Scope section) is intended to handle: ... support for devices common to current gaming systems including gamepads, directional pads, joysticks, wheels, pedals, accelerometers. Why does the spec title and abstract talk about gamepads (joysticks) only? Perhaps it's my mistake that I didn't read the scope section, but with title and abstract being so specific, that seemed unnecessary. Skipping scope section, I went right to IDL. Why is the interface called Gamepad if it's not only about gamepads? I think you should send these comments back on webevents-public@w3.orginstead as James pointed out. I'll add that I completely agree with both of your points above but I don't feel motivated or knowledgeable enough to post it myself. Also I don't want to take credits for your feedback :) - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev