Re: [webkit-dev] CMake for Apple's Windows port
If my memory serves me the problem was that Apple couldn't figure out how to get cmake installed on the Apple build system machine. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke [dpra...@chromium.org] Sent: Thursday, April 12, 2012 2:06 PM To: Patrick Gansterer Cc: WebKit Development Subject: Re: [webkit-dev] CMake for Apple's Windows port I think this is great; I've been meaning to spend some time on the apple win port trying to fix the remaining bugs holding up the switch to NRWT, but the fact that the apple win port still uses VS2005 is definitely an impediment (yes, I can probably just pull the binaries down from a bot for my purposes, but I'd really like to be able to build it). Patrick, have you documented what all you need to install on a Win box in order to be able to run CMake and do the build? Can someone from Apple weigh in on whether switch to CMake would be feasible? -- Dirk On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com wrote: Hi, it's more than a year since the last discussion about the build system of Apple's Windows port. In the meantime I merged most of the general changes into the CMake files in the repository and have a working patch with a few CMake files at [1] as written in [2]. I don't think that it is ready to replace the existing vcproj files already, but I like to hear all points needed to do that. Adding CMake files for the WinCairo port (which uses the vcproj files too) will be very easy when the Apple version has been added. Here some benefits to the CMake version: 1) Shared build system: The shared files are already used by the Blackberry, EFL and WinCE port, so only the list of platform specific files needs to be maintained. 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 version of the required executables (bison, gperf, flex, perl and python) like the WinCE port does already (see [4]). 3) Less Solution targets: Some of he current vcproj files only used for triggering Makefiles. The vcproj generates more native vcproj files, which e.g. allows clicking on one of the IDL files to generate the corresponding files. 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows an easy transition to other (newer) Visual Studio versions, since every developer can choose his preferred version. 5) It's possibe to create Makefiles: The output of the windows buildbots shows much unwanted messages. Using Makefiles on the bots can produce cleaner logs and take advantage of all cores when used with JOM [7]. Would be great if people who use the current VS Solution can give the CMake version a try and provide some feedback about it. BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a positive response. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html [3] https://bugs.webkit.org/show_bug.cgi?id=48166 [4] http://trac.webkit.org/wiki/WinCE#Build [5] https://bugs.webkit.org/show_bug.cgi?id=53445 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html [7] http://qt-project.org/wiki/jom [8] https://bugs.webkit.org/show_bug.cgi?id=73100 -- Patrick ___ 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 - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
With svn up you are just as likely to see a conflict. From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:12 PM To: Adam Treat Cc: Ashod Nakashian; WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat atr...@rim.commailto:atr...@rim.com wrote: There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason jma...@rim.commailto:jma...@rim.com wrote: It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it. What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches? What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier? The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run svn up. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
Indeed it is. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Carlos Garcia Campos [carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:38 PM To: Alexis Menard Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Yes, I think it's possible with a hook in the server. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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 - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving to Git?
There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [rn...@webkit.org] Sent: Thursday, March 08, 2012 3:00 PM To: Ashod Nakashian Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote: And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial. I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN. I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on. - Ryosuke - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with review of EFL CMake patches?
Bill, could you look over these CMake files and give it an informal review? On Monday 03 May 2010 02:37:22 pm Gustavo Sverzut Barbieri wrote: Hi all, As some of you know, the EFL port is almost all merged, we just lack a build system in SVN by now. We initially started with automake, sharing with GTK, but it was quite slow and the Gtk guys had the willing to get it clean before any changes were made, in order to avoid it to get worse. We did an initial cleanup, but then we figured out CMake would be a better option. By the time we were almost done with CMake build system, this mail list started discussing build systems and CMake was one of the considered options, making us quite happy at the time. We got the system done, but then people just started to move files in SVN making our lives quite hard these last weeks. Fortunately things are calm now and the system compiles quite well. We did the patches splitting the common and EFL specific parts, so people may add new ports with minimum effort. Of course as more systems are added, we should rearrange things that we overlooked at first, but that should be easy. What we need know is someone to review https://bugs.webkit.org/show_bug.cgi?id=37945 and land it to SVN. Note that we're trying to get EFL to build with SVN, not to build the most perfect CMake build system ever. So let's be reasonable with comments and suggestions, particularly those to make it generic as we consider that these should come when people start moving their ports to CMake. We surely can help with such tasks, we have a partially working GTK port that we may finish one day and suggest to webkit-gtk the move to it. BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake vs. Apple's build farm
Can someone from Apple comment on whether it is possible to include the sources to CMake and then the CMake could bootstrap itself with only dependency on the compiler? This would seem an acceptable solution, no? Adam On Tuesday 20 April 2010 01:06:43 pm Bradley Nelson wrote: Would prebuilt checked-in binaries be an option? Can cmake run out of an arbitrary directory? -BradN On Tue, Apr 20, 2010 at 5:25 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On 4/20/2010 5:13 AM, Maciej Stachowiak wrote: 1) None of the Mac builders have CMake installed. 2) The organization that maintains the Mac builders is not willing to let teams use any build systems to build that do not come with the OS, or to install any custom binaries on the builders, because builds need to be reproducible. So, long term is there a way for CMake to come with the OS? I mean gmake is part of the OS, python seems to be OK, how does a tool get promoted to such a level? 3) CMake is not part of the standard Mac OS X install for any shipping version of Mac OS X. 4) LLVM compiles using a separate Makefile-based (and apparently autoconf and autogen based) build system in OS builds. 5) LLVM uses CMake to build on Windows. 6) The build organization is more willing to install custom tools on Windows builders. I think this rules out using CMake to build the mac port. Even if we got it set up, we'd need to maintain some kind of parallel build system for production builds via the build farm, which would negate the benefit. It might be possible to use CMake for Apple's Windows port, but if we switch away from native project formats at all, ideally we'd like to switch both ports to the same build system. I am wondering if you could include the sources to CMake inside the source tree for the Mac build farms. CMake really only depends on the C++ compiler, and that is part of the OS. You could use CMake's bootstrap script to build it. Then run that CMake to generate the build. I could help you create a lean CMake that would only build the features used for the build of WebKit. Since gyp does not require any special software to be installed merely to build, it seems like a more plausible option at the moment. Note: this is not to hate on CMake, I just don't want to end up in a position where we have to maintain two parallel build systems for the Mac port, or fight with other organizations about the operation of the build farm. Requiring CMake to be installed at build time seems like a showstopper from that point of view. So, rather than install one program, Apple would rather have one of its developers maintain a forked build system. I would of course like to see this change. I would think it would be possible to change this. I suppose if enough tools that Apple uses move to CMake, it would become OK. Anyway, what do think about building CMake with the project? -Bill ___ 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] CMake vs. Apple's build farm
CMake is BSD style license so I don't think that is a problem. I understand that a lot of this is hypothetical and the last thing we want is to make life more difficult for our developers. I'm just trying to understand up front whether or not there are legitimate show stoppers before people go through a lot of effort trying to convert Apple's Windows port to a CMake build for demo. Adam On Wednesday 21 April 2010 02:24:26 pm Darin Adler wrote: On Apr 21, 2010, at 9:45 AM, Adam Treat wrote: Can someone from Apple comment on whether it is possible to include the sources to CMake and then the CMake could bootstrap itself with only dependency on the compiler? This would seem an acceptable solution, no? Hard to comment on something that’s hypothetical, but given the high level description, it’s not impossible. Part of this depends on the license for CMake. And it will be a lot of work for someone at Apple. The platforms where this sort of thing is most difficult are older ones where WebKit is built with old versions of development tools. Even small changes to the build system create challenges for my team here at Apple. We do our best to hide this complexity and prevent it from directly affecting the others working on WebKit. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview
I'd really like to see this on bugs.webkit.org with a proper patch splitting out the CMake portion. I understand that this is primarily motivated by your desire to see EFL port build, rather than to solve the build system problem, but this *DOES* add a new build system to the tree. I think we have to see if we can get the Apple showstopper cleared up. I think installing CMake sources and getting Bill's help to create a streamlined CMake binary is a great idea. Adam On Tuesday 20 April 2010 08:29:55 am Gustavo Sverzut Barbieri wrote: On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer par...@paroga.com wrote: Hi, Gustavo Sverzut Barbieri: Find attached 2 patches. ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that implements CMake support for WebKit-EFL and also adds the missing patches to make it compile (but runs with some bugs, needs updating to some api changes). Apply it if you want to compile the port (also get EFL from svn, see http://svn.enlightenment.org/) ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single CMakeLists.txt and support *.cmake modules Please take a look if you are interested in CMake for WebKit-EFL. If you know CMake already, review it and send comments. My team just started with CMake some days ago. Can you please post the patch at bugs.webkit.org. will do as soon as we get the .pc generated and installed, otherwise the external programs cannot know how to link to it. Maybe you can split it into a CMake and a other stuff part. (Was it already before you merged it?) It is already, the patch is at http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch I'd like to give you some feedback at the bug comments. The CMake file should be split into different projects for example. Hum... I saw everywhere that it was common to split in multiple directories, particularly for JavaScriptCore and WebCore. But given that I wanted to keep it simple, I forced it to be one single file to make merge into SVN easier. I was also worried about the propagation of settings and flags to the sub-folders. But yes, I notice that it will make easier to use INCLUDE_DIRECTORIES() as we'd just have one target per directory. Our primary goal is not to join into the recent GYP x CMAKE discussion, but we need our EFL port fully landed to avoid the overhead we're doing now. We were using the GTK autotools, as we were more familiar with it, but given it is slow and messy, the GTK guys did not want to merge our patches right away, requesting a cleanup of existing code first. We did part of the cleanup and CMake in parallel, but CMake worked out quite nice and we don't plan to use GTK's autotools anymore (but we did send the cleanup we achieved until now). That is to say that making it simple to be merged is our first aim. One more thing I'd like to kindly ask you is if you can also post patches to the CMake files. This is because our team is already suffering to match the latest WeKit changes (we have already a huge queue waiting to be merged, and now patches have to be rebased and so on). So the more help, the better! :-) BR, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Adam On Friday 16 April 2010 12:42:01 am Peter Kasting wrote: On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier kev...@theolliviers.comwrote: Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're probably better off trying to synchronize the build systems automatically in some way. My perception is that Qt developers will want to use qmake, GTK will want to use autotools, etc. and while some build systems could certainly be merged (e.g. as you say the Win and Mac projects for WebKit itself could be gyp-generated), I don't think we'll ever really narrow it down to one master system for a variety of reasons. I do, however, think we may be able to narrow the 'build system updating' process down to one step / one script that updates all ports simultaneously, and do so without too much effort. If I'm not mistaking you, that seems to be the route Evan is discussing, with his concrete proposal being to investigate the feasibility of making gyp be the mechanism by which various different build systems can be generated from a single place (rather than seven). Or is this not what you were saying? Since most build systems out there have their data stored in either XML or plain text, converting a build file list from one build system's data format to another is probably not more than a few hours of Python hacking, if that. Indeed, we already have MSVC/XCode/makefile generators for gyp, I would assume that given those, a generator for e.g. qmake wouldn't be hard. I really think someone should seriously consider investing some time and resources into improving this issue though, updating a build system doesn't take long but updating 7-10 build systems on almost a daily basis probably adds up to some pretty significant amount of time and energy that could probably be spent on better things. I think that is the shared viewpoint that has led to this discussion. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Cheers, Adam On Friday 16 April 2010 05:34:45 pm Eric Seidel wrote: I don't see this as a decision needing pre-approval. This is a decision needing code. No one has tried to make Mac, Win, or other ports use a common system yet. Obviously converting them in the end requires buy-in from those ports. But producing a demo doesn't/shouldn't. I eventually plan to look at this task. When I do, I'll take a peek at CMake. Someone just needs to sit down and build something. Then we can make an informed decision. -eric On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote: On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote: Hi, Adam Treat (tr...@kde.org) suggested that I join this list to talk about CMake as an option for a unified cross platform build solution. My name is Bill Hoffman. I am the lead CMake developer. My company Kitware created and supports CMake. I think CMake would have a lot to offer the WebKit developers. If you are not familiar with CMake, I did a google tech talk in December which can be found here: http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata Another article about how KDE switched to CMake can be found here: Why the KDE project switched to CMake -- and how http://lwn.net/Articles/188693/ If you are interested in moving to CMake, I would be interested in helping. If you have any questions about CMake, fire away! Thanks. -Bill I asked Bill to introduce himself here because I think CMake represents the best hope for WebKit to find a way out of the current build system proliferation we are experiencing. Of the meta-buildsystems in existence I think CMake is by far the most powerful and mature. CMake is by far the most widespread and supported. It is already used successfully by Open Source projects of a comparable scope to WebKit and with similar cross-platform needs: LLVM, KDE, Boost. I know that WebKit already has GYP and QMake meta-buildsystems, but to my knowledge both are inferior to CMake. In fact, I do not think CMake is lacking in any important way to the features of GYP. What's more, the WebKit project has already had a CMake based buildsystem. This is what the 'Unity' nascent QtWebkit port used originally. I think we should re-introduce it and seriously consider using CMake as a cross-platform solution to our build system proliferation issues. I highly encourage you all to view the google tech talk above as it gives a great introduction to CMake. Cheers, Adam ___ 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] CMake as a build system?
On Friday 16 April 2010 06:21:39 pm Maciej Stachowiak wrote: On Apr 16, 2010, at 2:45 PM, Adam Treat wrote: Sure. Having Bill's and Kitware's help will hopefully make it easier to produce such a demo using CMake. I pledge to help. We can start with this: http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853 Can CMake generate native Xcode and Visual Studio project files? There are some people who consider it important to be able to edit, build and debug in the IDE. Can it handle generated sources well? It was designed to do precisely that :) Bill can speak to this, but the google tech talk gives a great overview. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake as a build system?
On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote: Also: how hard is the dependency on being installed? Is this a solvable problem if it turns out to be a showstopper for some folks? It has to be installed, if this is a show stopper, then it is a show stopper. To be clear, it just has to be in the path, right? Which I think could be managed ;) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote: Given what proportion of overall maintenance work on WebKit I done by Apple, I don't think anyone is entitled to veto us adding a new API Whaa? Who is talking about veto of Apple's work? Rather, I am suggesting that it would have been helpful if people in the broader community had a chance to review and discuss the patches before they were summarily landed. To be clear, I have not had a chance to review the patches (I'm actually pretty excited by the ideas and I've no doubt the work is technically excellent given the people involved) and see what is going on before they were pushed into the tree. It just would have been nice to give the *community* more of a heads up and a chance to have a look and offer opinions. This isn't about 'Apple' and 'veto' so much as it is about a significant new piece of tech being added to WebKit without going through the common procedure where a bug is opened a patch is attached webkit-dev is notified and people have a chance to discuss and poke a little. It just felt a little rushed especially so that the new stuff is being landed with style errors. I normally wouldn't quibble with style issues, but others have and new ports have been required to fix any and all styling issues before landing. layer. I also recall that when the Chromium API layer was added, no one asked permission, you just let us know that it was coming. Which is fine - API layers are pretty low cost, and I hope no one would argue against a major contributor including theirs. What's more, this is really a parallel version of existing well-maintained API layers. I do not like the implication that Apple should have to ask permission for what we do with the WebKit API on Mac OS X. We do not ask the Qt or Gtk developers to explain all their API choices. Again, I think it'd be good to get away from 'Apple' vs 'Others'. The community as a whole has some fairly common procedures for landing large changes like this. This just felt a bit rushed. And no doubt I was a bit taken by the name 'WebKit2'. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote: There were in fact bugs opened with patches attached, and webkit-dev was notified before any of the patches were committed afaik. However, Indeed, but the post to webkit-dev had no link to the patches and no time was given for anyone in the community who hadn't been privy to the private development to have a look before it was landed. the new piece of tech really is just a new API layer for the Mac and Win ports. We are interested in other people being able to reuse this technology, but fundamentally, this is an extension of our existing APIs. I understand this now. I definitely didn't get this impression at first, but probably my mistake. It was in retrospect not a good choice of name. We hoped it would be a very boring choice. Think of it as WebKit/mac/async/ or something and see if you might feel differently. It does throw things in a different light. However, I still think it would have been nice to give people an opportunity to have a look and a little time for discussion before it was landed. I lament that we have so much private development in the community although I understand the necessity at times. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Friday 09 April 2010 04:53:31 pm Cameron Zwarich wrote: In the past we have accepted the Chromium port despite it having a new JS engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated changes, numerous layering violations, and seemingly unnecessary changes or replacements of platform-independent code. All of these problems were discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they were largely ignored and still exist today. In the past we've also had new ports land with some fairly hefty requirements including fixing of all style violations, layering violations, and generally going through the code with a fine tooth comb. Were that all ports and contributions received the same treatment. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi, Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? Cheers, Adam On Thursday 08 April 2010 08:58:22 pm Maciej Stachowiak wrote: On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. It will be available as a public API, but as Darin explained, it's up to individual ports whether to wrap this API, expose it directly, or do some combination. For the Mac OS X API, we will be doing a combination. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? I think that would be up to the individual ports. We expect that on Mac OS X, we will have to support the classic WebKit API for a long time, perhaps indefinitely, in parallel with the new WebKit2-based API. Regards, Maciej ___ 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] Announcing WebKit2
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Bulk] parallel painting
I think we'd be interested to see a cross-platform version from the perspective of the OpenVG graphics backend. On Sunday 04 April 2010 01:32:54 am Zoltan Herczeg wrote: Hi, I am working on a parallel painting feature for WebKit (bug id: 36883). Basically it records the painting commands on the main thread, and replay them on a painting thread. The gain would be that the recording operation is cheap. Currently it is Qt specific, but I could make it more platform independent if other ports are interested. Zoltan ___ 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] webkit installation on linux
This is not the correct forum for these types of questions. http://lists.webkit.org/mailman/listinfo/webkit-help This above is a better forum, but such basic build questions should likely be solved with google and a bit of elbow grease. Cheers, Adam On Thursday 11 March 2010 10:24:20 am Shivaprasad P wrote: Hi all, I want to install webkit on fedora fc7 linux. I installed gperf-3.0.4, glib 2.21.6 and downloaded WebKit-r55740 version got from http://nightly.webkit.org/builds/trunk/src/1 . I am getting following error: configure: error: Cannot find icu-config. The ICU library is needed. Can anybody tell howto resolve this error and is it I am installing right webkit version for fedora linux fc7? Regards Shiv The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Embedded Software India Pvt. Ltd. (TESI),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Bulk] how to get response in QtWebKit
On Thursday 11 March 2010 10:50:19 am Meir Yanovich wrote: Hello all im beginner with QtWebKit i build simple web frame that loaded page ( server side ) and when from this page i submit data i like to catch the response string from the server in the c++ side how can i do that ? Again, this is not the correct forum for these questions. This mailing list exists for WebKit contributors to discuss ongoing development of WebKit itself. You can use this forum for your questions: http://lists.webkit.org/mailman/listinfo/webkit-help Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unofficial reviews (WAS: Why I'm reviewing patches outside my area (and why you should too))
On Wednesday 10 March 2010 07:06:16 am Jeremy Orlow wrote: I can give you a success story though: michaeln is probably the most qualified reviewer of WebSQLDatabase code these days. He looks at most patches that go by, and I think on average he offers more and better comments than the official reviewers. The few WebSQLDatabase patches I have reviewed, I asked for Michael's sign off before r+ing. I'd say that the solution is to nominate him for reviewing then. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Need recommendation for Webkit port to use
This is the incorrect forum for this kind of question. Please use webkit-help instead. http://lists.webkit.org/mailman/listinfo.cgi/webkit-help Thanks, Adam On Wednesday 27 January 2010 08:15:40 am Duke5 wrote: Hi, I am looking to embed Webkit into an application. In order to do this, I need a port that meets the following major requirements: - Is Windows-based - Supports a COM-based interface that is callable from VB6 - All dependencies must be redistributable with a closed-source, for-profit app - Does not require Safari to be installed So far, I've only found ports that meet some of these requirements. Please keep in mind this is for an enhancement to an existing app and this needs to be implemented with minimal resources, so targeting a platform/architecture/language other than Win/COM/VB6 is not really a viable option here. Any help would be appreciated. Duke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Serialization?
On Friday 22 January 2010 12:09:14 pm Darin Adler wrote: On Jan 22, 2010, at 7:16 AM, Christopher White wrote: Is it possible to save the DOM resulting from the parsing of HTML / CSS into a file and then read it back instead of re-parsing the HTML (similar to Java object serialization). WebKit has a feature called web archives that does something like this. Correct me if I'm wrong, but he said without re-parsing. The WebArchive definitely needs to be reparsed, right? Christopher White: I don't think what you are asking for exists. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question about PopupMenuClient
On Thursday 07 January 2010 05:44:46 pm Kenneth Christiansen wrote: I guess that it is not safe to assume that PopupMenuClient::hostWindow() is always a Chrome, so would it be acceptable substituting the Why do you say this? Maybe add a virtual like: virtual PlatformPopupMenu platformPopupMenu() const = 0; to HostWindow.h ? Much like Qt already returns QWebPageClient for 'platformPageClient()' ? Maybe you can even re-use this QWebPageClient for the popup menu delegation too? Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit html parser api?
Hi, This list is not the correct place for this kind of question. Rather, you should use the webkit-help mailing list: http://lists.webkit.org/mailman/listinfo/webkit-help Thanks! Adam On Wednesday 06 January 2010 06:21:34 pm Tomas Ramirez wrote: Hi, I am wondering if I can use a subset of webkit as an html parser framework. Before I become entrenched in webkit development, could you let me know if this is even possible? I know that webkit is a web browser engine, so I suspect that the parsing might be hidden. Thanks, - Tomas ___ 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] Should we ever change style guidelines?
On Thursday 10 December 2009 01:34:12 pm Peter Kasting wrote: But if !color.green() is potentially confusing, then certainly it is just as confusing (in fact moreso) without the surrounding color.blue() and color.red() tests in Adam's example. Yet Adam cited consistency with surroundings as the reason to prefer == 0 in this case, which suggests that he'd be fine with an isolated test of this value. It doesn't suggest anything of the sort. The two cases are not mutually incompatible; both are confusing and in my mind call for exercising reviewer discretion over the style guide. My point is that your argument (and Adam's) is not actually an argument for reviewer discretion, or promoting consistency over whatever the style guide says; it's an argument that the style guide is wrong to prefer !foo over foo == 0. No, *it is* an argument for reviewer discretion. And I *do not* think the style guide is wrong for the *guide* to prefer !foo over foo == 0! I just think there are exceptions. And that in the end we have to trust in the compiler and the reviewer's judgement. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we ever change style guidelines?
On Thursday 10 December 2009 03:16:51 pm Peter Kasting wrote: Yeah, I'm not sold. But oh well. I think I was getting too irked, when really we're just both giving our opinions on how we want the style guide to work. There's nothing wrong with having opinions, or disagreeing. Besides, I've been on enough bugs with you to know that your judgement is solid. If it comes down to trusting that judgement, that's not too bad a fate. Thanks Peter :) Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Resolution on switch statement indentation
On Wednesday 09 December 2009 10:26:24 am Chris Marrin wrote: I saw another patch get rejected today because of switch statement indentation. We discussed this last week, and I saw a lot of support for my proposal of indenting case labels from their switch. But the discussion did not end in resolution. To summarize, here are the options mentioned: 1) Case labels always have the same indentation as their switch (today's rule) ... Anyway, how do we come to resolution on this? What is wrong with keeping the current rule? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Resolution on switch statement indentation
On Wednesday 09 December 2009 01:03:23 pm Chris Marrin wrote: What is wrong with keeping the current rule? As I pointed out in the previous thread, I feel like it makes the code harder to read, and got several responses of agreement. Also most of the switch statements in the code currently indent the case labels, so it will mean lots of code changes. I think it would be better to change the rule. Ok, well FWIW I disagree that the current rule makes things hard to read and I do not like the idea of changing it. I object on the same grounds as the other recent styling change proposals as well as substantively that it makes anything easier to read. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Resolution on switch statement indentation
On Wednesday 09 December 2009 02:04:07 pm Darin Adler wrote: On Dec 9, 2009, at 10:57 AM, Adam Treat wrote: Ok, well FWIW I disagree that the current rule makes things hard to read and I do not like the idea of changing it. I object on the same grounds as the other recent styling change proposals as well as substantively that it makes anything easier to read. Sorry to keep this topic open — I try to stay out of these — but this one is slightly different than the namespace indenting or whatever else was recently discussed in that there is still a roughly 50/50 split in existing code despite the style guide listing an unambiguous rule. -- Darin Yep, that does distinguish. That being said, my personal preference would be either to keep the current rule and change the code to meet it or even better just eliminate the rule altogether since the community hasn't been following it anyways. That speaks negatively to the real world value of the rule IMHO. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we ever change style guidelines?
On Wednesday 09 December 2009 04:02:07 pm Maciej Stachowiak wrote:
I have thought over your comments about not changing the style
guidelines at a whim.
I think you make a very good point: the most important thing about the
style guidelines is that there is one way to do things, and that's
more important than having the very best way. In particular, anyone
who is looking to change the style guidelines to best reflect their
personal preferences is thinking about it the wrong way. And making
lots of changes could lead to useless code thrash. So, your argument
almost made me back off on the proposed style rule changes.
However, I don't want to get so set in our ways that we never dare to
change anything about the style guidelines. One principle that's
important to the WebKit project is willingness to change things for
the better, even if there is a short-term cost in terms of disruption.
We're willing to rename classes and functions, rename files, and break
internal interfaces if that makes the code better. In the case of the
style guidelines, how do we balance this way of thinking with the
desire to avoid thrash and changing on a whim? I think something like
the following should be our meta-guidelines for when to change the
style guide:
Good point.
1) If an issue or a particular case is not addressed in the style rule
at all, then we should be willing to add a new rule.
I disagree with this. I think the heavily favored presumption should be
against adding new rules. If we discover some supremely annoying
inconsistency then that is one thing, but it is important to note that *we do
not need* a rule for every possible different type of style. I like having a
consistently styled codebase, but I also like having the flexibility to
exercise good judgement. With every new rule to the style guide I fear we
lose the latter and become ever more pedantic about often trivial issues.
Rather, I'd prefer to think of the style guidelines as just that: guidelines.
In the end, I believe both patch authors and reviewers should use good common
sense just like in any other aspect of our codebase. If for some reason the
style guidelines are problematic in a particular corner case, then I think we
should have the flexibility to use our common sense. I think this already
occurs, but perhaps it is good to spell out?
I'd like to go back to thinking of the style guidelines as a *guide* for patch
authors into the common coding style of the community. What I suspect is
happening (which concerns me), is the style guidelines being used to work
around the problems we're encountering scaling the review queue.
If we are to continue on the road of ever more stringent adherence to the
style strikeguidelines/strikerules, then I think we should exact an ever
heavier burden on adding to or modifying those rules.
2) If we failed to fully consider the consequences of a rule when we
first wrote it down, whether in general or in some particular case,
then we should consider revising it to address the unanticipated issues.
Sure.
3) If we have overwhelmingly strong evidence that a particular change
would aid readability, even though the issue in question had been
considered before, then we can consider changing. But there should be
a heavy presumption in favor of the current rule, and if there is not
consensus on the change, we should lean towards not changing.
Fine with that.
4) If the code actually follows a different pattern than the formal
rule, and we see no strong advantage to the rule, we should consider
changing the rule to match the code.
Or perhaps we get rid of the rule?
I think in the case of case labels, we have a bit of #2 going on. I
don't think we considered the possibility of blocks inside the case
label, or at least when we were creating these rules I don't think we
were aware that there are some cases where using braces is essential,
so the solution would be to leave them out. The only reason it's every
truly needed to use braces is if you declare a variable with a type
that has a constructor or destructor, and I'm pretty sure I at least
hadn't thought of this when we made the rule.
switch (type) {
case A:
{
Foo foo;
break;
}
case B:
default:
return;
}
That's what I've been using and I think this passes the current rule.
In the case of braces around single-line clauses, I think we also
didn't fully consider the impact when you have a lengthy if chain and
a mix of single-line and multi-line statements. So I think there too,
#2 applies. However, we definitely *did* consider if statements with
no else, and two-clause if/else statements, and decided we were ok
with the consequences of the rule.
Well, people still disagree whether this is a readability improvement. And
while I am sympathetic that it is, I still consider mine to be a subjective
opinion and therefore not a good enough reason to change the rule.
Cheers,
Re: [webkit-dev] Should we ever change style guidelines?
On Wednesday 09 December 2009 07:03:51 pm Peter Kasting wrote: But even what is trivial is a judgement call. In general people don't disagree about issues where they believe disagreement is a waste of time. ... And I don't. Who is right? More importantly, how will you prevent us from starting this debate on a bug? I won't? If you as a reviewer consider the indentation of case labels to be a non-trivial issue, then exercise your good judgement in patch review and I'll trust that as a reviewer you will do a good job. It's well-established that (a) not enforcing past rules as well as we're doing now and (b) changing rules without changing the whole codebase to comply contribute to this. Existing inconsistency is not evidence that inconsistency is fine, or even desirable. I'm not arguing against consistency. I'm arguing that there should be a heavy burden before we adopt more or modify the existing style guidelines. And that reviewers should have the freedom to interpret the guidelines as guides that almost always are correct and should be followed absent a good reason and not rules that should be enforced pedantically so sayeth $DIETY. Wasting a few dozen comments arguing the same issue with the same people in several different bugs is correctly termed a fiasco in my opinion. By contrast the numerous bugs I've seen where authors promptly corrected style violations in their patches and reposted them have gone quite smoothly. Lack of flexibility and/or enforcing the guidelines pedantically can also be a problem though. And we are continually moving more in the direction of automating and streamlining these actions so that patch authors get feedback as quickly and consistently as possible and reviewers don't have to bother thinking about things like this. That seems like a good direction to me. I like the style checker. That is why I helped write parts of it. However, I still want reviewers to have the flexiblity to think and make judgement calls about style issues. Something that I think was practiced in the past and should be continued. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
On Thursday 03 December 2009 02:30:17 pm Kenneth Russell wrote: In the WebKit WebGL implementation I've frequently encountered the case where the else clause in a single if/else is a one-liner, and I find it both ugly and error-prone to have to remove its braces. I'd really like to be able to use braces on both arms. Perhaps existing code could be grandfathered in but new or modified code required to conform to the rule Peter proposes. -Ken I'd like to lodge an objection on the grounds that the style guide is a matter of subjective opinion and rationally only serves to make our code consistent. I do not like changing this style guide as the fashion changes. However, as Hyatt might note I do not have a personally substantive problem with this particular change as I'd actually prefer this if the style guide were being made up today. It seems we keep changing the style guide as fashion changes. It is meant to ensure consistency and readability. This is a purely subjective change and I think unwarranted. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TARGET_OS_EMBEDDED
I think this would suffer from lack of clarity. Not all embedded systems are alike and not all will wish to be treated in the same way. On Friday 04 December 2009 08:51:12 am Zoltan Herczeg wrote: Hi, it would be a great to have a macro in WebKit, which would be enabled on embedded systems. We could replace macros like PLATFORM(SYMBIAN) in TextCodecQt.cpp to this new macro. However, TARGET_OS_EMBEDDED macro enables WTF_PLATFORM_IPHONE. Well, not only symbian and iPhone exist in embedded domain. What is your suggestion? Zoltan ___ 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] Proposing style guide change regarding braces on conditional arms
On Friday 04 December 2009 12:17:03 pm Jeremy Orlow wrote: I'm not necessarily disagreeing with your conclusion, but I have to ask: can you think of an example of a style change that isn't subjective and/or something that can change as the fashion (or, more likely, the developers working on the project) changes? Even stuff like the namespace change really depends on your development style (to determine whether or not you care about those 4 extra spaces wasted). Very little of it is not subjective. The main thing the style guide gives us is consistency. And that I am fully supportive of. But a lot of it is merely taste. The compiler excepts both. Two developers fully informed and both of great technical prowess can reasonably disagree on almost all points of the style guide. That meets my definition of subjective for this purpose. Regarding the namespace change, I objected to that change too (and for the very same reasons) if you look through the archives. I don't think we should be changing the style guide for anything besides clarifications of currently unwritten rules. No matter how the fashion may change or how developers may change. Changing the rules throws consistency out the window which is, I believe, the greatest benefit of having a style guide. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
On Friday 04 December 2009 04:22:57 pm Dirk Pranke wrote: On Fri, Dec 4, 2009 at 9:39 AM, Adam Treat tr...@kde.org wrote: I don't think we should be changing the style guide for anything besides clarifications of currently unwritten rules. No matter how the fashion may change or how developers may change. Changing the rules throws consistency out the window which is, I believe, the greatest benefit of having a style guide. While I agree with your points re: subjectivity, and I agree that any two competent programmers can disagree on any points, it is also true that some practices can be shown to be more reliable, maintainable, or readable, and those practices do change over time, partially as technology changes and partially because this is a social process. You can't show that any practice is more readable than another because it is subjective as you admit. People can argue over the readability of different style options and come to different conclusions much as has been done in this long thread. As for technology changing, what do you think drives this particular style change other than the subjective opinions of a set of developers? Dunno if this changes any of your thinking or not ... Sorry, not really. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] virtual functions in ChromeClient and other clients
If i remember correctly another strike against this is SVG. I believe that
SVG uses a different set of empty clients. This would make that more difficult?
On Thursday 22 October 2009 03:29:28 pm Yong Li wrote:
Oops, even m_page is a data member.
Hm... I need to think more about it.
-Yong
- Original Message -
From: Yong Li yong...@torchmobile.com
To: Adam Barth aba...@webkit.org
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:28 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
Usually, those clients call WebPage or WebFrame to access the data
members.
For example:
ChromeClient::doSomething()
{
m_page-doSomething();
}
-Yong
- Original Message -
From: Adam Barth aba...@webkit.org
To: Yong Li yong...@torchmobile.com
Cc: WebKit Development webkit-dev@lists.webkit.org
Sent: Thursday, October 22, 2009 3:25 PM
Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
clients
How would the class implementing ChromeClient hold any data members?
I guess we could use pimpl...
Adam
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
Hi All,
ChromeClient and other clients defined in webkit are using a lot of
WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
always implemented in a static lib that's linked with WebCore together.
If that's true, why do we need those virtual functions? One reason
might
be for this case:
class WebPage: public ChromeClient, public EditorClient, public . {
};
But I see most ports implement these clients with single classes. If we
can
make this mandatory, then we can remove these virtual words from these
client interface, and then the compilers could make those functions
inline
whenever suitable. I guess this could boost performance a little bit.
Best regards,
Yong Li
___
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] Calling All Reviewers
On Friday 07 August 2009 05:51:57 pm Eric Seidel wrote: We also definitely need to fix our tools to make it impossible to post a patch w/o a ChangeLog, and impossible to post a patch that doesn't pass check-webkit-style. This is a bad idea. check-webkit-style still has false positives and is very new. It has been designed to never be free of false positives in fact. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] freeing static variables
On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote: Hi, any thoughts on this? I hope my qestion was clear :) I would like to pack the static declarations into wrapper classes, so we can add platform and/or compilation mode (debug/release) dependent functionality to all static variables (i.e: freeing them on exit). Zoltan I've tried this before and it didn't work out so well. The order in which you free them becomes very important and error prone. And, of course, whatever solution you make has to be optional and easy to maintain as the default policy in WebKit is to not care - by design - about cleaning up after static globals on exit as that is left to the OS. Another strategy for the embedded case where you want to free everything on exit is to create a custom memory handler that will do this for you. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript code that access the DOM tree
On Thursday 30 July 2009 08:57:53 am Luka Napotnik wrote: Hello. I'm searching for the JavaScriptCore code that can access the DOM tree. An example would be JavaScript code that changes the image source of an IMG dom element. Any good pointer on this subject? Greets, Luka This is not an appropriate topic for this mailing list as webkit-dev is for discussion related to the development of the WebKit rendering engine. It is not for answering generic JavaScript questions. Thanks! Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit Build Error on Windows (Urgent)
This thread is not appropriate for webkit-dev. There is a new mailing list -
webkit-help - which has been setup for threads of this nature. Please use the
other mailing list and keep webkit-dev focused on webkit development.
http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
Cheers,
Adam
On Wednesday 22 July 2009 07:45:52 am mjbh wrote:
Hi
Thanx Niilesh. Cannot find file: \usr\bin\WebKit\WebKit.pro Error
occurred due to qmake not able
understand the cygwin style path. I have modified webkitdir.pm to generate
windows style path.
then I got the below message.
bash-3.2$ WebKitTools/Scripts/build-webkit --cairo-win32 --debug
unix DIR: '/usr/bin/WebKit'
WIN DIR: 'D:\cygwin\bin\WebKit'
Qmakebin Value: 'qmake'
buildArgs Value: '-r
OUTPUT_DIR=D:\cygwin\bin\WebKit\WebKitBuild/Debug_Cairo D:\
cygwin\bin\WebKit\WebKit.pro CONFIG-=release CONFIG+=debug'
Calling 'qmake -r OUTPUT_DIR=D:\cygwin\bin\WebKit\WebKitBuild/Debug_Cairo
D:\cyg
win\bin\WebKit\WebKit.pro CONFIG-=release CONFIG+=debug' in
D:\cygwin\bin\WebKit
\WebKitBuild/Debug_Cairo
Reading D:/cygwin/bin/WebKit/WebCore/WebCore.pro
[D:/cygwin/bin/WebKit/WebKitBui
ld/Debug_Cairo//WebCore]
c:\Qt\4.4.3\bin\rcc.exe: File does not exist
'..\..\..\WebCore\inspector\front-e
nd\WebKit.qrc'
c:\Qt\4.4.3\bin\rcc.exe: File does not exist '..\..\..\WebCore\WebCore.qrc'
c:\Qt\4.4.3\bin\rcc.exe: File does not exist
'..\..\..\WebCore\inspector\front-e
nd\WebKit.qrc'
c:\Qt\4.4.3\bin\rcc.exe: File does not exist '..\..\..\WebCore\WebCore.qrc'
Reading D:/cygwin/bin/WebKit/JavaScriptCore/jsc.pro
[D:/cygwin/bin/WebKit/WebKit
Build/Debug_Cairo//JavaScriptCore]
Reading D:/cygwin/bin/WebKit/WebKit/qt/QtLauncher/QtLauncher.pro
[D:/cygwin/bin/
WebKit/WebKitBuild/Debug_Cairo//WebKit/qt/QtLauncher]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/tests.pro
[D:/cygwin/bin/WebKit/Web
KitBuild/Debug_Cairo//WebKit/qt/tests]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebframe/qwebframe.pro
[D:/cygwin
/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebframe]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebpage/qwebpage.pro
[D:/cygwin/b
in/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebpage]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebelement/qwebelement.pro
[D:/cy
gwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebelement]
Reading
D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebhistoryinterface/qwebhistoryin
terface.pro
[D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebh
istoryinterface]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebview/qwebview.pro
[D:/cygwin/b
in/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebview]
Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebhistory/qwebhistory.pro
[D:/cy
gwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebhistory]
Reading
D:/cygwin/bin/WebKit/WebKit/qt/tests/benchmarks/painting/tst_painting.p
ro
[D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//benchmarks/p
ai nting]
Reading
D:/cygwin/bin/WebKit/WebKit/qt/tests/benchmarks/loading/tst_loading.pro
[D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//benchmarks/l
oadi ng]
===
WebKit is now built. To run QtLauncher with this newly-built
code, use the WebKitTools/Scripts/run-launcher script.
NOTE: WebKit has been built with SVG support enabled.
QtLauncher will have SVG viewing capabilities.
Your build supports the following (optional) SVG features:
* Basic SVG animation.
* SVG as image.
* SVG fonts.
* SVG foreign object.
* SVG use support.
===
but I when invoke the run-launcher, I am getting the below error:
bash-3.2$ WebKitTools/Scripts/run-launcher
Starting webkit launcher, running against the built WebKit in
D:/cygwin/bin/WebK
it/WebKitBuild/Release/lib...
Can't exec D:/cygwin/bin/WebKit/WebKitBuild/Release/bin/QtLauncher: No
such fi
le or directory at WebKitTools/Scripts/run-launcher line 68.
Died at WebKitTools/Scripts/run-launcher line 68.
bash-3.2$
If I tried to build through the Qt command prompt using nmake, I am getting
the below Error:
( I am using Qt 4.4.3 )
D:\cygwin\bin\WebKit\WebKitBuild\Debug_Cairo\WebCorenmake -f
Makefile.Debug
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
perl D:/cygwin/bin/WebKit/JavaScriptCore/pcre/dftables
generated\debug\c
hartables.c --preprocessor=cl /E
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9002 : ignoring unknown option
'/tmp/dftables-FjM3m7_
1.in'
cl : Command line error D8003 : missing source filename
Use of uninitialized value $pcre_internal{tables_length} in printf at
D:/cygwi
n/bin/WebKit/JavaScriptCore/pcre/dftables
Re: [webkit-dev] QWebElement not found in Qt 4.5.2
This thread is not appropriate for webkit-dev. There is a new mailing list - webkit-help - which has been setup for threads of this nature. Please use the other mailing list and keep webkit-dev focused on webkit development. http://lists.webkit.org/mailman/listinfo.cgi/webkit-help Cheers, Adam On Wednesday 22 July 2009 03:20:14 am Ashok N N wrote: Hi, I am compiling QtWebKit for the first time with Qt 4.5.2. At the very end of compilation, I see linking errors for QWebElement (among others). And searching around I did not find the header file qwebelement.h included in Qt4.5.2. And searching online I found that QWebElement is released in Qt 4.6 (http://chaos.troll.no/~tavestbo/webkit/domapi/qwebelement.html). I was wondering how the current code is compilable in this situation? Is there a flag that can be set to disable this part of the code? The actual changes to WebKit were done in rev 42238. thanks, ashok ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Compiling WebKit (any flavor) for ARM
This thread is not appropriate for webkit-dev. There is a new mailing list - webkit-help - which has been setup for threads of this nature. Please use the other mailing list and keep webkit-dev focused on webkit development. http://lists.webkit.org/mailman/listinfo.cgi/webkit-help Cheers, Adam On Wednesday 22 July 2009 06:55:24 am Ashok N N wrote: Hi, I've gone through some of the posts related to compiling WebKit for ARM but found them to be conflicting. One of them says that just setting the QMAKESPEC should work fine while others mentioned compiling the tool chain for cross compilation etc. Can somebody help me with any instructions for compiling WebKit for ARM? Also is there a guide to the build system being used? I see that build-webkit tries to identify the architecture etc and invoke specific build functions like buildQMakeQtProject() etc. thanks, ashok ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] loading webpage on webkit_gtk has error of font
If you believe you've found a bug the correct thing to do is to post a bug on bugs.webkit.org. See here: http://webkit.org/quality/reporting.html Otherwise, generic queries of this form should probably be asked on the webkit-help mailing list: http://lists.webkit.org/mailman/listinfo.cgi/webkit-help Thanks, Adam On Wednesday 22 July 2009 12:40:47 am deuxliquid wrote: Hi all, I built webkit on gtk. Then run Gtklauncher but the font of webpage is so blur. Any one gives me some advices? Thank you in advance! Vui vẻ chat thêm trên nhiều blog và website. Hãy thử dùng ứng dụng Pingbox online. http://vn.messenger.yahoo.com/pingbox/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TeaShark
This thread is not appropriate for webkit-dev and indeed, not appropriate for any webkit list in general. TeaShark is only tangentially related to WebKit and the WebKit developers have no special knowledge of this third party product. For queries about TeaShark or any client application that happens to use WebKit: you should ask the client authors directly. Cheers, Adam On Tuesday 21 July 2009 11:09:46 pm Hieu Le Trung wrote: Hi, According to the following archive http://lists.macosforge.org/pipermail/webkit-dev/2007-September/002427.h tml I wonder if there is source code release of TeaShark or not. Thanks, -Hieu ___ 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
[webkit-dev] Review Queue needs some more attention
We have close to 100 patches that need attention in the review queue. http://www.webkit.org/pending-review I count five or six for the Qt port. Eight for the GTK port. Several for the Haiku port where a decision should probably be made. And several for the ARM Jit work and the custom memory allocator. I'm going to try and go through what I can, but if any other reviewers have some time... Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Review queue needs love
On Friday 19 June 2009 02:05:23 pm Drew Wilson wrote: I was more specifically wondering if there was something about this patch that made it not show up on the list Eric provided below. My concern is because the bugfix came from a google.com address, it might have been getting lumped in with the oh, must be Yet Another Chromium Patch so I won't worry about it list, which if true has troubling implications given that there are an increasing number of Googlers that are making contributions to WebKit that have nothing to do with Chromium. Your concern seems rather odd given that Eric is a Google employee. Moreover, the link that started this thread was given by Maciej and your bug is indeed found in that list: https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review queue needs love
On Thursday 18 June 2009 05:39:04 pm Oliver Hunt wrote: I reviewed quite a few last night as well. At the moment there appear to be a large number of chromium, gtk, and qt specific patches up for review -- it would be great if reviewers for those ports went through them all :D I went through all the Qt ones today after Maciej made his request. I think there is only one outstanding Qt related one at the moment... Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MIPS port problem - cti_op_put_by_id slow case problem
On Wednesday 17 June 2009 05:12:41 pm Jeremy Orlow wrote: If so, why not just develop in the open? I'm just guessing here... but probably for the same rough combination of reasons that Google didn't develop Chromium in the open before it was publicly announced... or for the same rough combination of reasons that Apple didn't develop the new ARM JIT support in the open before it was publicly announced. Same goes for lots of initial features or ports that the various companies involved in WebKit have eventually contributed. It would be nice if every change that is envisioned will eventually be merged back into the official repository to be developed in the open, but that is just not realistic given the commercial world we live in. That said, if a company is determined to initially develop such things behind a closed door, then they should have no expectation that the greater community will help with any obfuscated technical questions given that we aren't privy to what's going on behind that closed door. At least that's how I see it. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Bulk] Re: MIPS port problem - cti_op_put_by_id slow case problem
On Wednesday 17 June 2009 06:24:32 pm Adam Treat wrote: It would be nice if every change that is envisioned will eventually be merged back into the official repository to be developed in the open, but that is just not realistic given the commercial world we live in. I would also add that in my personal opinion and experience the business reasons often cited for hiding behind a closed door during the initial development of a new feature are dubious at best and real hindrances (even crippling hindrances) at worst. Too often I think companies involved with Open Source choose to develop some new feature behind a closed door almost as an a priori default position. In my experience this often leads to a lot of headaches when interacting with the community much as we are starting to see here. Moveover, the actual business value of such initial closed development is often just assumed. I think it would behoove companies that are involved with WebKit to rethink these initial assumptions and actually make sure that whatever PR value they get from announcing there brand new swanky feature that has been developed behind a closed door, is actually greater than the negative repercussions that come from doing so. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines
On Tuesday 16 June 2009 02:34:14 pm Luke Kenneth Casson Leighton wrote: ... a browser engine where the javascript namespace / DOM namespace that can be extended? Sure. how the heck does anyone do that with webkit? correction: how does anyone get some object into the global namespace that will sit side-by-side next to document. and window. and all other global objects? http://doc.qtsoftware.com/4.5/qwebframe.html#addToJavaScriptWindowObject Now, as Mark and Oliver have already patiently said, Opera Unite is a feature of the browser itself and as such it is a feature orthogonal to WebKit proper. Of course, you are free to create your own browser using WebKit that features an Opera Unite-alike, but this mailing list is not the place to chat about it. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Harmonizing content sniffing
Has there been any progress with this effort? Specifically, I'm wondering if there is a bug on bugs.webkit.org that we are using to track this task. Cheers, Adam On Friday 14 November 2008 5:53:56 pm Adam Barth wrote: Ok. I'll file a bug report at http://bugreport.apple.com/ with several things that should be easy to change. In parallel, we can investigate moving the sniffing algorithm to WebKit. Thanks, Adam On Fri, Nov 14, 2008 at 2:40 PM, Darin Adler da...@apple.com wrote: On Nov 14, 2008, at 2:32 PM, Adam Barth wrote: One disadvantage of moving the algorithm is that we might make some unintended changes. Another disadvantage is that any other Mac OS X libraries or applications that rely on the sniffing done by CFNetwork will no longer get the same results as WebKit clients. Also, I don't think we've established yet if we can turn off the sniffing in CFNetwork and keep the other desirable CFNetwork features working. There are a number of closely related features, such as the one that determines the suggested filename for a download. I think the concept of moving the sniffing into WebKit is great if we can execute it successfully. I'm worried that it may be difficult to do that in the Mac OS X version and the Windows version used by Safari. -- Darin ___ 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] Questions about expected test results
On Wednesday 25 February 2009 1:41:50 pm Sami Kukkonen wrote: Being new to WebKit this is confusing so I have a couple of questions: 1.Why doesn't trunk-qt-linux-release run layout tests? Is it known and expected that hundreds of them will fail? The buildbot for the QtWebKit port does not currently execute layout tests. This is a known issue and is being worked on. Torch Mobile plans on hosting a new buildbot for the QtWebKit port that will have the layout tests turned on. It is known that lots of tests do not currently pass. That is a result of some bitrot in the implementation of DRT for the Qt port, but it is being worked on. Lots of the failures are a result of problems with DRT rather than the Qt port itself. 2.Why does trunk-qt-linux-release report jscore-test as passed when results file contains 50 failures? Again, the current Qt buildbot has issues, but a plan is in place to fix this. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Questions about expected test results
On Wednesday 25 February 2009 3:12:14 pm Sami Kukkonen wrote: OK, thanks. I'll ignore the failures for now and I can also use GTK as my reference build since it seems to pass almost all of the layout tests. Actually the Qt port passes more tests right now (not by much) than the GTK port. Both are skipping an enormous amount of tests via the Skipped files. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning off rendering in WebKit
On Wednesday 14 January 2009 5:07:56 am goldeneyes wrote: Bugzilla from tr...@kde.org wrote: Sorry, the method had moved. Here you go: void FrameView::paintContents(GraphicsContext* p, const IntRect rect) from http://trac.webkit.org/browser/trunk/WebCore/page/FrameView.cpp?rev=39858 Cheers, Adam hi, Thank you for the answer, I have made the changes in this file WebKit / WebCore / page / FrameView.cpp but it stil displays the main window whith no Content( white page ). But how can i do to hide the whole browser ? Thank you in advance for any help, That's not what you asked for before. You just didn't want WebKit to render any of the contents unless I read something wrong. If you want to disable all painting altogether then that will depend on the port of WebKit you are using: Qt, Mac, Windows, etc. For the Qt port you could just use QWebPage with no QWebView and nothing would be drawn to screen. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning off rendering in WebKit
On Monday 12 January 2009 12:25:05 pm Shariq Rizvi wrote: I am using WebKit to piggy-back on the non-rendering phases of WebKit's loading of a page (parsing, DOM creation, onload-time Javascript execution), for doing some dynamic analysis of the in-memory objects that result after these phases. Hence, I want to disable the actual rendering of visible objects (I don't need to see any window). So far, I have been using Xvfb (X Virtual Frame Buffer) to have my application send its window into this fake X server. Is there an even better approach - perhaps a macro/flag that I can turn off so that WebKit does not graphically render anything? Thanks! Not sure what port you are using, but perhaps put in a 'return;' at the beginning of Frame::paint(...) ? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] support for Qt 4.3
Hi Ariya, I will simply note that several current customers of Qt Software have yet to migrate to Qt Extended 4.4 and are still developing plans for doing so. This move will preclude them from benefiting from crucial improvements to the browser engine without a correspondingly large move to a new version of Qt Extended/Qtopia. Technologies like Squirrelfish and the improvements made to the Javascript engine are proportionally very important for such customers. Cheers, Adam On Monday 17 November 2008 9:37:20 am Ariya Hidayat wrote: As Qt 4.5 is approaching the release, we would like to express that officially we would support only building QtWebKit trunk with either Qt 4.4 or Qt 4.5. This means, nobody from Qt Software will check whether the current state of the code even compiles with Qt 4.3. If nobody else is using/building/testing QtWebKit trunk with Qt 4.3, we propose to remove the support code for that. Otherwise, we can leave it as it is but then it would be better if there is a build bot for that. Note that this applies only to trunk, not to any branches. Thank you! Best regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Update on memory allocation control proposal...
On Wednesday 18 June 2008, Paul Pedriana wrote: I've created a working wtf/New.h file and a basic unit test for it. It implements both of Maciej's recent proposals, which were essentially 1: provide an allocation base class and 2: provide a global allocator. I definitely prefer number #1. Although it does require an extra base class for and thus a big code change, it is still *much* less intrusive compared to #2. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] construct the dom tree of non Xml valid page
Hi Nina,
If I understand correctly, you are loading a page in QtWebKit and then using
the QWebFrame::toHtml() method to retrieve the actual markup which is missing
closing tags.
If the html is missing *all* closing tags then this sounds like a bug in the
toHtml method. If the html is missing only *some* closing tags then this is
not remarkable as of course the html does not need to be well formed for
webkit to display it.
This is hard to know since we have no details about what page you are
trying to load and or any other details that normally go into a bug report.
If you believe you've discovered a bug then by all means fill out a bug on
bugs.webkit.org. This website is not the right place for these kinds of bug
reports.
Adam
On Sunday 08 June 2008, nina wrote:
Thanks David for response,
I want to load an html page with webkit then contruct his dom tree, I
use Qt4.4 which integrate Webkit.
QWebView v;
QString frameText = v . page() - mainFrame() - toHtml(); Loading the
page
void Charger::Dom-tree(QDomNode node) Function which construct dom
tree for html page loaded
{
if (node.hasChildNodes ())
{
listnode = node.childNodes();
for(i=0; ilistnode.length() ; i++) {
e = node.toElement();
Dom-tree(listnode.item(i)); }
}
}
This failed, because there is some missing closings tags !!!
___
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] Async IconDatabase and reading icons from disk on startup
Hi, I do not understand how a client application should use IconDatabase to display icons given its async nature. It would seem that a client application should call iconDatabase()-iconForPageURL() when it needs to display a particular icon on startup. However, the way IconDatabase is written it appears that the client application would need to call this method *twice* before being able to retrieve the actual icon from disk. The only time image data is actually read from disk is in IconDatabase::readFromDatabase() and the only icons it reads are marked by the set of icons in m_iconsPendingReading. However, the only time IconRecord's are actually *added* to m_iconsPendingReading is in IconDatabase::iconForPageURL()...?? So, it appears a client application has to call IconDatabase::iconForPageURL twice before being able to actually retrieve the icon image data. Once for scheduling it to be read from disk and a second time to actually retrieve it??!! What am I missing? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Async IconDatabase and reading icons from disk on startup
On Sunday 11 May 2008, Darin Adler wrote: On May 11, 2008, at 5:08 PM, Adam Treat wrote: It would seem that a client application should call iconDatabase()- iconForPageURL() when it needs to display a particular icon on startup. However, the way IconDatabase is written it appears that the client application would need to call this method *twice* before being able to retrieve the actual icon from disk. The client should call retainIconForPageURL as soon as it discovers it will need the icon for a particular URL. Later, dispatchDidAddIconForPageURL will be called on the client when that icon is available. How is it actually read from disk then? Looking at the code... the only time it is actually read from disk is in IconDatabase::readFromDatabase and even then it only reads in icons that are flagged in m_iconsPendingReading. And when grepping the code the only time I see that an icon is inserted into m_iconsPendingReading is when iconForPageUrl is called?? At that point, the client can call iconForPageURL to get the icon. If the icon is no longer needed, the client should call releaseIconForPageURL. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Async IconDatabase and reading icons from disk on startup
On Sunday 11 May 2008, Darin Adler wrote: Or you could do as Safari does and call iconForPageURL twice; the first time it's display the icon if we already have it but the second time it's I heard you have a new icon, lets display the new icon we now know about. It would probably be cleaner if triggering the load of the icon was completely separate from actually fetching the icon data. Right. I would suggest that iconForPageURL should always return 0 unless and until readIconForPageURLFromDisk is called which actually triggers the load. It should be noted that *nothing* currently uses readIconForPageURLFromDisk() ;) I guess I just couldn't believe that Safari calls iconForPageURL twice. It is very unclear API. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] QWebNetworkManager triggering a memleak in Qt
Hi, I've checked and this appears to be the case in both Qt 4.3.2 and Qt 4.4 snapshot... ==7746== 4 bytes in 1 blocks are definitely lost in loss record 5 of 507 ==7746==at 0x4022765: malloc (vg_replace_malloc.c:149) ==7746==by 0x5CB16C4: qMalloc(unsigned) (qglobal.cpp:1964) ==7746==by 0x5D7E43C: queuedConnectionTypes(QListQByteArray const) (qobject.cpp:67) ==7746==by 0x5D82E5A: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2567) ==7746==by 0x80513D2: QObject::connect(QObject const*, char const*, char const*, Qt::ConnectionType) const (qobject.h:291) ==7746==by 0x4B38C6C: QWebNetworkManager::QWebNetworkManager() (qwebnetworkinterface.cpp:432) ==7746==by 0x4B38D5F: QWebNetworkInterface::QWebNetworkInterface(QObject*) (qwebnetworkinterface.cpp:906) ==7746==by 0x4B38DE6: QWebNetworkInterface::defaultInterface() (qwebnetworkinterface.cpp:890) ==7746==by 0x4B38E36: QWebNetworkManager::self() (qwebnetworkinterface.cpp:438) ==7746==by 0x4AFAFD7: WebCore::ResourceHandle::start(WebCore::Frame*) (ResourceHandleQt.cpp:134) ==7746==by 0x49E9280: WebCore::ResourceHandle::create(WebCore::ResourceRequest const, WebCore::ResourceHandleClient*, WebCore::Frame*, bool, bool, bool) (ResourceHandle.cpp:53) ==7746==by 0x4970831: WebCore::MainResourceLoader::loadNow(WebCore::ResourceRequest) (MainResourceLoader.cpp:377) QObject is allocating memory for this queued connection that is apparently never freed. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Webkit-QT and DOM
On Saturday 15 September 2007, william lee wrote: And also the API or signal to handle before navigate to somewhere. This is really useful, to check something before navigate. I can't find it. It is in QWebPage: virtual NavigationRequestResponse navigationRequested( QWebFrame *frame, const QWebNetworkRequest request, NavigationType type); Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Webkit-QT and DOM
On Friday 14 September 2007, [EMAIL PROTECTED] wrote: Hello, I am using Webkit-QT under Windows, and I need to access to the DOM tree. Anyone has an idea on how to do that? Is there some plan to add it to the Webkit-QT interface? Funny. We have been discussing such an API recently, but it is not done yet. For now we have no API for accessing the DOM, but that is likely to change soon. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit and Konqueror
On Friday 14 September 2007, Andre-John Mas wrote: Hi, Does anyone know whether WebKitQT has advanced far enough for us to start seeing an alpha build of Konqueror using WebKit? Sure. Just install the WebKitPart in playground and you'll see Konqueror render with QtWebKit. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit and Konqueror
On Friday 14 September 2007, Mike Hommey wrote: On Fri, Sep 14, 2007 at 11:21:39AM -0400, Adam Treat [EMAIL PROTECTED] wrote: On Friday 14 September 2007, Andre-John Mas wrote: Hi, Does anyone know whether WebKitQT has advanced far enough for us to start seeing an alpha build of Konqueror using WebKit? Sure. Just install the WebKitPart in playground and you'll see Konqueror render with QtWebKit. BTW, is the WebKitPart living under WebKitQt in webkit svn up to date and buildable ? No, I believe the one living in KDE's playground is the correct one. I imagine the one living in webkit svn is scheduled for removal... Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKitQt build issue: pthread.h
On Thursday 13 September 2007, KC Jones wrote: The Windows Qt build is busted for me. Is this known, or have I muffed something? The compilation failure concerns pthread.h while compiling .\WebCore\dom\Document.cpp: [...]\WebKit\WebCore\platform\Threading.h(33) : fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory The file Threading.h was introduced in revision 25416 on Sep 7. I have heard no mention of this problem on this list. Is this a known bug? The windows version of QtWebKit is very new and hasn't received a lot of attention. I haven't event built it yet as I don't have a working windows machine. BTW, Simon/Lars, what is the plan for the buildbots now that Zack has left? Are you guys planning on providing a windows buildbot? Perhaps we can host host some buildbots at SCS... I tried reverting to revision 25415 (after parsing through the update-webkit script to do it by hand). The release target built successfully but was utterly unstable. The debug target, surprisingly, didn't build at all -- didn't even get to the compilation stage. Which makes me wonder... Is there a roadmap for the WebKitQt project that I have not seen on webkit.org? Are there branches or labeled versions that Here is the roadmap: http://trac.webkit.org/projects/webkit/wiki/QtWebKitTodo identify more stable source bases for various builds? Is this an No, there are no more stable branches. I have no idea whether the windows version of QtWebKit is 'utterly unstable', but I wouldn't describe the linux version that way at this point. appropriate forum for asking questions about the roadmap? I'm trying to Yes, this is the correct forum for these types of questions. And of course when it actually builds please report any bugs to the bugzilla or even better patches :) Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re: [webkit-changes] [25269] trunk/LayoutTests
On Tuesday 28 August 2007, Adam Roben wrote: On Aug 27, 2007, at 11:35 PM, [EMAIL PROTECTED] wrote: Modified: trunk/LayoutTests/ChangeLog (25268 = 25269) --- trunk/LayoutTests/ChangeLog 2007-08-28 05:59:26 UTC (rev 25268) +++ trunk/LayoutTests/ChangeLog 2007-08-28 06:35:23 UTC (rev 25269) @@ -1,5 +1,16 @@ 2007-08-27 Oliver Hunt [EMAIL PROTECTED] +Reviewed by NOBODY (layout test result fix). + +Output of layoutTestController.dumpChildFramesAsText changes in non-relevant way +when running this test on its own vs. running as part of the full suite. + +Correcting test result for the output produced while running the full suite. Yikes! I wonder why this happens? I hate that we have all these tests that have differing results depending on which other tests have been run. -Adam Interestingly enough, this patch fixes exactly this issue for the Qt port: http://bugs.webkit.org/show_bug.cgi?id=14842 However, I based the fix off of what the Windows DRT does for testing. Must be multiple bugs where this is happening... Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Fw: Re: Re: [webkit-dev] Why QtLauncher doesn't load pages from internet ?
On Monday 09 July 2007, vic burka wrote: -Original Message- From: vic burka [EMAIL PROTECTED] To: Adam Treat [EMAIL PROTECTED] Date: Mon, 09 Jul 2007 18:31:47 +0400 Subject: Re: Re: [webkit-dev] Why QtLauncher doesn't load pages from internet ? I'm using gperf 3.0.3 - I built it from source. GNU gperf 3.0.2 here. Make sure that qmake can find it! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Error when building QT port on Linux
You need to update your version of Qt. Qt 4.3.x is the minimum version required. Adam On Wednesday 27 June 2007, Oleg Sukhodolsky wrote: Hi, I'm using Ubuntu 7.04. Got up-to-date sources from svn. Did everything mentioned at http://trac.webkit.org/projects/webkit/wiki/BuildingQtOnLinux and got the following error :( ../../../WebKitQt/Api/qwebnetworkinterface_p.h:134: error: ‘QSslError’ was not declared in this scope ../../../WebKitQt/Api/qwebnetworkinterface_p.h:134: error: template argument 1 is invalid ../../../WebKitQt/Api/qwebnetworkinterface_p.h:135: error: ‘QAuthenticator’ has not been declared ../../../WebKitQt/Api/qwebnetworkinterface_p.h:136: error: expected ‘,’ or ‘...’ before ‘’ token ../../../WebKitQt/Api/qwebnetworkinterface_p.h:136: error: ISO C++ forbids declaration of ‘QNetworkProxy’ with no type make[1]: *** [tmp/ResourceHandleQt.o] Error 1 Is this a bug in sources or I have missed something? Thanks, Oleg. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Problems with QtLauncher
On Monday 21 May 2007, Michael Eichhorn wrote: Hello all, i am a newbie with WebKit, but i tried to compiling/running the code etc. i am interested in the Qt Launcher and i want to start it, and it starts the window but without any content, and i get an error message: QPainter::setCompositionMode: Composition modes not supported on device i also tried the demo composition of qt and it seemed to run. You need a newer Qt install. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: reorganization of WebKitTools/Scripts
Hi, Currently the build, run and debug scripts in WebKitTools/Scripts are a mashup of scripts for the various ports. Most of the scripts are written in perl, but a few are bash scripts. Some of them use common functions, but not all and not all in the same way. I'd like to propose a reorganization so that all the ports can share common defines and functions as well as a common build directory root. Specifically: 1. Add a dir for each port so we'd have Scripts/mac, Scripts/qt, Scripts/gdk for port specific scripts where the common defines and functions would live in the Scripts directory proper. 2. Specify command line options for all scripts which would invoke the proper port specific script. That or we set a standard ENV variable that the scripts can use to invoke the port specific scripts. ie: build-webkit (--mac|--qt|--gdk) OR make build-webkit script to read $(WEBKIT_PORT) env var... 3. Make bakefiles ports respect WebKitBuild dir... and so on... Comments? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] how to build Webkit with qt-4.2.3 on Windows
On Monday 16 April 2007, Sebastien Le Faou wrote: Hi everybody, I want to build Webkit with Qt on Windows. Building WebKit with Qt on Windows is not supported at this moment. The WebKit Qt developers have been talking about a plan to support this in the future, but it remains a task for another day. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] how to build Webkit with qt-4.2.3 on Windows
On Monday 16 April 2007, Sebastien Le Faou wrote: Hi Adam, Thank you but, I already know all of this I talked on IRC with some guys who told me that. They told me if I want to make it work on windows I have to look at the .pro files. But I don't even build something with qmake. In fact I did, but the makefiles which were created had were good (some problems with paths). So, I want to work on it, make it work, but I if I can't even run qmake it's not possible to see where there are stuffs to change in the .pro files. The major problem with the .pro files right now is that they rely upon custom compilers for generation of numerous files. These custom compilers were not written in a cross-platform way. I suspect that the incorrect directory separators you are encountering are hardcoded into the various custom compilers found in WebCore.pro and elsewhere. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
