[webkit-dev] Reg: Build break on latest Trunk!
Hi, Has anybody tried building the latest webkit-trunk for Safari on windows? I am getting some build errors while building WebCore :) *Can anybody share the latest working SVN Revision Number that I can try? * -- Justin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reg: Build break on latest Trunk!
On Oct 12, 2011, at 3:15 AM, just2 contribute wrote: Has anybody tried building the latest webkit-trunk for Safari on windows? I am getting some build errors while building WebCore :) Can anybody share the latest working SVN Revision Number that I can try? http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 says that the last revision the bots built was r97252. http://trac.webkit.org/ says that that's the latest checked-in revision. In general you can assume that any recent revision builds on Windows. You can double-check with the bots if you'd like. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Compiling chromium webkit unit tests on Mac
Hi all, I apologize for sending this out to such a broad audience, but I'd like to know how to compile the chromium webkit unit tests on Mac? I tried this: xcodebuild -project third_party/WebKit/Source/WebKit/chromium/WebKit.xcodeproj -configuration Debug -target webkit_unit_tests It complains about a missing libskia. How do I build skia then? Or is there a better way to build the unit tests? Thanks, Fady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling chromium webkit unit tests on Mac
./Tools/Scripts/update-webkit --chromium ./Tools/Scripts/build-webkit --chromium That will build the Chromium WebKit unit tests as well. Adam On Wed, Oct 12, 2011 at 10:31 AM, Fady Samuel fsam...@chromium.org wrote: Hi all, I apologize for sending this out to such a broad audience, but I'd like to know how to compile the chromium webkit unit tests on Mac? I tried this: xcodebuild -project third_party/WebKit/Source/WebKit/chromium/WebKit.xcodeproj -configuration Debug -target webkit_unit_tests It complains about a missing libskia. How do I build skia then? Or is there a better way to build the unit tests? 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] Reading from Object
I think my issue some kind of lack of knowledge in C++. I'm trying to redesign the the text placement engine in webkit. For my purpose I need to get access to font face which is stored in the place I mentioned. I know that they are private but I want to read them, and I know it is possible to do so. 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 From: Ryosuke Niwa rn...@webkit.org To: Soheil Servati Beiragh sserv...@yahoo.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Sent: Wednesday, October 12, 2011 3:37 AM Subject: Re: [webkit-dev] Reading from Object What are you trying to do here? Clearly, all member variables are private here so you shouldn't be accessing directly by m_fontlist.m_ptr-m_cachePrimarySimpleFontData-m_platformData.m_face. I don't know much about the rendering engine but perhaps other contributors can help you out if you give us more context in which you're trying to do this. - Ryosuke On Tue, Oct 11, 2011 at 12:57 PM, Soheil Servati Beiragh sserv...@yahoo.com wrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Distinction between local and non-local URIs
Dear Adam, thank you for the the description. In line with my argument, that there is nothing intrinsically special with resources residing under file:// than there is with other resources let me ask coversely - very much because I understand exactly what you mean: Why do you consider the possibility that a website can determine whether specific images are available on the users filesystem any more dangerous or intruding than the possibility to find out whether a user has cookie-authed to a remote image-resource (let us assume the particular server-side does not check for referers)? Before you answer that question though, which I'm sure you could, because it, at that stage, is merely a matter of taste for what is appropriate, let me propose a different solution: Given the assumption that it would be indeed more inappropriate for a webpage to check for locally available images (or any sort of embedded resource) than it is for a webpage to for remotely available images, it would be sufficient to extend the same-origin restriction in the case of access to local resources to encompass preventing embedded content to be loaded. Other things, particularly anchors or iframes (though I in no sort approve of such ridiculous usage on a website whatsoever) pose absolutly no intrusion into the users privacy and therefore should be permitted. At this point I'm admittedly convinced that the use-case upon which my question and proposition is based, is indeed a most negligible corner-case and possibly not worth re-desiging the security feature or even just removing it alltogether. However, I'd still like to reach a conclusion, and if it be only for future prospect readers of this thread, on how far such a restricition is in fact needed. -- ManDay On Wed, Oct 12, 2011 at 12:40:23PM -0700, Adam Barth wrote: As far as I know, every modern browser prevents non-local HTML document (e.g., those with http or https schemes) from embedding resources (e.g., images or iframes) from the local file system. This restriction prevents remote parties from probing the user's local file system for information. For example, if we didn't implement this restriction, a web page could detect whether you had a particular piece of software installed on your computer by embedding images that program stores at predictable locations on disk. If the software package is installed, those images would load correct and their height and width would affect layout. If not, the image load would error out. You seem somewhat upset about this policy, but please understand that we implement the restriction to improve the privacy and security of our users. If you're embedding WebKit in your application, there is a setting for disabling this protection if it's not appropriate for your application. Hopefully this email will give you some context for why we implement this restriction. Thanks for the feedback, and I hope you find WebKit useful. Adam On Wed, Oct 12, 2011 at 12:25 PM, Cedric Sodhi man...@gmx.net wrote: I'm of the opinion that there is no need to distinguish between local and non-local schemes, such as it is in the case where a non-local (say, http) URI cannot load or embed a local (say, file) scheme. I've heard that there must have been reasons for such a restriction to be introduced. I hereby would like to reaccess those reasons and ask the people who originally drove the implementation to justify that restriction with regard to contemporary security issues. As a preclaimer to any argument I would like to cleary state that there IS NO INTRINSIC DIFFERENCE BETWEEN LOCAL AND NON-LOCAL RESOURCES. Both have equal rights to demand security. The only difference lies in the protocol being used to access them and what has to considered a distinct domain with regard to same-origin-policy. For reading, it's of no relevance, whether a file is at file:// , http:// , ftp:// , scp:// , or etc. Hence, limitations randomly imposed on either of the schemes are superflous and a wrong approach to whatever possible security considerations might have been made. -- regards, ManDay ___ 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] Gamepad API [Was: New feature flag proposal: Joystick API]
Hi all, Alexey appears to strongly dislike the name of this API specification ( http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so that he is blocking development of the API behind a flag. As a reminder, this API is being developed through the WebEvents WG jointly with other browser vendors, including Mozilla. Folks working on this appear to be content with the Gamepad name, precisely because the spec is limited to dealing with input devices that are represented in terms of buttons and axes. Gamepad seems like a fairly canonical name for such a device, even though devices by other names can be represented by similar data. Does anyone else feel strongly enough that the name of the API is so bad that it should therefore not be allowed onto WebKit trunk behind a flag? Personally, I feel like the name is quite malleable at this point in time, and I really like coming up with the best possible name for things. However, I don't see why we need to have the perfect name before we continue development of this feature behind a flag. As we were developing Blob and File support, we made several name changes along the way. It is not always so obvious how to name things from the start. See this bug for reference: https://bugs.webkit.org/show_bug.cgi?id=69451 Thoughts? -Darin 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? - 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] Distinction between local and non-local URIs
On Wed, Oct 12, 2011 at 12:56 PM, Cedric Sodhi man...@gmx.net wrote: Dear Adam, thank you for the the description. In line with my argument, that there is nothing intrinsically special with resources residing under file:// than there is with other resources let me ask coversely - very much because I understand exactly what you mean: Why do you consider the possibility that a website can determine whether specific images are available on the users filesystem any more dangerous or intruding than the possibility to find out whether a user has cookie-authed to a remote image-resource (let us assume the particular server-side does not check for referers)? If I could prevent that from happen, I would. However, the only ways I know of preventing that from happening also cause many people to become unhappy with my browser and to choose to use a different browser. Given that I want folks to use my browser, I have to keep that security hole open. By contrast, in the local file case, the evidence is that I can both close the security hole and have my browser be popular. Given that I value security over consistency in this case, my choice is clear. Adam Before you answer that question though, which I'm sure you could, because it, at that stage, is merely a matter of taste for what is appropriate, let me propose a different solution: Given the assumption that it would be indeed more inappropriate for a webpage to check for locally available images (or any sort of embedded resource) than it is for a webpage to for remotely available images, it would be sufficient to extend the same-origin restriction in the case of access to local resources to encompass preventing embedded content to be loaded. Other things, particularly anchors or iframes (though I in no sort approve of such ridiculous usage on a website whatsoever) pose absolutly no intrusion into the users privacy and therefore should be permitted. At this point I'm admittedly convinced that the use-case upon which my question and proposition is based, is indeed a most negligible corner-case and possibly not worth re-desiging the security feature or even just removing it alltogether. However, I'd still like to reach a conclusion, and if it be only for future prospect readers of this thread, on how far such a restricition is in fact needed. -- ManDay On Wed, Oct 12, 2011 at 12:40:23PM -0700, Adam Barth wrote: As far as I know, every modern browser prevents non-local HTML document (e.g., those with http or https schemes) from embedding resources (e.g., images or iframes) from the local file system. This restriction prevents remote parties from probing the user's local file system for information. For example, if we didn't implement this restriction, a web page could detect whether you had a particular piece of software installed on your computer by embedding images that program stores at predictable locations on disk. If the software package is installed, those images would load correct and their height and width would affect layout. If not, the image load would error out. You seem somewhat upset about this policy, but please understand that we implement the restriction to improve the privacy and security of our users. If you're embedding WebKit in your application, there is a setting for disabling this protection if it's not appropriate for your application. Hopefully this email will give you some context for why we implement this restriction. Thanks for the feedback, and I hope you find WebKit useful. Adam On Wed, Oct 12, 2011 at 12:25 PM, Cedric Sodhi man...@gmx.net wrote: I'm of the opinion that there is no need to distinguish between local and non-local schemes, such as it is in the case where a non-local (say, http) URI cannot load or embed a local (say, file) scheme. I've heard that there must have been reasons for such a restriction to be introduced. I hereby would like to reaccess those reasons and ask the people who originally drove the implementation to justify that restriction with regard to contemporary security issues. As a preclaimer to any argument I would like to cleary state that there IS NO INTRINSIC DIFFERENCE BETWEEN LOCAL AND NON-LOCAL RESOURCES. Both have equal rights to demand security. The only difference lies in the protocol being used to access them and what has to considered a distinct domain with regard to same-origin-policy. For reading, it's of no relevance, whether a file is at file:// , http:// , ftp:// , scp:// , or etc. Hence, limitations randomly imposed on either of the schemes are superflous and a wrong approach to whatever possible security considerations might have been made. -- regards, ManDay ___ 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]
I don't think it's worth blocking development of the feature based solely on the name. I'd recommend sorting out the name issue before enabling the feature by default though, because that's the point in time after which changing the name will become painful. If the name is really a sticking point, you can always give the API a ridiculous name to force yourself to change it later. Adam On Wed, Oct 12, 2011 at 12:59 PM, Darin Fisher da...@chromium.org wrote: Hi all, Alexey appears to strongly dislike the name of this API specification (http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so that he is blocking development of the API behind a flag. As a reminder, this API is being developed through the WebEvents WG jointly with other browser vendors, including Mozilla. Folks working on this appear to be content with the Gamepad name, precisely because the spec is limited to dealing with input devices that are represented in terms of buttons and axes. Gamepad seems like a fairly canonical name for such a device, even though devices by other names can be represented by similar data. Does anyone else feel strongly enough that the name of the API is so bad that it should therefore not be allowed onto WebKit trunk behind a flag? Personally, I feel like the name is quite malleable at this point in time, and I really like coming up with the best possible name for things. However, I don't see why we need to have the perfect name before we continue development of this feature behind a flag. As we were developing Blob and File support, we made several name changes along the way. It is not always so obvious how to name things from the start. See this bug for reference: https://bugs.webkit.org/show_bug.cgi?id=69451 Thoughts? -Darin 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? - 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 ___ 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]
Its obvious that a naming nit is a not a good reason to block development behind a flag. Is the the true basis for that r- expressed in this comment? The concern here as I understand it is 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. But that concern also shouldn't block initial development behind a flag. Seems like that concern should be brought up with the WG. On Wed, Oct 12, 2011 at 12:59 PM, Darin Fisher da...@chromium.org wrote: Hi all, Alexey appears to strongly dislike the name of this API specification ( http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so that he is blocking development of the API behind a flag. As a reminder, this API is being developed through the WebEvents WG jointly with other browser vendors, including Mozilla. Folks working on this appear to be content with the Gamepad name, precisely because the spec is limited to dealing with input devices that are represented in terms of buttons and axes. Gamepad seems like a fairly canonical name for such a device, even though devices by other names can be represented by similar data. Does anyone else feel strongly enough that the name of the API is so bad that it should therefore not be allowed onto WebKit trunk behind a flag? Personally, I feel like the name is quite malleable at this point in time, and I really like coming up with the best possible name for things. However, I don't see why we need to have the perfect name before we continue development of this feature behind a flag. As we were developing Blob and File support, we made several name changes along the way. It is not always so obvious how to name things from the start. See this bug for reference: https://bugs.webkit.org/show_bug.cgi?id=69451 Thoughts? -Darin 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? - 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 ___ 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]
12.10.2011, в 14:10, Adam Barth написал(а): I don't think it's worth blocking development of the feature based solely on the name. Quoting what I actually said in the bug, I don't think that we should accept an implementation of a spec that's so immature that it doesn't even have a meaningful name. 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. - 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, yet a patch was again posted for review in Bugzilla. I'd recommend sorting out the name issue before enabling the feature by default though, because that's the point in time after which changing the name will become painful. If the name is really a sticking point, you can always give the API a ridiculous name to force yourself to change it later. :) - 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 announcement - Implement HTML5 Microdata in WebKit
Given that Gecko is implementing the unprefixed getItems (see https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in implementing with webkit prefix. Also, it's still under a compile-time flag so we can prefix it before enabling the flag by default if we strongly feel like it. - Ryosuke On Thu, Sep 22, 2011 at 2:32 PM, Charles Pritchard ch...@jumis.com wrote: On 9/22/2011 2:13 PM, Ian Hickson wrote: On Fri, 23 Sep 2011, Dean Jackson wrote: However, isn't prefixing designed to avoid incompatibilities in spec changes, not incompatibilities between implementations? Ensuring no conflicts in implementations doesn't matter too much if the spec changes. It's designed to ensure that authors can reliably use a name and expect to get the same result in any UA that supports that name. I'm not going to change the spec in a way that conflicts with that -- if the spec has to change, it'll change either in a compatible way (e.g. to match what was actually implemented), or in a way that doesn't conflict (e.g. by changing the name in the spec). Note I'm not talking about Microdata in particular. I don't even know what that spec is :) I'm just talking about the general approach. If the world can guarantee that this spec will never change, then I guess your technique works. FWIW, there is an in-between approach, which is the one used by WebGL. It defines a prefix that all implementations share. canvas.getContext(**experimental-webgl); That'll just result in that name becoming the standard. I would like some kind of fast track method for these kind of issues. Something like a Request for dropping prefix RfDP protocol would be super. RfDP: Microdata. First the spec editor would have to vouch for it, then, if Moz, MS, Opera, Apple and Google reps can give a nod within a few weeks, we've got something. I'd really like to avoid repeats of the CSS -vnd-transform baggage, when possible. WebKit went back and forth on BlobBuilder. Now it's at: WebKitBlobBuilder. That was not so fun. That's another situation I'd like to avoid. For this particular method, the microdata section, I'm happy enough hearing that the spec editor will vouch for it. If that's the precedent, I'll take it. I'd like to learn how we can build on that precedent. Reps from the major vendors have been quite responsive this year. I know they can't commit to supporting an API in a short time frame (such as the File API), but they have been great about voicing issues. -Charles __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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] Gamepad API [Was: New feature flag proposal: Joystick API]
On Wed, Oct 12, 2011 at 3:58 PM, Alexey Proskuryakov a...@webkit.org wrote: Quoting what I actually said in the bug, I don't think that we should accept an implementation of a spec that's so immature that it doesn't even have a meaningful name. That the name is not meaningful, and that this is a sign of too great of spec immaturity, are both judgment calls. I don't happen to agree with your judgment in either case (not that my own judgment is objectively better). There's been a noteworthy lack of good alternative ideas for the name (joystick has similar issues to gamepad, whereas input device or similar are clearly far too broad for what the spec covers; in the end I agree with Darin that the name is fine overall), and in that context I'm not sure the name is evidence for spec immaturity. We had consensus on webkit-dev that the name was bad, yet a patch was again posted for review in Bugzilla. Consensus seems somewhat strong. Looking over the emails sent, you expressed some concern, but there was not a ton of discussion beyond that. I read the tone of the thread as generally OK with things. (If that hadn't been the case I would have sent this email earlier.) As Adam notes, we should be confident of the name before we turn it on by default, but I don't think that should block development, and I also think it would behoove people unhappy with the name to offer some clearly-superior proposals. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New feature announcement - Implement HTML5 Microdata in WebKit
On 10/12/2011 4:12 PM, Ryosuke Niwa wrote: Given that Gecko is implementing the unprefixed getItems (see https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits in implementing with webkit prefix. Also, it's still under a compile-time flag so we can prefix it before enabling the flag by default if we strongly feel like it. - Ryosuke I've no objection. I'd like to hear from Microsoft and Opera. I'll go solicit their feedback. -Charles ___ 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] Gamepad API [Was: New feature flag proposal: Joystick API]
12.10.2011, в 16:43, Scott Graham написал(а): - 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. 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? You could look at other classifications of input devices. Maybe USB HID spec itself has a good classification? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Gamepad API [Was: New feature flag proposal: Joystick API]
Forwarding two messages from Jerry Seeger, whose e-mails aren't getting to the list yet. Answering Jerry's comment, I think that targeting the spec to explicitly address gaming use case is better than the current situation. A very large group of devices is undoubtedly built with gaming and only gaming in mind. Jerry's proposed line of thinking certainly seems very promising, too. - WBR, Alexey Proskuryakov Начало переадресованного сообщения: От: Jerry Seeger vikin...@me.com Тема: Ответ: [webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API] Дата: 12 октября 2011 г. 18:10:05 Тихоокеанское летнее время Кому: Alexey Proskuryakov a...@webkit.org Копия: Scott Graham scot...@chromium.org, WebKit Development webkit-dev@lists.webkit.org 'Game' is a use case, not a description of device characteristics. GameController and Gamepad both carry the same ambiguity. Alexey, I have to admit that maybe I didn't understand your original objections, if a swapping -pad for -Controller makes the spec OK. Sorry Alexey to beat the horse, but I'm including here my previous message, while I figure out why my messages aren't going to the list: I haven't been a direct contributor to Webkit, but I think Alexey has a valid point. A gamepad is some sort of amalgam of controls for gaming that probably has joysticks and multiple buttons (and inertial controllers?). A joystick is a piece of hardware with specific characteristics, which may or may not be used for gaming. Confusion about the name in this case is a flag that indicates that the scope of the spec is ambiguous. 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. And there you have a description that describes what you cover, and intrinsically excludes what you don't. Which begs a larger question not really for this list: is that really two specs - one for bounded linear analog devices, and one for collections of devices. The good people writing the spec have probably gone round and round with this, but I think the places I'm not convinced mirror Alexey's, so I thought I'd try my hand at articulating those objections a different way. And now I will shut up and watch with interest. Jerry On Oct 12, 2011, at 5:07 PM, Alexey Proskuryakov wrote: 12.10.2011, в 16:43, Scott Graham написал(а): - 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. 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? You could look at other classifications of input devices. Maybe USB HID spec itself has a good classification? - 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
