[webkit-dev] build.webkit.org is down?
Hi, build.webkit.org appears to be down: http://www.downforeveryoneorjustme.com/build.webkit.org kr, Christophe DUMEZ. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org is down?
On 2013-02-16, at 00:12, Christophe Dumez - SISA ch.du...@sisa.samsung.com wrote: build.webkit.org appears to be down: http://www.downforeveryoneorjustme.com/build.webkit.org I’ve fixed it. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org is down?
Indeed. Thanks! Christophe DUMEZ. From: Mark Rowe [mr...@apple.com] Sent: Saturday, February 16, 2013 10:26 To: Christophe Dumez - SISA Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] build.webkit.org is down? On 2013-02-16, at 00:12, Christophe Dumez - SISA ch.du...@sisa.samsung.commailto:ch.du...@sisa.samsung.com wrote: build.webkit.orghttp://build.webkit.org appears to be down: http://www.downforeveryoneorjustme.com/build.webkit.org I’ve fixed it. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Github repository not being updated
Hello Webkit-dev, I am using the github repository https://github.com/webkit/webkit but since the rev 142863 its not been updated. i.e. since 3 days. So wanted to see if someone who is maintaining this repo can look into this and fix if possible. Many thanks, Vivek ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Access WebKit Rendering pixel data
Are you talking about Rendered buffer? It is graphics library specific. From which layer you wanted to access? Each WebKit port(qt,gtk,chromium,efl,wx,mac) has their own API exposed to the app developers. Incase of Qt QWebView is a QWidget and you can use http://doc.qt.digia.com/qt/qwidget.html#render to get the rendered buffer as QPixmap object. In GTK port you can get the Cairo context and copy it to the Cairo_image_t(pixman backed Cairo surface). On Feb 16, 2013 8:23 AM, Michael Chen michael8...@yahoo.com wrote: Hi All, I am new to WebKit. Is it possible to get a raw pointer to the WebKit rendering buffer? I appreciate any comments. Best regards, Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ok
ok ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Deprecating JS interface
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and any
method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How to get patch test at different platform before webkit-patch upload
Hi I am handling this issue (https://bugs.webkit.org/show_bug.cgi?id=78957) now. My question is I test my added test code locally, however, it seems failed on some other platform(get red on cr-linux). So can I(and how can I) test my added test code on some EWS before I upload some patch? BTW, is there anyone who can help review my patch? I need the review can be passed by next month based on my job. And I do not think it can be passed easily because I am a new one to this project. More Detail: The added test for this patch is passed on my local platform(Safari@Mountain Lion). And I don't want to add dozens of almost same patches to one issue. BR, Zheng ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to get patch test at different platform before webkit-patch upload
Hi, On Sat, Feb 16, 2013 at 5:45 PM, 徐征 xz91...@yahoo.co.jp wrote: I am handling this issue (https://bugs.webkit.org/show_bug.cgi?id=78957) now. My question is I test my added test code locally, however, it seems failed on some other platform(get red on cr-linux). So can I(and how can I) test my added test code on some EWS before I upload some patch? The cr-linux bot is the only EWS running the pixel tests. Your test likely fails on everything but Mac. The problem is you assume the pixel test will be the same on all platform. Because the way fonts are rendered varies, the resulting images vary with each platform. In those cases, you can generate results for the platform you are working on, and mark the test for rebaseline in the TestExpectations files of the other platforms (in LayoutTest/platform/platformFooBar/TestExpectations). Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
It's much easier to discuss a concrete example. Which interface are
you interested in deprecating?
Adam
On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and
any method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote:
It's much easier to discuss a concrete example. Which interface are
you interested in deprecating?
I can understand that it is easier to discuss on a concrete example, even if I
would like to discuss this in a general scope. We have multiple interfaces that
we may want to deprecate at some point.
A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in
WebCore yet but hopefully replaced by a standardized Matrix interface in the
future[2]. This new interface will not be fully compatible to WebKitCSSMatrix
and I would like to warn authors before they actually start using it.
Again, I think it would be better to discuss this in a wider scope but am happy
to discuss it on the concrete example as well. This actually might make it
easier to come up with general rules in the future.
Greetings,
Dirk
[1] https://bugs.webkit.org/show_bug.cgi?id=110048
[2] https://bugs.webkit.org/show_bug.cgi?id=110001
Adam
On Sat, Feb 16, 2013 at 5:28 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
There are several steps on deprecating features[1]. My question is about
deprecating a whole interface and throwing warnings that the feature is
deprecated.
If I have the following interface for deprecation:
[Constructor]
interface Bla {
attribute bar;
void foo();
}
Should I just throw the deprecation warning on calling the constructor (and
any method/attribute creating the object), or on calling foo and bar as well?
Greetings,
Dirk
[1] http://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote: It's much easier to discuss a concrete example. Which interface are you interested in deprecating? I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point. A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it. Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here. Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class. Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future. I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deprecating JS interface
On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org wrote: It's much easier to discuss a concrete example. Which interface are you interested in deprecating? I can understand that it is easier to discuss on a concrete example, even if I would like to discuss this in a general scope. We have multiple interfaces that we may want to deprecate at some point. A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in WebCore yet but hopefully replaced by a standardized Matrix interface in the future[2]. This new interface will not be fully compatible to WebKitCSSMatrix and I would like to warn authors before they actually start using it. Since you're the one designing the new interface (or at least you are the spec editor), why don't you just make it compatible? Breaking changes to existing Web APIs should only be done as a last resort, and I don't understand the justification for doing it here. It is a proposal so far and no draft yet. Technically, I am not the editor of it so. The proposal has quite some way to go (hopefully not too much) and I do not plan to land anything in this direction as long as the responsible WGs did not agree on continuing with the proposal and the general direction. I will post a separate mail with the actual feature implementation announcement when the time comes. Then we have a much simper transition story, and WebKitCSSMatrix can be aliased to the new class. I indeed tried to preserve the behavior of WebKitCSSMatrix as much as possible. I got an action of the SVG WG to work on a replacement for SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix (which is definitely actively used by web content) and provide a basic interface that can be used beyond just SVG. There are a lot of use cases in the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and WebGL are the obvious once. A specification interoperable format to share transformation data seems extremely desirable. I encourage everyone who is interested to look at the proposal and give feedback. Again, I think it would be better to discuss this in a wider scope but am happy to discuss it on the concrete example as well. This actually might make it easier to come up with general rules in the future. I think spamming the console is not a useful thing to do for interfaces that actually have significant usage in the wild. A more productive step would be to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not going to be able to remove it. I agree that we need more metrics to discuss the next active steps on WebKitCSSMatrix and I already uploaded a patch to add it to the FeatureObserver[1]. The question remains: How do we want to continue with deprecating WebKit specific features in the long term. Especially when we have a standard compliant replacement. It is extremely hard to maintain all different behaviors. So far we have multiple implementations of background, flex-box, gradients to name some. This doesn't scale very well and there will be a time where we can not guarantee for the correct functioning of old features. This is a problem that other browsers like IE are focused for quite some time as well (not necessarily successfully). As long as we are concerned to deprecate and remove features, we increase the complexity of the code base. Less and less reviewers will be able to determine the behavior of patches to the general code base, while we increase the feature count and interoperability between modules more and more. There is no other way then to risk breaking content that relies on non-standardized behavior of platforms. And we should formalize this t o give a bit more reliability to web authors. The last section on [2] is too vague at the moment. Greetings, Dirk [1] https://bugs.webkit.org/show_bug.cgi?id=110002 [2] http://trac.webkit.org/wiki/DeprecatingFeatures Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
