Re: [webkit-dev] Fwd: Gamepad API [Was: New feature flag proposal: Joystick API]
Hi, Alexey Proskuryakov wrote: One way to come up with a good name for something already in existence is to look how other people call it. For example, a Wikipedia article on USB HID devices puts everything this spec cares about into game controllers section. How about GameController? Yes, agreed, GameController was the third candidate that was discussed in the WG (other than Joystick and Gamepad). Gamepad was favoured, because Controller seemed to imply too much generality (cameras, et al.). The discussion is in the minutes here for those interested http://www.w3.org/2011/09/20-webevents-minutes.html. Personally, I see Gamepad as a representative name rather than necessarily all encompassing. Analogously we use Mouse in other specs. Many people use trackballs, trackpads, joystick-like devices, etc. to control some indexed buttons with a 2d location + scrolling indications. This is because there's no particularly better word for that input concept than mouse. I believe this is the case for gamepad too. Jerry Seeger vikin...@me.com wrote: I read the scope, and it seems pretty clear, but it's worth asking: If you stated what you DO cover better, is it no longer necessary to state what you DON'T cover. If the scope is clear, why is the name so difficult? In this case a 'gamepad' has been defined as a collection of analog inputs with input values between either 0..1 or -1..1.From my (very brief) scanning of the spec, it seems like this is the 'bounded (or finite?) analog input collection' spec. Thanks for the feedback. That does seem like a good way of summarizing the scope, and I think we should include something like that in the spec to help make things more explicit. As a name though, boundedAnalogInputDeviceCollection seems a bit unwieldy. scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API]
2011/10/12 Alexey Proskuryakov a...@webkit.org: The issues that I see are: - Immaturity that's manifesting itself even in the name. You can't really ask someone to meaningfully review a spec when its scope is so unclear. What about the scope is unclear? I feel that the Scope section of the spec and the draft charter outlines what we hope to address. - Spec development process that ignores feedback. Multiple people who want this feature (including one of spec editors) were aware of feedback but didn't act on it. We had consensus on webkit-dev that the name was bad I was indeed aware of your feedback (that you felt the name was unclear, as far as I understood it), but after discussing during a WG meeting, we haven't thought of a better name. If you have any suggestions, I'm sure all would be open to an improved name. I apologize for not publicly acknowledging that we have not yet addressed the issue you've raised. I have opened an issue on your behalf: http://www.w3.org/2010/webevents/track/issues/24 Again, the goal is to attempt to gather feedback from developers at this stage, with work done behind a flag so as to reduce any possible negative impact on WebKit. The hope is that we will learn more. Perhaps we'll come up with a better name too! ___ 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
Hello, Work has started on a Gamepad (Joystick) spec in the W3C WebEvents WG. If you're interested in commenting or participating, the mailing list can be found at http://lists.w3.org/Archives/Public/public-webevents/ For reference, the draft in-progress can be found at http://dvcs.w3.org/hg/webevents/raw-file/tip/gamepad.html scott On Thu, Aug 25, 2011 at 8:44 AM, Scott Graham scot...@chromium.org wrote: Thanks Simon and Dimitri, I wasn't familiar with the procedure for attacking these sorts of things. I've started a discussion on public-webapps, which will hopefully help to clarify a sensible API. Please add your voice if you have the time and inclination: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1019.html If the discussion proves fruitful, I will re-approach the WebKit community to figure out the best way to work on a prototype implementation. I've closed the previously mentioned bug for now. scott On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We should do this right, you won't hear any arguments from me. But I am also sure that W3C time investment is a code word for years of soul-sucking bureaucratic drudgery. As such, I don't think you meant we should be using W3C process as the measuring stick for doing things right in WebKit. There would not be WebKit if we did. What I hope you meant instead is: * study the problem in the larger context of a Web platform * come up with a set of use cases that cover the problem * design a solution based on the use cases * build consensus with browser vendors while prototyping it in WebKit * write a spec and a test suite that makes sense * submit this to W3C as time permits. That's what we've always done, right? :DG On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser simon.fra...@apple.com wrote: My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events. I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment. Simon On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote: On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham scot...@chromium.org wrote: 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. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? FWIW, keeping implementation downstream (that is in Chromium) is basically an equivalent of forking, and we should work hard to avoid that. But certainly not by just rejecting prototyping outright -- because the only workaround for that is forking. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
2011/9/21 Alexey Proskuryakov a...@webkit.org: platforms. Interfering with mouse movement would be one of the most dangerous and frustrating things Web pages could possibly do. While I agree, that doesn't seem like a problem with the spec. As I read the spec, it seems that it leaves enough latitude to allow each browser to do what it feels is best for its users as far as security and annoyance is concerned. If your browser simply prompted or required whitelisting before allowing a page to mouse lock along with directions on how to cancel, it doesn't seem like it would be problematic to me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to change an .exp file?
I believe the Windows ones are the .def files. I had to make a similar
change here: https://bugs.webkit.org/attachment.cgi?id=102529action=prettypatch
(e.g. Source/WebKit2/win/WebKit2.def and similar)
You have to be able mangle in your head it seems. I found the easiest
way was to make a simple program with the same
namespaces/classes/empty functions and then use dumpbin to see the
appropriate name. :( Maybe there's a better way someone can point out
though.
On Fri, Aug 26, 2011 at 1:50 AM, Xianzhu Wang (王显著)
wangxian...@chromium.org wrote:
Hi,
I'm developing on Linux. One of my patch failed to build on Windows because
I haven't changed the related .exp file (e.g. JavaScriptCore.exp).
I just did the following on Linux to update the file:
1. nm xx.o | grep T | sed 's/^.\{19\}/_/'
2. replace related lines in the .exp file with the above output
Though it works I guess it's not the correct way. What's the correct way?
Thanks,
Xianzhu
___
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
Thanks Simon and Dimitri, I wasn't familiar with the procedure for attacking these sorts of things. I've started a discussion on public-webapps, which will hopefully help to clarify a sensible API. Please add your voice if you have the time and inclination: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1019.html If the discussion proves fruitful, I will re-approach the WebKit community to figure out the best way to work on a prototype implementation. I've closed the previously mentioned bug for now. scott On Wed, Aug 24, 2011 at 11:25 AM, Dimitri Glazkov dglaz...@chromium.org wrote: We should do this right, you won't hear any arguments from me. But I am also sure that W3C time investment is a code word for years of soul-sucking bureaucratic drudgery. As such, I don't think you meant we should be using W3C process as the measuring stick for doing things right in WebKit. There would not be WebKit if we did. What I hope you meant instead is: * study the problem in the larger context of a Web platform * come up with a set of use cases that cover the problem * design a solution based on the use cases * build consensus with browser vendors while prototyping it in WebKit * write a spec and a test suite that makes sense * submit this to W3C as time permits. That's what we've always done, right? :DG On Wed, Aug 24, 2011 at 10:21 AM, Simon Fraser simon.fra...@apple.com wrote: My main objection to adding this is that it's just one of many different types of input device, and if we add these piecemeal for each device that takes our fancy, we'll end up with a horrible mishmash of different input events. I'd prefer a more general strategy of thinking about all the various types of input events (e.g. joysticks, remote controls, assistive devices), and having an API that caters for all of them. This of course would require significant W3C time investment. Simon On Aug 24, 2011, at 9:43 AM, Dimitri Glazkov wrote: On Wed, Aug 24, 2011 at 9:39 AM, Scott Graham scot...@chromium.org wrote: 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. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? FWIW, keeping implementation downstream (that is in Chromium) is basically an equivalent of forking, and we should work hard to avoid that. But certainly not by just rejecting prototyping outright -- because the only workaround for that is forking. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New feature flag proposal: Joystick API
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
Re: [webkit-dev] New feature flag proposal: Joystick API
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. There's certainly work to be done in improving the design. I'm not proposing to slavishly implement the API exactly as specified there. However, I would like to prototype and help with the design of this API by iterating an implementation in the Chromium port. Is a feature flag inappropriate for this? i.e. Should that sort of prototype work be kept downstream indefinitely or until we have a draft spec? scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Timing updates for SVG SMIL animations
Hi, When the Timer is fired for SMILTimeContainer to update animations, the elapsed time is calculated based on the client's currentTime(). That elapsed time is passed into updateAnimations and is used most of the way down. In some cases during the update though, SMILTimeContainer::elapsed() is re-called (e.g. in SVGSMILElement::beginListChanged, endListChanged, createInstanceTimesFromSyncbase). This seems somewhat incorrect because it means that various parts of the animation will be updated with (slightly) different elapsed times than others. It also makes it impractical to use a debugger to step the code. Does anyone disagree that all updates should use the same elapsed time during the update? Or, in other words, is there any reason to re-get the current wallclock time during the update? Thanks, Scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing updates for SVG SMIL animations
On Wed, Jul 27, 2011 at 12:15 PM, Simon Fraser simon.fra...@apple.comwrote: On Jul 27, 2011, at 11:14 AM, Scott Graham wrote: Does anyone disagree that all updates should use the same elapsed time during the update? Or, in other words, is there any reason to re-get the current wallclock time during the update? I think your analysis is correct. You should file a bug for this in bugs.webkit.org, and folks can review your proposed changes there. Thanks, done: https://bugs.webkit.org/show_bug.cgi?id=65274 scott ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
