Re: [webkit-dev] changelog and patches
Run WebKitTools/Scripts/resolve-ChangeLogs each time you rebase. PS: try webkit-patch help --all-commands, from that same directory; in particular webkit-patch post-commits automates attaching your patch to a bug. On Tue, Feb 23, 2010 at 1:27 PM, arno a...@renevier.net wrote: Hi, I've recently submitted a few patches. My workflow is as follow: I use git repository. Once I've made my modifications, I run WebKitTools/Scripts/prepare-ChangeLog, then I git-commit changeset in a private branch, then I export my patch with git-format-patch or git-diff My first problem is that sometimes, my patch does not apply because of changelog. I suppose it's because webkit changelog has changed in the repository. See for example attachment 49123 in bug #35191 My second problem is that once I've updated git master branch, I can't rebase my private branch because again, changelogs have changed, and diffs do not apply correctly. So, what's wrong with my approach ? How do you manage multiple patches efficiently without being hampered by those changelog diff problems ? thanks a lot arno -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkuDya8ACgkQ7Z0ZxRdGQ+fVrACfV5kyuaiv5zF63dpXvFGeZj/J E6AAnAy6ncq7zseXZwZSa/nIBAkZGV3k =3Y2/ -END PGP SIGNATURE- ___ 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] changelog and patches
On Tue, Feb 23, 2010 at 4:27 AM, arno a...@renevier.net wrote: Hi, I've recently submitted a few patches. My workflow is as follow: I use git repository. Once I've made my modifications, I run WebKitTools/Scripts/prepare-ChangeLog, then I git-commit changeset in a private branch, then I export my patch with git-format-patch or git-diff My first problem is that sometimes, my patch does not apply because of changelog. I suppose it's because webkit changelog has changed in the repository. See for example attachment 49123 in bug #35191 Your first problem doesn't seem to be because of ChangeLog files, at least in the bug you referenced. It looks like that patch didn't apply because the first line of the patch you submitted is not the diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog line. It is a known issue that svn-apply doesn't work if the patch has leading junk. See this report, for example: https://bugs.webkit.org/show_bug.cgi?id=33119 Using git-diff instead of git-format-patch should probably resolve that one. Also read the wiki page about using Git with WebKit: http://trac.webkit.org/wiki/UsingGitWithWebKit --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] changelog and patches
On 23/2/10 13:31 , Evan Martin wrote: Run WebKitTools/Scripts/resolve-ChangeLogs each time you rebase. Or run once: git config merge.changelog.driver resolve-ChangeLogs --merge-driver %O %A %B tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Increasing the number of cross-platform/port expected results
Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. We're seeing this in the Qt port when results are checked in as platform-independent and causing failures, or when we have to generate platform-dependent results for new tests when the test looks cross-platform. I also had this problem when trying to get a Windows build up and running with 0 failing layout-tests, so that I could verify that I didn't break anything before landing. Even after using various tricks to get the same font setup as the buildbots I still had failures that looked like they were due to font metrics [1]. Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. Another approach would be to use a fixed set of metrics for text and themes when running the DRT, unless the test specifically asks for real font and theme metrics. We could for example add two additional functions to the layout-test controller: layoutTestController.dumpRealFontMetrics() and layoutTestController.dumpRealThemeMetrics() This would allow us to share render-tree results between all ports for those tests that don't explicitly test font or theme rendering (unless I missed more platform-differences). Thoughts? Will this work? :) Or, are there other ways we could achieve the same thing? My worry is basically that the number of platform-specific-result will not scale as the number of ports and platforms increases if we continue to have all these false positive platform-specific-results that are not really platform-specific. Tor Arne [1] http://trac.webkit.org/wiki/BuildingOnWindows#RunningtheLayoutTestsonWindows ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Feb 23, 2010 at 2:00 PM, Tor Arne Vestbø tor.arne.ves...@nokia.com wrote: Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. For Chromium on Linux, we try to insulate ourselves from the platform settings by injecting a custom fontconfig file and font list that makes things match Windows behavior. (Matching Windows is important because many sites will hardcode a pixel width on a div then fill it with text and expect the text not to wrap.) This makes our tests sadly kind of font-set and platform-dependent but it at least makes the test behave the same regardless of which system it's run on. See this code for a discussion: http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=webkit/tools/test_shell/test_shell_gtk.cc;h=e6673ffc1b6dfe756c5f95e59679c8e857af530d;hb=HEAD#l173 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 14:15 , Evan Martin wrote: On Tue, Feb 23, 2010 at 2:00 PM, Tor Arne Vestbø tor.arne.ves...@nokia.com wrote: Lately we've been playing with the idea of using SVG fonts for the Qt port to get the same set of expected results for qt-mac, qt-linux and qt-win, by injecting new @font-face rules using a user-stylesheet and preventing platform-fonts from being loaded, but this approach/hack has proven to be quite fragile, and we will also miss out on those tests that actually test font loading/rendering. For Chromium on Linux, we try to insulate ourselves from the platform settings by injecting a custom fontconfig file and font list that makes things match Windows behavior. (Matching Windows is important because many sites will hardcode a pixel width on a div then fill it with text and expect the text not to wrap.) We do the same thing for the Qt DRT on Linux, but I was hoping to get something that would work for Windows and Mac OS X too, since we don't use FreeType on those platforms, etc. That's where the idea of using SVG fonts spawned, since if we force the Qt DRT to use the raster paint engine those SVG fonts should be rendered the same way regardless of platform. But then we would have the problem of not being able to test actual font loading (without adding lots of exceptions) and the trick would not work for other ports, just the Qt port. That's why I was playing with the idea of using hard-coded metrics for fonts and themes on a global basis in WebKit (if running under the DRT), and letting those tests that actually test font loading/rendering or theming override this using the layoutTestController. Does that sound achievable/desirable at all? :) tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 5:00 AM, Tor Arne Vestbø wrote: Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. Isn't it our existing pixel test infrastructure? Or do you mean something else? -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 8:08 AM, Ariya Hidayat wrote: When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. Isn't it our existing pixel test infrastructure? Or do you mean something else? In pixel tests, the expected file is a checked-in image. In addition, we still have a render tree dump; it’s not just pixels. In reference tests, the expected file is HTML; different than the test file, typically simple markup. Both files are rendered and the resulting pixels are compared. And I presume there would be no render tree dump. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 17:02 , Simon Fraser wrote: On Feb 23, 2010, at 5:00 AM, Tor Arne Vestbø wrote: Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. You mean for example that the reference file of a css-border test that has some header-text describing the test would contain the same header-text but then a image to represent the reference of the css-part? tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 8:21 AM, Tor Arne Vestbø wrote: On 23/2/10 17:02 , Simon Fraser wrote: On Feb 23, 2010, at 5:00 AM, Tor Arne Vestbø wrote: Hey all, A reoccurring problem when trying to maintain layout-test results is differences in font and theme metrics for tests that dump the render tree. Often a test does not actually test font loading/rendering or theming, but has a piece of text or an input element somewhere in the test which causes the metrics in the render tree to be different, and hence the test failing. I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. You mean for example that the reference file of a css-border test that has some header-text describing the test would contain the same header-text but then a image to represent the reference of the css-part? It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On 23/2/10 17:34 , Simon Fraser wrote: On Feb 23, 2010, at 8:21 AM, Tor Arne Vestbø wrote: On 23/2/10 17:02 , Simon Fraser wrote: I think the correct longterm solution to this problem is to use reftests. A reftest consists of two files; the test file, and a reference file that should give the same on-screen rendering. When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. You mean for example that the reference file of a css-border test that has some header-text describing the test would contain the same header-text but then a image to represent the reference of the css-part? It could be an image, or it could be a configuration ofdiv elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Right. Seems to me we have all the pieces to the puzzle? DRT can ouput a PNG with --pixel-tests, we can add foo-reference.html to accompany foo-expected.txt, and run-webkit-tests can be taught to pick up on these reference-files and run DRT with pixel-tests on both and then use ImageDiff to compare them? Then we can gradually migrate tests to use references rather than expected render-trees? Tor Arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
Eric, On Mon, 2010-02-22 at 11:19 -0800, Eric Seidel wrote: I have a few questions (and I assume others are curious to the answers as well): - Who maintains this port? (Samsung I assume.) ProFUSION and Samsung. - Is this an active port? (Are there plans for the EFL contributors to work upstream?) Yes, we want to work directly with upstream. ProFUSION itself will keep working on it even if contracts are over, as it is a great component for EFL and we invest a good amount of work in EFL-related technologies as it is part of our service offerings. I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: - Rafael Antognolli antogo...@profusion.mobi, working on the port since August last year, did a great amount of work to get optimizations and fixes. - Gustavo Sverzut Barbieri barbi...@profusion.mobi, core developer of EFL, rewrote the WebKit/efl/ based on initial port by INdT. Is now the manager and internal ProFUSION reviewer. - Lucas De Marchi lucas.demar...@profusion.mobi, working to fill the gaps, like missing APIs in WebCoreSupport. - Raphael Kubo da Costa k...@profusion.mobi, worked on alternative backing store scaling to speed up zooming in mobile systems. - Does the EFL port have a DumpRenderTree implementation? (And if so, can it run the LayoutTests? What percentage pass?) Not yet, but we'll surely add it in future as we want to have automated tests just like Qt. Cheers, Leandro signature.asc Description: This is a digitally signed message part ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 9:58 AM, Dirk Schulze wrote: But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? Possibly with canvas. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
Hi, I like this concept of reftests because it seems easier to maintain and scales better on multiple ports than the current form of testing. On the other hand it has to be noted that it would apparently be much work to create reference tests for the current tests which doesn't appear to be a trivial task, furthermore the testing process would be much slower than now becasue, as I experienced it, running the pixel tests is really slow (at least on the Qt port) and we have to generate two pictures per test if we introduce reftests. BTW, does the python based layout testing framework, which was checked in recently, support pixel tests? AFAIK it can run multiple DRT's in parallel and speed up the testing process which wouldn't be bad a bad thing in this case either. Regards, Andras 2010-02-23 19:04 keltezéssel, Sam Weinig írta: On Tue, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de mailto:vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Feb 23, 2010 at 11:06 AM, Andras Becsi abe...@inf.u-szeged.huwrote: BTW, does the python based layout testing framework, which was checked in recently, support pixel tests? AFAIK it can run multiple DRT's in parallel and speed up the testing process which wouldn't be bad a bad thing in this case either. Offtopic, but yes it does. It doesn't support everything that run-webkit-test does (yet and I don't know where they are in the work). Regards, Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
I agree. We should organize cross-browser-test-fest and pick each other's brains. I like the idea of introducing ref tests and I think they are teh hot. My only concern would be to the amount effort of converting existing tests to that, so I think we should start small. :DG On Tue, Feb 23, 2010 at 10:04 AM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. -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] SmartDelete incorrect?
On Feb 22, 2010, at 6:47 PM, Ojan Vafai wrote: As best I can tell, smart delete/paste were added for Mail at http://trac.webkit.org/changeset/7627. Until now, I've understood that the correct Mac platform text editing behavior is what TextEdit does. I’ll check with some folks here at Apple to see if the NSTextView behavior in this case is considered a feature or a bug. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
The first step is probably to get the infrastructure in place so that new tests can be written as ref tests when possible. -Darin On Tue, Feb 23, 2010 at 11:24 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: I agree. We should organize cross-browser-test-fest and pick each other's brains. I like the idea of introducing ref tests and I think they are teh hot. My only concern would be to the amount effort of converting existing tests to that, so I think we should start small. :DG On Tue, Feb 23, 2010 at 10:04 AM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. -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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Fwd: Re: Announcing new port: EFL]
Hi all, sorry about the post to forward, possibly breaking the mail thread, but I was not subscribed to the list. Find below some comments: On Tue, Feb 23, 2010 at 5:09 PM, Leandro Pereira lean...@profusion.mobi wrote: -- Forwarded message -- From: Leandro Pereira lean...@profusion.mobi To: webkit-...@lists.webkit.org Date: Tue, 23 Feb 2010 14:44:24 -0300 Subject: Re: [webkit-dev] Announcing new port: EFL Eric, On Mon, 2010-02-22 at 11:19 -0800, Eric Seidel wrote: I have a few questions (and I assume others are curious to the answers as well): - Who maintains this port? (Samsung I assume.) ProFUSION and Samsung. - Is this an active port? (Are there plans for the EFL contributors to work upstream?) Yes, we want to work directly with upstream. ProFUSION itself will keep working on it even if contracts are over, as it is a great component for EFL and we invest a good amount of work in EFL-related technologies as it is part of our service offerings. I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: - Rafael Antognolli antogo...@profusion.mobi, working on the port since August last year, did a great amount of work to get optimizations and fixes. - Gustavo Sverzut Barbieri barbi...@profusion.mobi, core developer of EFL, rewrote the WebKit/efl/ based on initial port by INdT. Is now the manager and internal ProFUSION reviewer. - Lucas De Marchi lucas.demar...@profusion.mobi, working to fill the gaps, like missing APIs in WebCoreSupport. - Raphael Kubo da Costa k...@profusion.mobi, worked on alternative backing store scaling to speed up zooming in mobile systems. - Does the EFL port have a DumpRenderTree implementation? (And if so, can it run the LayoutTests? What percentage pass?) Not yet, but we'll surely add it in future as we want to have automated tests just like Qt. I'm quite sure Samsung people will step in and confirm their commitment to the success and continuation of the EFL port, as they are already doing with the core EFL itself. Browser engine, as we are all aware, is a critical component of any modern system and thus of high interest to them. But Samsung is not alone in this port. I can say about ProFUSION and Enlightenment, as I'm both owner of former and core developer of later. Enlightenment developers always liked and supported the WebKit-EFL port, even the first public release did by INdT got patches and applications developed around it. For one, we got ewww browser from Calaos guys, then I created eve based on it -- it lived in E SVN for a while, just dropped recently as we ended changing the public API completely (and for good). After WebKit-EFL lands completely, it is planned to have Elementary (our widget set/toolkit, http://trac.enlightenment.org/e/wiki/Elementary) widget encapsulating it... that will likely boost its usage. ProFUSION is about development and services, with the differentiation factor being EFL support. Our plans regarding WebKit-EFL are quite longstanding, even before being contracted by Samsung to do this port we planned to have a WebKit-EFL component in EFL. Of course Samsung's support helps supporting it, but even without them we do plan to continue investing manpower in this port as it is a key technology for our developments and services. I hope this are bit more clear now. This is not a drop-and-run ;-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing new port: EFL
On Tue, 2010-02-23 at 14:44 -0300, Leandro Pereira wrote: I am doing the cleanups required by the upstream task, merge of GTK+'s and EFL's build system, and will do further works on unifying both GTK +'s and EFL's codebases. There are other people working on this port, however: I think it's important to step in on this. I'm sure EFL and GTK+ will be able to share many things, and that the EFL port wants to use the same network backend, and media implementation we use, for instance. I'd like to ask potential reviewers to avoid giving r+ to patches that touch our build system or any of our backends without having us (g...@gnome.org, and xan.lo...@gmail.com) CCed in the bug so we can give it a quick pass, unless the change is trivial or just moving stuff around, as was the case for GOwnPtr, and GRefPtr. As everyone knows our build system is one of the slowest, so adding complexity to it may not be always a good idea. Also, we want to be sure that we are using the best tools available to GTK+ in the backends we maintain, avoiding lowest common denominator solutions, so we will likely prefer having alternate implementations for stuff that is not portable, rather than dumbing them down, if that's needed. Having said that, welcome to WebKit, and count on me to help get things rolling where possible! =) See you, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SmartDelete incorrect?
On Feb 22, 2010, at 6:47 PM, Ojan Vafai wrote: From the test: Tests: Smart delete when deleting the first word on a line. Expected Results: The first word and the space following the first word should be deleted. That is the correct result. But you only get smart deletion you use double click. So, specifically, if I have foo bar baz and I select the word foo using cmd+shift+right, hitting delete will delete the space in WebKit, but *not* in TextEdit. If, however, I select the word foo using cmd+right, hitting delete does not delete the space in either app. The TextEdit behavior seems more predictable (and sane). Command-shift-right selects a line, not a word. I think you mean option-shift-right. You have a point. Option-shift-right does not give you smart deletion behavior in Mac OS X NSTextView. Selecting words with double click does. The smart-delete-001.html test is testing a particular case of smart deletion and we do need a test for that fix. But it incorrectly depends on smart deletion mode being set when extending a selection by word. We probably need to turn this into two tests: 1) Test that extending by word does *not* give you smart deletion. 2) Test that double clicking at the beginning of a line to do smart deletion correctly deletes both the word and a space. It might be tricky to write (2) because I don’t know of a way to make a selection that will result in smart deletion with DOM APIs. Maybe execCommand(SelectWord)? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 11:06 AM, Andras Becsi wrote: I like this concept of reftests because it seems easier to maintain and scales better on multiple ports than the current form of testing. A reftest-style test seems like a good alternative to a pure text test. It can handle testing a lot more things but has a similar level of cross-platform portability. It’s great that reftest-style tests are not as dependent on font metrics as render tree dumps and not as dependent on rendering differences as pixel tests are. But depending on the reftest machinery is implemented these may only be good for simple tests that fit on one screen, a limitation that currently affects only pixel test results, and these kinds of tests can miss breakages that pixel tests or render tree dumps could catch. If we convert too many tests we’ll lose coverage. It’s probably common for both the reference rendering and the test case to both render wrong for the same reason. And in quite a few cases we can detect this type of regression even with just a render tree dump. Today we have two types of tests: 1) Plain text result only. 2) Render tree test plus pixel result. But in practice pixel results are often ignored entirely. I think that reftest-style tests if done right could be a great addition. -- Darin PS: Someone, please, rename DumpRenderTree! ;-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
Dimitri Glazkov: I agree. We should organize cross-browser-test-fest and pick each other's brains. I believe some Mozilla people are interested in working on a cross browser test suite framework, based in part on reftests. Jonathan Watt and fantasai are people to coordinate with on this, IIRC. -- Cameron McCormack ≝ http://mcc.id.au/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Google Summer Of Code 2010
WebKit participated in GSoC http://code.google.com/soc/ 2 years ago, I was wondering whether there was interest in doing so again this year? I've started a wiki page to collect ideas and potential mentors for this year: https://trac.webkit.org/wiki/Google%20Summer%20of%20Code%202010 The deadline for registering a mentoring organization is March 12thhttp://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline, so we need to decide by then where we stand. Copious apologies if I'm getting this wrong, but from what I understand - apart from one outstanding contributor, the WebKit community didn't have a very positive experience last time around. Perhaps if we try taking a more conservative approach this year. Both in terms of our criteria for accepting students and picking projects closer to the current core functionality of WebKit [rather than implementing totally new specs], that we might have a better experience. Best regards, Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler da...@apple.com wrote: But in practice pixel results are often ignored entirely. I think that reftest-style tests if done right could be a great addition. Pixel tests are run for every build by chromium, and regressions tracked there. :) Also, there are zillions of render-tree-dump tests which could easily be converted to plain-text tests. No one has yet written a tool to visualize how many tests we have with platform-specific results, but I would expect many of those platform-specific results could be removed by converting more existing tests to dump as text. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Feb 23, 2010, at 8:14 AM, Darin Adler wrote: On Feb 23, 2010, at 8:08 AM, Ariya Hidayat wrote: When the test is run, the browser loads both files, takes snapshots, and does a pixel comparison. Thus font differences between platforms become less of an issue. Isn't it our existing pixel test infrastructure? Or do you mean something else? In pixel tests, the expected file is a checked-in image. In addition, we still have a render tree dump; it’s not just pixels. In reference tests, the expected file is HTML; different than the test file, typically simple markup. Both files are rendered and the resulting pixels are compared. And I presume there would be no render tree dump. The challenge with reftests is coming up with different markup that's supposed to render exactly the same, but for unrelated reasons. While it's possible, for example, to compare a table layout to absolute positioned boxes, for some things you get down to primitives that can't be tested independently. For example you can test that b, strong and font-weight: bold have the same results, but none of that tells you whether bold in fact works. You could have a regression which caused bold to be completely ignored and would not be able to catch it with a reftest. Even in cases where there are truly independent ways to get the same visual result, it can be tricky to design both. That being said, it does do a good job of factoring out font differences. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to debug webcore,or disable some webcore loader?
we worked on webcore application base on embbed system(mips), used qt-webkit package (qt-embedded-linux-opensource-src-4.5.1). sometime our browser will crash when access few website. 1.is there any tools can analytics(which part of webcore cause crash)? 2.how can we disable some function by api not configure options ,like gif display, flash plugin,or something else? 3.till now ,we can not use gdb to trace into webcore,even use core dump , can not get symbol infomations? -- RyanYee ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Google Summer Of Code 2010
I'd love to see something related to MathML on this list but I'm not a committer. I'd need a committer volunteer but I'd be happy to be directly involved. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to debug webcore, or disable some webcore loader?
Hi, On Tue, Feb 23, 2010 at 5:26 PM, RyanYee/叶晔 god...@gmail.com wrote: we worked on webcore application base on embbed system(mips), used qt-webkit package (qt-embedded-linux-opensource-src-4.5.1). sometime our browser will crash when access few website. 1.is there any tools can analytics(which part of webcore cause crash)? 2.how can we disable some function by api not configure options ,like gif display, flash plugin,or something else? 3.till now ,we can not use gdb to trace into webcore,even use core dump , can not get symbol infomations? This is not the right place to ask such questions. This mailing is for the WebKit project development. You should direct such questions to webkit-help or webkit-qt where they will receive likely better answers (see them at http://lists.webkit.org/mailman/listinfo/). Regards, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Cancel image loading in webkit browsers
hi all I'm working on a (openstreetmap) slippy map for iphone browser. http://lamp2.fhstp.ac.at/~lbz/beispiele/ws2009/iphonemap4/simple.html At the moment I have a problem with cancel image loading. Simple example: script type=text/javascript document.getElementById(img).setAttribute(src,image1.jpg); document.getElementById(img).setAttribute(src,image2.jpg); /script Firefox does not load image1.jpg because it is not really needed. Webkit loads the image1.jpg and that is a big problem. Here a page that shows the effect more detailed: http://lamp2.fhstp.ac.at/~lbz/beispiele/ss2010/webkit/ Is there a way to cancel image loading in WebKit browsers? To change the src attribute does not stop loading - slow map thanks Bernhard ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
