[webkit-dev] need help with adding javascript commands to browser.

2011-10-06 Thread D.J. Barrow
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

2011-10-06 Thread 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] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)

2011-10-06 Thread Fady Samuel
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

2011-10-06 Thread Dan Bernstein

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

2011-10-06 Thread 蓋文彼德斯
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

2011-10-06 Thread Darin Fisher
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

2011-10-06 Thread Dan Bernstein

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

2011-10-06 Thread Dan Bernstein

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)

2011-10-06 Thread Anders Carlsson
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)

2011-10-06 Thread Fady Samuel
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)

2011-10-06 Thread Anders Carlsson
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)

2011-10-06 Thread Fady Samuel
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

2011-10-06 Thread Alexey Proskuryakov

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

2011-10-06 Thread James Robinson
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

2011-10-06 Thread David Levin
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

2011-10-06 Thread Soheil Servati Beiragh
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

2011-10-06 Thread Alexey Proskuryakov

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.

2011-10-06 Thread Ariya Hidayat
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

2011-10-06 Thread Peter Kasting
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

2011-10-06 Thread Peter Kasting
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

2011-10-06 Thread Scott Graham
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

2011-10-06 Thread Alexey Proskuryakov

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-06 Thread Ryosuke Niwa
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

2011-10-06 Thread James Robinson
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-06 Thread Ryosuke Niwa
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