Re: [webkit-dev] Documentation on internals of WebKit
Thanks for the pointers - I will have a look at the blog. Also, Conrad, my primary objective is to understand the code-flow in webkit and then to see if image decoding and javascript could be optimized. So, if you have any helpful pointers in this regard, please let me know. Regards, Aneesh On Tue, Jul 14, 2009 at 9:46 PM, David Kilzerddkil...@webkit.org wrote: On Tuesday, July 14, 2009 3:28:27 AM, Jack Wootton wrote: I'm sure there are other good blog entries, and the standard seems to be quite high, unfortunately I haven't found a page which lists the entries away from all the ...is now a webkit reviewer or allows a search of them. All I can do is provide this link: http://webkit.org/blog/ where you can trawl through all the blog entries searching for something useful. You may use Google to search the blog entries for you using the site: keyword: site:webkit.org/blog render tree http://www.google.com/search?client=safarirls=enq=site:webkit.org/blog+%22render+tree%22ie=UTF-8oe=UTF-8 Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
On Thu, 2009-07-09 at 14:32 -0400, tonikitoo (Antonio Gomes) wrote: I grew up listing and seeing people not writing their emails *as it* and publishing on the internet so would replacing m...@apple.com by mjs at apple dot com be a good practice ? I always failed to see much wisdom in this. It might be because I always used highly published email addresses, but then again, I would much rather have something I can just click/copy instead of copy-edit. -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
On Fri, 2009-07-10 at 18:18 -0700, John Abd-El-Malek wrote: this changelist. Operations such as gcl upload CHANGENAME (upload to Rietveld) work on the group of files at the same time (also things like gcl diff/commit/revert). The nice thing about it that on such large codebases, developers will often have unrelated changes, and this avoids having to unapply/apply frequently. This looks like a hack that is fixed by using a proper tool, such as git, to me. -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Feature request] Bugzilla: default unassignee emails to per component.
On Mon, 2009-07-06 at 13:15 -0700, Darin Adler wrote: To follow bug activities on a particular component, we should probably add a Bugzilla watch feature that lets you follow bug activities on a component. I was talking about this with Mark Rowe this week: what we need is to enable the QA Contact feature, and point components' QA contact to 'fake' email addresses, so that it is easy to 'subscribe' to them. In GNOME's bugzilla the default assignee and QA contact both are fake email addresses named like this: project@gnome.bugs. The good thing of having it this way is that, even if a developer assigns the bug to himself, the QA contact keeps receiving notifications, and thus alerting interested people of changes. I would like to see something of this sort implemented, because I would really like to follow the WebKit Gtk component. RSS helps, but is so very limited compared to receiving copies of bug mail. See you, -- Gustavo Noronha Silva g...@gnome.org GNOME ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] S60WebKit MIME type question
One thing to look out for is that I don't thin the NPAPI is fully implemented on S60. it is pretty much fully implemented on S60 AFAIK, though the API got symbianized for some reason, by changing some data types (char*) to Symbian types (HBufC*). http://trac.webkit.org/browser/S60/trunk/WebKit/Plugin/inc/npapi.h Zalan. On Tue, Jul 14, 2009 at 5:08 PM, Jack Woottonjackwoot...@gmail.com wrote: Just to add, you are right, S60 browser uses ECOM to load a list of plugins at runtime that implement the interface 'CEcomBrowserPluginInterface'. It stores meta data about each plugin, such as the MIME type it handles and the UID of the DLL implementing the plugin. The browser then loads the plugin if the MIME type found in the object or embed tag matches. One thing to look out for is that I don't thin the NPAPI is fully implemented on S60. On Tue, Jul 14, 2009 at 4:04 PM, Jack Woottonjackwoot...@gmail.com wrote: Plugins should follow the NPAPI (https://developer.mozilla.org/en/Gecko_Plugin_API_Reference) and so it shouldn't really matter if it pre-dates WebKit. No doubt someone else on this mailing list can offer more help here (since I'm new to webkit). If you sign up to the Symbian Foundation, then you can browse S60 code online. Unfortunately having had a quick look it seems there are no reference plugin implementations in the code. There are some s60 specific plugin files, using the Symbian Foundation cross referencing tool, they can be found in: /MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins (http://developer.symbian.org/xref/oss/xref/MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins/) On Tue, Jul 14, 2009 at 3:35 PM, Sam Critchleyscritch...@gypsii.com wrote: Hi Jack, Thanks for taking the time to reply. The Nokia Platform Services resources are great, but currently only available in WRT on their S60 5th edition devices (5800 and N97). I think we're also going to look closely at the plug-in route as well - I wonder if there's a repository of standard plug-ins somewhere... I found the following on S60 browser plug-ins: http://www.forum.nokia.com/main/resources/technologies/browser_plug-in_api.html Unfortunately I think this pre-dates the WebKit browser, so I'm not sure it still applies I did find some documentation on Ecom plug-ins as well. I assume that's also available through S60WebKit as well. The main question is whether there's a repository of existing plug-ins somewhere (e.g. if there's a camera plug-in) or if you have to code your own. Thanks, Sam On Jul 14, 2009, at 2:46 PM, Jack Wootton wrote: If a browser finds a MIME type it cannot display (for example from an embed or object tag) then is will iterate through available plugins and load the plugin which handles that MIME type. Regarding camera on S60, you may want to take a look at: Nokia hvave released a beta version of the their new Platform Services (JavaScript API to you and me), this includes a camera API (the download includes a sis file which adds the new api to the device, but it also comes with a JavaScript library which allows pictures to be taken using the camera app and displayed using JavaScript). There are also sample widgets which use the camera API. http://www.forum.nokia.com/info/sw.nokia.com/id/cccea743-f4e5-418f-ad9f-0a7a7f50868f/Nokia_Platform_Services_2_0.html For something which isn't in beta, Nokia provide a JavaScript API for launching 3rd party applications (you just supply the UID of the app you wish to launch - I don't know how you can transfer data from the app to the webkit environment though). The API is part of Nokia's Web Developer Library found here: http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-4D13AF3F-4733-44E7-996F-F27A11C9D6BF_cover.html You want to look at Web Developer's Library 1.7 Web Runtime widgets Developing widgets Web Runtime API reference JavaScript Service API reference On Tue, Jul 14, 2009 at 1:21 PM, Sam Critchleyscritch...@gypsii.com wrote: Hi, Apologies for the very basic question, but I'm trying to find out how you can use custom MIME types in WebKit on S60 (3rd and 5th editions). We're looking at doing something like triggering the S60 camera app using a camera button in a web form (which is accessed in an app using Webkit for content display), take a picture, insert it into the form, and POST it to the website. Can anyone point me to information on how/whether we could do this? Thanks, Sam *** Sam Critchley VP, Products and Co-Founder GyPSii http://www.gypsii.com/ scritch...@gypsii.com GyPSii HQ Amsterdam Mobile: +31 6 28 233 133 Landline: +31 20 715 5915 Fax: +31 20 524 8896 Join the GyPSii mobile lifestyle Download GyPSii to your phone Latest GyPSii Place *** ___ webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
I don't want to open the can of worms that is git vs other source control systems. However given that the instructions for developing WebKit are for svn and there already exists svn-apply/unapply scripts, I think there are enough WebKit devs using svn that warrant improving this process flow. On Wed, Jul 15, 2009 at 12:52 AM, Gustavo Noronha Silva g...@gnome.orgwrote: On Fri, 2009-07-10 at 18:18 -0700, John Abd-El-Malek wrote: this changelist. Operations such as gcl upload CHANGENAME (upload to Rietveld) work on the group of files at the same time (also things like gcl diff/commit/revert). The nice thing about it that on such large codebases, developers will often have unrelated changes, and this avoids having to unapply/apply frequently. This looks like a hack that is fixed by using a proper tool, such as git, to me. -- Gustavo Noronha Silva g...@gnome.org GNOME ___ 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] Changes to prepare-ChangeLog
On Wednesday 15 July 2009 03:59:53 pm John Abd-El-Malek wrote: I don't want to open the can of worms that is git vs other source control systems. However given that the instructions for developing WebKit are for svn and there already exists svn-apply/unapply scripts, I think there are enough WebKit devs using svn that warrant improving this process flow. I think Maciej recently posted a very good action plan for how we can improve the contribution process. In that action plan it was suggested that certain things can be done first (Phase #1 and Phase #2) and then for things that might involve a look at other revision control systems (Phase #3) we can look at those after. This would seem to fall into Phase #3. I think Maciej's was a good action plan. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote: * Phase 1 * A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to being there. I'm going to help him refine this tool to the point that submitting a patch has only one step - a single command will make the patch, file a bug if needed, attach the patch to the bug, and flag it for review. B) Make it really easy to commit a patch. Again, I think bugzilla-tool is the right path to achieving this. C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. Speaking of your action plan... I've had a look at C.3 and was going to try to modify the bugzilla tools to highlight as you suggested. But after looking at the review queue over the last few days I'm not sure it is necessary or that it would help to fix the problem. http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Wed, Jul 15, 2009 at 1:14 PM, Adam Treat tr...@kde.org wrote: http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? I think it would still be effective as it provides a concrete measure of success in getting reviews completed in a timely manner. Having such a highlighting would hopefully provide the motivation to change the fact that half the queue would be highlighted. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
I'll try to get bugs filed for any part of the plan that isn't done by tomorrow, and I'll tag them with a keyword so we can track progress. On Jul 15, 2009, at 1:14 PM, Adam Treat wrote: On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote: * Phase 1 * A) Make it really easy to submit a patch. Eric's bugzilla-tool is close to being there. I'm going to help him refine this tool to the point that submitting a patch has only one step - a single command will make the patch, file a bug if needed, attach the patch to the bug, and flag it for review. B) Make it really easy to commit a patch. Again, I think bugzilla- tool is the right path to achieving this. C) Improve the way we get attention from reviewers. I think we should do three things here: C.1) Split review queues, based on our emerging [Bracket] convention for patches needing specialized review. If we find more areas of specialty besides ports, we can add new [Bracket] tags. C.2) Improve the quality of emails sent C.3) Highlight in a special way patches that have been waiting for review longer that some minimum period (a week?). These could be highlighted visually in the review queue, and maybe would send extra review request emails automatically. Speaking of your action plan... I've had a look at C.3 and was going to try to modify the bugzilla tools to highlight as you suggested. But after looking at the review queue over the last few days I'm not sure it is necessary or that it would help to fix the problem. http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? I tend to use this URL to scan the review queue instead: https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F I have few problems with the official review queue page, and maybe what we need to do is come up with one version that has the benefits of both. Here are the things I don't like about the pending-review page: 1) Uses two lines per bug plus a table border, so you can see fewer items at once. I can see 13 in a max-height browser window on my MacBook Pro, compared to 25 using my preferred query. 2) It splits out bugs with a specific requestee into separate lists, this is I think harmful to prompt review because usually those bugs don't really need review from one specific person. 3) Lists multiple patches on a single bug separately. I don't like this, usually such patches should be reviewed together, and it inflates the list. 4) No summary count. Here are things I like about it, compared to a vanilla query: 1) Skips most of the irrelevant fields, like priority, assignee, status, etc. 2) Sorts by date of request. I would love to have a single view that combines the best of both ways of viewing the review queue. That being said, I think highlighting old bugs is good to do right now. Even though today, 50% are older than a week, we don't want that to be the norm. By marking them in a clear way (and maybe further highlighting patches older than a month), we can help get to a point where this is the exception, not the norm. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Saturday, July 11, 2009 11:55:36 AM, Maciej Stachowiak wrote: On Jul 11, 2009, at 9:39 AM, Darin Adler wrote: On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See from October 2007. I guess the reason I hadn't noticed is that I often to svn update to update only the directory I'm working on. Maybe we need an update-subtree command. Why don't you update your whole source directory at once? I would think that updating only subdirectories could make the source tree out-of-sync and cause build problems later. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch process - let's make it better
On Jul 15, 2009, at 4:13 PM, David Kilzer wrote: On Saturday, July 11, 2009 11:55:36 AM, Maciej Stachowiak wrote: On Jul 11, 2009, at 9:39 AM, Darin Adler wrote: On Jul 10, 2009, at 4:23 PM, Maciej Stachowiak wrote: Perhaps we should make update-webkit (or some new wrapper type tool) run resolve-ChangeLogs automatically. Dave Kilzer had the same idea when he created resolve-ChangeLogs, so update-webkit does run resolve-ChangeLogs automatically. See from October 2007. I guess the reason I hadn't noticed is that I often to svn update to update only the directory I'm working on. Maybe we need an update-subtree command. Why don't you update your whole source directory at once? I would think that updating only subdirectories could make the source tree out-of-sync and cause build problems later. Updating just JavaScriptCore is often useful and a lot faster than a full update, especially when preparing to commit a patch that I have already tested. I agree that full updates are usually the right thing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
On Mon, Jul 13, 2009 at 4:56 PM, Maciej Stachowiakm...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. I would need to discuss it with my student, but what about the brand new Haiku port being the gyp guinea pig? For those who don't know, I am mentoring a student in the Google Summer of Code for the Haiku operating system (http://www.haiku-os.org) and we are working on a native Haiku web browser with WebKit as the rendering engine. I don't know if our port is any better of a choice than the Wx port, since the resources are also small (just two of us for now) and we aren't even in the WebKit tree yet, but I think we still might be a good choice because: 1) We obviously don't yet have a production browser using our port so breakage isn't an issue. Plus only my student (Maxime Simon) and I are working on it. 2) I have decent experience with build systems and think I could handle working with gyp and writing a new back end. 3) Haiku generally uses Jam for building and we would like our port to do the same. Rather than adding Yet Another Build System to WebKit, we could use gyp and write a Jam backend for it. This can therefore serve as a test of gyp for another platform as well as for another backend. I would rather not have to maintain a Jamfile for WebKit if I can avoid it, and I certainly don't want to burden the other WebKit developers with having to maintain it for what is now (and may forever be) a tiny port. Though we certainly hope Haiku's popularity increases in the future (it hasn't even had a first release anyhow, so there is plenty of room to grow.) Anyhow, I'd be interested in hearing what other people think. -- Regards, Ryan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
