Re: [webkit-dev] Announcing the New England Browser Authors Meetup
Hey, I'd love to attend but I'm going to be away on vacation at that time. Maybe next time. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Gavin Peters (蓋文彼紱斯) [gav...@webkit.org] Sent: Friday, May 18, 2012 3:46 AM To: WebKit Development Subject: Re: [webkit-dev] Announcing the New England Browser Authors Meetup Here is the CORRECT attendee list and agenda: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Apologies for getting it wrong in the announcement! On Fri, May 18, 2012 at 4:38 PM, Gavin Peters (蓋文彼紱斯) mailto:gav...@webkit.org>> wrote: Hi! Are you a webkit contributor or other browser author in New England? If so, read on, and consider coming to a half day unconference later this month on the web platform, to informally share your work, talk about the web platform, and meet other people working in browsers in the area! On 5/29, for a half day (starting just after lunch), authors of web browsers are encouraged to come to (LOCATION TBA, NEAR MIT, CAMBRIDGE) for an unconference of browser authors. We already have confirmed attendance from webkit contributors, mozilla committers, and chromium contributors who live and work in the New England area. If you do related work, consider coming; we'd like to hear what you are doing that's interesting. Don't prepare too long slide decks, but do prepare opinions about what browsers are getting right and getting wrong these days. Here's the attendee list, add yourself at the bottom: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 Here's the session list, please sign up to give one, or ask for one here: https://docs.google.com/spreadsheet/ccc?key=0AuCFZb6cRiGjdExYSzVhdTdxeTM1TDR0NmxuLTAyU3c#gid=0 When we start at 1pm, we'll go over the session list and assign slots. So come ready to vote on what you like, too! - Gavin - 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] 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 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?
Would be good to know who the remaining svn users are. And who is using git/git-svn now. I'd love to see the breakdown. Data is good. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Maciej Stachowiak [m...@apple.com] Sent: Friday, March 09, 2012 4:43 PM To: Alexis Menard Cc: WebKit Development Subject: Re: [webkit-dev] Moving to Git? Here's my thoughts based on this and other comments On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote: > > To the global infrastructure : > - Local history for git. svn log access to the server every time you > call that command. Will improve the load of the server. > - Performance of checkouts/pull as data are send compressed from the server. Sounds like there is some potential benefit here, though we might want to explore beefing up the servers before changing the tools. > > To git user : > - Using git push rather than having to use git-svn (which you need to > keep in sync). > - Simplified workflow, we don't need to mess with git-svn. > - Companies who fork (we all do) can simplify their workflow a bit > regarding branches. It sounds like avoiding use of git-svn is the big benefit to git users and perhaps the reason this topic periodically comes up. Can anyone spell out in more detail the benefits of using straight git instead of git-svn? > > To svn user : > - Conflict resolving much easier and performant than svn (we have > drivers for changelogs and the default one are much better than svn). > - Local history/blaming/... > - Proper diff coloration (though I'm sure you guys have some magic > scripts using colordiff). > - The staging area, upload what you want/need and keep some work local > - Smaller checkouts So far many SVN users haven't found these benefits to exceed the switching cost, though perhaps more will be inspired to give git a try by this thread. Regards, 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 mailto: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 mailto: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?
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 mailto: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] 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 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 > > 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 wrote: > >> > On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian > >> > > >> > 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=get&search=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] 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
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] 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 wrote: > > 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] 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 > > 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] 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] 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?
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 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=8Ut9o4OdSC0&feature=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 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=8Ut9o4OdSC0&feature=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] [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 wrote: > > 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] 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
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 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 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] 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] [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] [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] 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] 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] Lots of “BREW” patches up for review
You have a complete port of BREW already? Interesting. Can you point to the complete sources so potential reviewers can have a look at what the state is? On Thursday 14 January 2010 07:02:24 am KwangYul Seo wrote: > I created a wiki for the BREW port of WebKit. > > https://trac.webkit.org/wiki/BREW > > Currently it contains preliminary information. I will add more > contents gradually. > > Thanks, > Kwang Yul Seo > > On Thu, Jan 14, 2010 at 9:22 AM, Ariya Hidayat wrote: > >> This is not a one-time code drop. We want to maintain the BREW port > >> ongoing and will do everything that are required to keep the BREW port > >> up and running. Porting DumpRenderTree is still under work, but we > >> have a complete BREW port which works fine both in BREW device and > >> simulator. > > > > Kwang, can you add the all information about the port to > > http://trac.webkit.org/wiki#WebKitPorts? I guess, make a new wiki page > > for that and add it to that list. > > > > > > -- > > Ariya Hidayat > > http://www.linkedin.com/in/ariyahidayat > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ > 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] 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 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] Should we ever change style guidelines?
On Thursday 10 December 2009 02:35:38 pm Peter Kasting wrote: > On Thu, Dec 10, 2009 at 11:28 AM, Adam Treat wrote: > > both are confusing and in my mind call for exercising reviewer > > discretion over the style guide. > > > > And I *do not* think the > > style guide is wrong for the *guide* to prefer "!foo" over "foo == 0"! > > OK. Then I have no idea what your standards are. Uses of !foo are > confusing, but foo == 0 shouldn't be preferred, except when it should. > Whatever. But I think I've been clear?! I think the style guideline for preferring '!foo' vs 'foo == 0' is a good one for the vast majority of cases. And it also happens to be the current rule which is a bonus :) However, I don't think it is a good rule to follow dogmatically. And I believe I've given good examples of why. You disagree? If a person thinks the style guidelines should only consist of those rules where there are no possible exceptions, then I guess such a person would advocate against removing this guideline. I however don't feel that they should be interpreted so dogmatically. > In several dozen emails we have progressed no further. Stalemates like > this and feelings like "this is inexplicable" as above are precisely why I > don't want reviewer judgement guiding style on patches that I or anyone > else submits. I guess the reverse is true for me. Stalemates like this are a good example of why I do want good reviewer judgement to be used when evaluating the style as well as the rest of the code in a patch. 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 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 Wednesday 09 December 2009 07:52:22 pm Peter Kasting wrote: > You haven't really said why. The closest you got was the vague "It is also > true that the current style guidelines if > practiced pedantically in every case can lead to potential bugs." Bugs > like what? Perhaps if there are some, we should change the appropriate > guide, instead of leaving the choice up to a reviewer, who, if the rule > really _can_ be problematic, might erroneously enforce it. Off the top of my head as a reviewer I'd accept: if (color.red() == 255 && color.green() == 0 && color.blue() == 255) // pink! over if (color.red() == 255 && !color.green() && color.blue() == 255) // pink! most days of the week... Consistency and all that. Cheers, Adam PS: Maybe not on a monday. I really hate mondays :) ___ 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 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] Should we ever change style guidelines?
On Wednesday 09 December 2009 06:33:20 pm Peter Kasting wrote: > On Wed, Dec 9, 2009 at 3:19 PM, Adam Treat wrote: > > With every new rule to the style guide I fear we > > lose the latter and become ever more pedantic about often trivial issues. > > I see no problem with pedantry. Pedantry over trivial issues wastes time. > A major problem: as you already noted, my common sense and yours disagree. > For example, the case indenting example you gave seems bad to me. Style > guides prevent us from arguing forever about things like this. They > streamline the review process, not lengthen it. And that is only a problem when we are disagreeing about non-trivial issues. The indentation of case labels I believe is a relatively trivial issue. And I would cite the already noted inconsistency of the current codebase as well as the documented disagreements on this list as evidence. > 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. > > I very much hope not. I have been on many bugs already where precisely > this happened. It was a fiasco. I think you overstate. It is also true that the current style guidelines if practiced pedantically in every case can lead to potential bugs. Note: I am not suggesting this is reason to change them. Corner cases should not make the guide. > I don't see that at all. What I see is us actually noticing style > violations instead of having them slip under the radar. Knowledge is good. How you act on that knowledge is another matter. 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 guidelinesrules, 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 r
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] 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 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] 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 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] 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] 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 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] 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"
> To: "Adam Barth"
> Cc: "WebKit Development"
> 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"
> > To: "Yong Li"
> > Cc: "WebKit Development"
> > 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 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] Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
I do not like this change. First, by retroactively changing this rule we are thereby making a not insubstantial number of existing header files non- compliant. Second, the change requires a fix for the tools. Third, why are we changing this? Not for consistency. Not for any functional advantage. Just because of the subjective opinion of a few. Well, a lot of the style rules are subjective. Should we start taking nominations for other pieces of the style rules that could be changed? Adam On Tuesday 22 September 2009 04:39:42 pm David Levin wrote: > Don't care either. (Just as long as there is consistency and that the style > guide reflects the current consensus.) > > > Will check-webkit-style need an update? > > Yes it will. (I'm pretty sure that the single fix needed will be > in check_namespace_indentation and then any corresponding test cases.) > > Dave > > On Tue, Sep 22, 2009 at 1:24 PM, Eric Seidel wrote: > > I'm fine either way. Will check-webkit-style need an update? I think it > > might. > > > > On Tue, Sep 22, 2009 at 1:23 PM, Sam Weinig wrote: > > > I also think this change is the right way to go. r=me. > > > > > > On Tue, Sep 22, 2009 at 1:20 PM, Brady Eidson wrote: > > >> I've always hated the indentation in header files. > > >> > > >> I have no objections. > > >> > > >> ~Brady > > >> > > >> On Sep 22, 2009, at 1:06 PM, David Hyatt wrote: > > >>> I had thought that we resolved ages ago that we would no longer be > > >>> indenting code inside namespaces in header files, since that just > > > > results in > > > > >>> the entire class declaration being pointlessly indented. > > >>> > > >>> This is point 3 on the page: > > >>> > > >>> http://webkit.org/coding/coding-style.html > > >>> > > >>> I'd like to reverse the Right and Wrong examples to fix this. > > >>> > > >>> Are there any objections to this change? I know a few months ago, > > > > people > > > > >>> agreed (notably Maciej) that there was no longer any point to > > > > essentially > > > > >>> indenting the entire file's contents (when we already don't do this > > >>> in > > > > .cpp > > > > >>> files). > > >>> > > >>> dave > > >>> (hy...@apple.com) > > >>> > > >>> ___ > > >>> 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 > > > > ___ > > 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] 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] 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] 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] 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] 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] 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] 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 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\WebCore>nmake -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
Re: [webkit-dev] Patch process - let's make it better
On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote: > * Phase 1 * > > A) Make it really easy to submit a patch. Eric's bugzilla-tool is > close to being there. I'm going to help him refine this tool to the > point that submitting a patch has only one step - a single command > will make the patch, file a bug if needed, attach the patch to the > bug, and flag it for review. > > B) Make it really easy to commit a patch. Again, I think bugzilla-tool > is the right path to achieving this. > > C) Improve the way we get attention from reviewers. I think we should > do three things here: > C.1) Split review queues, based on our emerging [Bracket] > convention for patches needing specialized review. If we find more > areas of specialty besides ports, we can add new [Bracket] tags. > C.2) Improve the quality of emails sent > C.3) Highlight in a special way patches that have been waiting > for review longer that some minimum period (a week?). These could be > highlighted visually in the review queue, and maybe would send extra > review request emails automatically. Speaking of your action plan... I've had a look at C.3 and was going to try to modify the bugzilla tools to highlight as you suggested. But after looking at the review queue over the last few days I'm not sure it is necessary or that it would help to fix the problem. http://www.webkit.org/pending-review The page above already lists the review queue sorted by date. Over the last few days the queue has numbered in the 100's. A significant fraction (50%+) are older than a week. I could highlight them, but if it is already ordered by date and the highlight will encompass more than half the queue... what's the point? Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 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
[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] Please welcome GYP to the our dysfunctional build family
On Sunday 12 July 2009 10:42:26 am Jeremy Orlow wrote: > On Sun, Jul 12, 2009 at 5:38 AM, Adam Treat wrote: > > On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: > > > Dear WebKiteurs, > > > > > > In our persisting quest to be more like a common WebKit port, we have > > > added Chromium build files to the tree this afternoon. These files are > > > WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they > > > are the GYP include files. As you may know, we use GYP > > > (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and > > > even Make projects for Chromium. > > > > > > We are rather fond of GYP. Perhaps it is because it allows us to > > > maintain one set of project files for all three Chromium platforms; > > > > Gyp sounds remarkably similar to CMake to me. I've never heard of Gyp > > before > > so I don't know much more about it than what you've said in this email, > > but CMake has been around for quite sometime and is in very wide use in > > the Open > > Source community. Can you say what prompts the use of Gyp over a tool > > like CMake? > > From a quick glance at cmake's website, it seems that it's a build system > and not a project file generator. I think it was pretty important to us to > generate project files so that you can use the full power of each > platform's IDE and toolchain. Take a more detailed look. CMake is a meta-build system. It generates native project files for Windows Visual Studio, XCode and GNU Makefile. Just like Gyp if I understand correctly. It has been around for a good amount of time and works under every major platform. KDE uses CMake exclusively to build on every platform. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: > Dear WebKiteurs, > > In our persisting quest to be more like a common WebKit port, we have > added Chromium build files to the tree this afternoon. These files are > WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they > are the GYP include files. As you may know, we use GYP > (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and > even Make projects for Chromium. > > We are rather fond of GYP. Perhaps it is because it allows us to > maintain one set of project files for all three Chromium platforms; Gyp sounds remarkably similar to CMake to me. I've never heard of Gyp before so I don't know much more about it than what you've said in this email, but CMake has been around for quite sometime and is in very wide use in the Open Source community. Can you say what prompts the use of Gyp over a tool like CMake? 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.name&type0-0-0=equals&value0-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] [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] 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] 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 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 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] 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
[webkit-dev] NOTICE: run-webkit-tests has changed default behavior
Hi, With revision 41183 the 'run-webkit-tests' has changed default behavior so that no new test results are generated for any port other than the canonical Apple Mac port. This means that other ports which wish to update to include results for newly created tests will need to explicitly pass the new-test- results flag to the 'run-webkit-tests' script. This behavior change is a result of the fact that no other port is reasonably up to date with all the new results and as a consequence running the script with default arguments can result in littering hundreds of new files in the source tree. Just wanted to give a heads up to those responsible for the maintaining the layout test results for other ports. 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 Tuesday 13 January 2009 5:53:33 am goldeneyes wrote: > Bugzilla from tr...@kde.org wrote: > > Not sure what port you are using, but perhaps put in a 'return;' at the > > beginning of Frame::paint(...) ? > > > > Adam > > hi, > > I want to do the same thing, I search the word "Frame:" with the following > command: > find /home/hiba/webkit-last-version/WebKit/ -type "f" | xargs grep -i > "Frame::" | less -S > but i don't found "Frame:: paint" > where i can find it ? please, can you help me. > > thank you in advance for any help, 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 ___ 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; 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
Re: [webkit-dev] Async IconDatabase and reading icons from disk on startup
On Sunday 11 May 2008, Adam Treat wrote: > 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. Simon, I don't think QtWebKit API deals with this asynchronous nature of the IconDatabase at all. I'm not sure how to deal with it as it would seem that QWebSettings::iconForUrl() needs to be deprecated and possibly all the icon database API in QWebSettings. Looks like we need at a minimum a public API signal that the icon has been loaded (either from disk or network) and that will require a new class as QWebSettings is not a QObject. QWebIconDatabase ?? :( Cheers, 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: > 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
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
[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
[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(QList 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
[webkit-dev] Patch to prepend the name of the git branch to the $baseProductDir
Hi,
This patch will prepend the git branch name if you are in one to the
$baseProductDir if you have the appropriate key/value pair in your git config
file.
The use case is a developer who is switching between branches and testing but
doesn't want to clobber his build everytime. The default is off and you can
override the global setting on a branch by branch basis.
Comments and review welcome...
Adam
diff --git a/WebKitTools/ChangeLog b/WebKitTools/ChangeLog
index 3067d7c..9ad38d4 100644
--- a/WebKitTools/ChangeLog
+++ b/WebKitTools/ChangeLog
@@ -1,3 +1,12 @@
+2007-11-19 Adam Treat <[EMAIL PROTECTED]>
+
+Reviewed by NOBODY (OOPS!).
+
+* Script changes for usage with git branches.
+
+* Scripts/VCSUtils.pm:
+* Scripts/webkitdirs.pm:
+
2007-11-12 Adam Roben <[EMAIL PROTECTED]>
* Scripts/update-webkit-localizable-strings: Changed to only scan the
diff --git a/WebKitTools/Scripts/VCSUtils.pm b/WebKitTools/Scripts/VCSUtils.pm
index 3ba40e1..731b3fe 100644
--- a/WebKitTools/Scripts/VCSUtils.pm
+++ b/WebKitTools/Scripts/VCSUtils.pm
@@ -44,6 +44,8 @@ our @EXPORT_OK;
my $isGit;
my $isSVN;
+my $gitBranch;
+my $isGitBranchBuild;
sub isGitDirectory($)
{
@@ -59,6 +61,32 @@ sub isGit()
return $isGit;
}
+sub gitBranch()
+{
+unless (defined $gitBranch) {
+chomp($gitBranch = `git symbolic-ref HEAD`);
+$gitBranch =~ s/refs\/heads\///;
+$gitBranch =~ s/master//;
+}
+
+return $gitBranch;
+}
+
+sub isGitBranchBuild()
+{
+my $branch = gitBranch();
+chomp(my $override = `git config branch.$branch.webkitbranchbuild`);
+return 1 if $override eq "true";
+return 0 if $override eq "false";
+
+unless (defined $isGitBranchBuild) {
+chomp(my $gitBranchBuild = `git config --bool core.webkitbranchbuild`);
+$isGitBranchBuild = $gitBranchBuild eq "true";
+}
+
+return $isGitBranchBuild;
+}
+
sub isSVNDirectory($)
{
my ($dir) = @_;
diff --git a/WebKitTools/Scripts/webkitdirs.pm b/WebKitTools/Scripts/webkitdirs.pm
index a2b1e32..1ba0c27 100644
--- a/WebKitTools/Scripts/webkitdirs.pm
+++ b/WebKitTools/Scripts/webkitdirs.pm
@@ -31,6 +31,7 @@ use warnings;
use FindBin;
use File::Basename;
use POSIX;
+use VCSUtils;
BEGIN {
use Exporter ();
@@ -123,6 +124,12 @@ sub determineBaseProductDir
if (!defined($baseProductDir)) {
$baseProductDir = "$sourceDir/WebKitBuild";
+
+if (isGit() && isGitBranchBuild()) {
+my $branch = gitBranch();
+$baseProductDir = "$baseProductDir/$branch";
+}
+
@baseProductDirOption = ("SYMROOT=$baseProductDir", "OBJROOT=$baseProductDir") if (isOSX());
if (isCygwin()) {
my $dosBuildPath = `cygpath --windows \"$baseProductDir\"`;
@@ -698,11 +705,17 @@ sub buildQMakeProject(@)
my $dir = baseProductDir();
if (! -d $dir) {
-mkdir $dir or die "Failed to create product directory " . $dir;
+system "mkdir", "-p", "$dir";
+if (! -d $dir) {
+die "Failed to create product directory " . $dir;
+}
}
$dir = $dir . "/$config";
if (! -d $dir) {
-mkdir $dir or die "Failed to create build directory " . $dir;
+system "mkdir", "-p", "$dir";
+if (! -d $dir) {
+die "Failed to create build directory " . $dir;
+}
}
chdir $dir or die "Failed to cd into " . $dir . "\n";
___
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 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] 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-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] 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: [webkit-dev] QtLauncher for Windows
On Wednesday 18 July 2007, [EMAIL PROTECTED] wrote: > Hi all, > > I have a project using Qt that is necessary a web browser internally. I am > having problems for compilation of WebKti in Windows. Can QtLauncher to be > compiled in Windows??? No, not yet. This subject has come up many times. Please search the list archives. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Building errors and QT
On Sunday 15 July 2007, Steve Atkins wrote: > On Jul 15, 2007, at 2:16 PM, George Staikos wrote: > > On 14-Jul-07, at 6:16 PM, Nagy Tamás wrote: > >> Other question :I'm also interested in compiling it with QT, I > >> downloaded QT OpenSource Edition for Windows, but I couldn't > >> compile it anyway. Could somebody send me (or tell e, where can I > >> find) a step-by-step documentation, how should I build webkit with > >> QT, please? > > > > We don't presently support building WebKitQt on Windows. We'll > > add support in the future (or you're welcome to contribute it). > > Any guesses as to how difficult that would be to do - just beating on > the build automation, or might some of the code be VC++ unfriendly? The biggest problem is the use of our custom qmake 'compilers' for the various bits. For instance, the path is hardcoded in many parts and uses the unix directory separator. The hard part will be getting this all to work using cygwin tools and the windows compiler. I haven't looked at it since the release of the windows port, but this might make it easier. Anyways, not a terribly difficult task, just will take a bit of time. 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] Why QtLauncher doesn't load pages from internet ?
On Monday 09 July 2007, vic burka wrote: >>No, it is incorrect. QtLauncher can of course display pages from the net as >>well as local pages. Same for images. Works fine here. > Thaks Adam for your response. I think the reason in that I commented some > soucrce code because I couldn't compile WebKit. I got the following errors: Yah, I wouldn't do that. > I found description of this problem on wiki > (http://trac.webkit.org/projects/webkit/wiki/BuildingQtOnLinux) - they > advised: "This error is typically caused by not having gperf installed. > Install gperf, run touch WebCore/html/DocTypeStrings.gperf and try building > WebKit again." > > but I did this - and I got the same errors. I checked if gperf is in PATH so I typed: > > gperf > > at the console - it runs. > What version of gperf do you have installed? > > So may be you could help me to compile the WebKit correctly ? > > My platforms is : > openSuSE 10.2, > g++ (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux), > Qt-x11-4.3.0 > > I will thank for any help. Sure. Adam ___ 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 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
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
[webkit-dev] Syncing javascript keycode's across platforms
Hi, Currently the keycodes returned by the various platforms under WebKit are nowhere near close to uniform. This seems like something that should be standard across all platforms that WebKit provides. It is unclear to me exactly how the keycodes are generated by the different platforms... In platform/qt/PlatformKeyboardEventQt.cpp the following snippet of code seems to handle the return code for the up arrow key: case Qt::Key_Up: return VK_UP; // (26) UP ARROW key The equivalent code for the mac would seem to be in platform/mac/KeyEventMac.mm: // VK_UP (26) UP ARROW key case NSUpArrowFunctionKey: return 0x26; The actual behavior under Safari seems to be to return '63232' I am not at all aware how this happens. The current mess for javascript keycodes is nicely summarized on this page. http://www.unixpapa.com/js/key.html If we can't fix this as a standard across browsers, surely this could be fixed across platforms that WebKit provides, no? Adam PS Any clue as to where Safari turns that code into '63232' would be much appreciated. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
