[webkit-dev] Why are the mock implementations in WebCore/platform?
Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is not supposed to know about classes outside of WebCore/platform in WebCore (such as DeviceOrientationController) and this seems to be perpetuating the laying violation. Perhaps a top-level WebCore/mock/ would be preferable. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are the mock implementations in WebCore/platform?
Note that it's still a bit of an open question as to where mocks should live in general. IIRC, the top candidates are like device orientation and speech do now, somehow in some central place but not compiled into production libraries, or in DRT (which means more copied code, but the platform layers will be better exercised). It would be nice to get this resolved once and for all and get the code cleaned up. J On Fri, Nov 26, 2010 at 6:33 PM, Sam Weinig sam.wei...@gmail.com wrote: Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is not supposed to know about classes outside of WebCore/platform in WebCore (such as DeviceOrientationController) and this seems to be perpetuating the laying violation. Perhaps a top-level WebCore/mock/ would be preferable. - Sam ___ 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] Why are the mock implementations in WebCore/platform?
Originally, I thought it made sense to mock out pieces of the platform abstraction that didn't exist in all ports (e.g., GPS sensors). I'm not sure why you'd want to mock out a client interface. Can't you just implement the client interface in DRT? Adam On Fri, Nov 26, 2010 at 10:33 AM, Sam Weinig sam.wei...@gmail.com wrote: Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is not supposed to know about classes outside of WebCore/platform in WebCore (such as DeviceOrientationController) and this seems to be perpetuating the laying violation. Perhaps a top-level WebCore/mock/ would be preferable. - Sam ___ 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] Exposing CSS pixel metrics to the scripting environment
Recently I brought this issue up to the WHATWG mailing list, without much luck. Currently, mobile devices are given access to window.devicePixelRatio, used for managing what are essentially higher resolution displays. See the iPhone, Android, etc. Within the desktop environment, devicePixelRatio is not updated on zoom events. I don't think it should be, but it's something to consider. Such information is critical to adjusting the resolution of bitmaps, be they from an image source or a canvas source, to be as crisp as can be. Microsoft has gone ahead in IE9 and just exposed a collection of metrics data: deviceXDPI, logicalXDPI, systemXDPI and Y counterparts. Source: http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx The task at hand is deciding whether or not to expose this information, and where. Technically, it's quite simple, as it's only a few floating point values which are already available to the WebKit environment. Zoom events always trigger a 'resize' event for window, as they alter the innerWidth and innerHeight of the layout. That resize event is the point in which the scripting environment would check to see if CSS pixel metrics have changed, and adjust the page accordingly. I want to note, that I am not speaking at all about changing how zoom works, or in any way suggesting that zoom be controlled by the scripting environment / web authors. I am recommending that we take a look at Microsoft's .screen extensions, and decide whether they hold merit, and may be included in WebKit. Doing so would mean that an independent implementation has picked up the extension, and it may be on the fast track for standardization. I had a rough time bringing this up with Mozilla. I'm hoping for a little more focus here, on this mailing list. Again, I'm merely looking to have CSS pixel metrics exposed, and I'm suggesting the MS proposal as it's certain to exist in their upcoming IE9 release. Their proposal exposes six floating point variables in the window.screen object, and is sufficient for current needs. Please let me know thoughts on the matter, and try to keep focused on the fact that we're just looking to expose a few floating points to the scripting environment, we're not looking to change any existing behaviors in any existing elements. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Exposing CSS pixel metrics to the scripting environment
Are you posting here because there is something specific to WebKit in your query or because you dislike the outcome of the WHATWG thread? Most of us follow the WHATWG closely and generally prefer to discuss standardization issues such as this in that forum to get a broader feedback base. - James On Friday, November 26, 2010, Charles Pritchard ch...@jumis.com wrote: Recently I brought this issue up to the WHATWG mailing list, without much luck. Currently, mobile devices are given access to window.devicePixelRatio, used for managing what are essentially higher resolution displays. See the iPhone, Android, etc. Within the desktop environment, devicePixelRatio is not updated on zoom events. I don't think it should be, but it's something to consider. Such information is critical to adjusting the resolution of bitmaps, be they from an image source or a canvas source, to be as crisp as can be. Microsoft has gone ahead in IE9 and just exposed a collection of metrics data: deviceXDPI, logicalXDPI, systemXDPI and Y counterparts. Source: http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx The task at hand is deciding whether or not to expose this information, and where. Technically, it's quite simple, as it's only a few floating point values which are already available to the WebKit environment. Zoom events always trigger a 'resize' event for window, as they alter the innerWidth and innerHeight of the layout. That resize event is the point in which the scripting environment would check to see if CSS pixel metrics have changed, and adjust the page accordingly. I want to note, that I am not speaking at all about changing how zoom works, or in any way suggesting that zoom be controlled by the scripting environment / web authors. I am recommending that we take a look at Microsoft's .screen extensions, and decide whether they hold merit, and may be included in WebKit. Doing so would mean that an independent implementation has picked up the extension, and it may be on the fast track for standardization. I had a rough time bringing this up with Mozilla. I'm hoping for a little more focus here, on this mailing list. Again, I'm merely looking to have CSS pixel metrics exposed, and I'm suggesting the MS proposal as it's certain to exist in their upcoming IE9 release. Their proposal exposes six floating point variables in the window.screen object, and is sufficient for current needs. Please let me know thoughts on the matter, and try to keep focused on the fact that we're just looking to expose a few floating points to the scripting environment, we're not looking to change any existing behaviors in any existing elements. -Charles ___ 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
