Re: [webkit-dev] CMake for Apple's Windows port

2012-04-12 Thread Adam Treat
If my memory serves me the problem was that Apple couldn't figure out how to 
get cmake installed on the Apple build system machine.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Dirk Pranke [dpra...@chromium.org]
Sent: Thursday, April 12, 2012 2:06 PM
To: Patrick Gansterer
Cc: WebKit Development
Subject: Re: [webkit-dev] CMake for Apple's Windows port

I think this is great; I've been meaning to spend some time on the
apple win port trying to fix the remaining bugs holding up the switch
to NRWT, but the fact that the apple win port still uses VS2005 is
definitely an impediment (yes, I can probably just pull the binaries
down from a bot for my purposes, but I'd really like to be able to
build it).

Patrick, have you documented what all you need to install on a Win box
in order to be able to run CMake and do the build?

Can someone from Apple weigh in on whether switch to CMake would be feasible?

-- Dirk

On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com wrote:
 Hi,

 it's more than a year since the last discussion about the build system of 
 Apple's Windows port. In the meantime I merged most of the general changes 
 into the CMake files in the repository and have a working patch with a few 
 CMake files at [1] as written in [2]. I don't think that it is ready to 
 replace the existing vcproj files already, but I like to hear all points 
 needed to do that.
 Adding CMake files for the WinCairo port (which uses the vcproj files too) 
 will be very easy when the Apple version has been added.

 Here some benefits to the CMake version:
 1) Shared build system: The shared files are already used by the Blackberry, 
 EFL and WinCE port, so only the list of platform specific files needs to be 
 maintained.
 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 
 version of the required executables (bison, gperf, flex, perl and python) 
 like the WinCE port does already (see [4]).
 3) Less Solution targets: Some of he current vcproj files only used for 
 triggering Makefiles. The vcproj generates more native vcproj files, which 
 e.g. allows clicking on one of the IDL files to generate the corresponding 
 files.
 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows 
 an easy transition to other (newer) Visual Studio versions, since every 
 developer can choose his preferred version.
 5) It's possibe to create Makefiles: The output of the windows buildbots 
 shows much unwanted messages. Using Makefiles on the bots can produce cleaner 
 logs and take advantage of all cores when used with JOM [7].

 Would be great if people who use the current VS Solution can give the CMake 
 version a try and provide some feedback about it.

 BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a 
 positive response.

 [1] https://bugs.webkit.org/show_bug.cgi?id=72816
 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html
 [3] https://bugs.webkit.org/show_bug.cgi?id=48166
 [4] http://trac.webkit.org/wiki/WinCE#Build
 [5] https://bugs.webkit.org/show_bug.cgi?id=53445
 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html
 [7] http://qt-project.org/wiki/jom
 [8] https://bugs.webkit.org/show_bug.cgi?id=73100

 -- Patrick
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Adam Treat
With svn up you are just as likely to see a conflict.

From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa 
[rn...@webkit.org]
Sent: Thursday, March 08, 2012 3:12 PM
To: Adam Treat
Cc: Ashod Nakashian; WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat 
atr...@rim.commailto:atr...@rim.com wrote:
There is nothing about git that forces you to have multiple branches locally.  
Good practice, yes, but nothing forcing it.  As for the difficulty of resolving 
conflicts between patches you've made locally and changes made on the shared 
repository since you started making your local patches... nothing about git 
makes this any harder.  Unless you have a lock based source control system 
you'll have to resolve conflicts.

On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason 
jma...@rim.commailto:jma...@rim.com wrote:
It seems to me that there's no need to use multiple local branches in git if 
you find it confusing - it's an additional feature, but I don't see anything 
that requires it.

What workflow do you have that requires you to have multiple branches locally 
in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is 
the svn equivalent easier?

The simplicity. In git, I have to worry about things like committing local 
changes before rebasing to master, or stashing, etc... In svn, all I have to do 
is to run svn up.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Adam Treat
Indeed it is.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Carlos Garcia Campos [carlo...@webkit.org]
Sent: Thursday, March 08, 2012 12:38 PM
To: Alexis Menard
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
  It is possible to keep linear history with git.  This just requires you to 
  fast forward and rebase before pushing.

 But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

  Konrad
  Sent from my BlackBerry on the Rogers Wireless Network
 
  - Original Message -
  From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
  Sent: Thursday, March 08, 2012 12:27 PM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Moving to Git?
 
  El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
  On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
   On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
   ashodnakash...@yahoo.com
   wrote:
  
   In the light of discovering that some SVN scripts have fallen behind in
   terms of maintenance[1] and WebKit's strong Git support and 
   infrastructure,
   against my better judgement, I'd like to distract you from being 
   productive
   by bringing up this topic (again).
  
   The wiki page of the same name[2] was created 3 years ago and hardly
   updated since[3]. I know we're all busy with more important things, but 
   IMHO
   I think we can at least update the wiki and perhaps vote on when/how we
   should do the eventual transition.
  
   I understand that while this type of work isn't necessarily very
   productive, maintaining two repositories and sets of scripts (with their
   docs and issues) has a very real cost as well. I'm proposing we 
   reevaluate
   the situation and act accordingly.
  
  
   Re-evaluating the situation is good, but I'm still opposed.
 
  I don't use svn but the only benefit I see of WebKit using svn is the
  linear history, clean, easy to read and to explore. Git repos tend to
  have merging commits a lot and it leads to make bisecting/history
  browsing harder (my taste).
 
  I agree about merging commits, but I think it's possible to enforce all
  merges to be fast-forward and without merging commits. In general
  browsing git history is easier and cleaner than svn, and more important
  it's much faster (my taste :-P)
 
  Then for everything else I use git and its power locally.
 
  I would be more than happy with the switch :-)
 
  --
  Carlos Garcia Campos
  http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
  -
  This transmission (including any attachments) may contain confidential 
  information, privileged material (including material protected by the 
  solicitor-client or other applicable privileges), or constitute non-public 
  information. Any use of this information by anyone other than the intended 
  recipient is prohibited. If you have received this transmission in error, 
  please immediately reply to the sender and delete this information from 
  your system. Use, dissemination, distribution, or reproduction of this 
  transmission by unintended recipients is not authorized and may be unlawful.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-08 Thread Adam Treat
There is nothing about git that forces you to have multiple branches locally.  
Good practice, yes, but nothing forcing it.  As for the difficulty of resolving 
conflicts between patches you've made locally and changes made on the shared 
repository since you started making your local patches... nothing about git 
makes this any harder.  Unless you have a lock based source control system 
you'll have to resolve conflicts.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Thursday, March 08, 2012 3:00 PM
To: Ashod Nakashian
Cc: WebKit Development
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
And that's a show stopper for me. For build bot maintenance, regression fixes, 
etc... being able to easily tell the number of commits between two revisions 
(in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can 
enforce fast-forward as many have pointed out and we can maintain an SVN 
mirror. Although I don't like the idea of maintaining an SVN repo, and it's 
almost universally agreed that git offers superior tools to SVN.

I don't think so. I like the simplicity of svn. While git client works great, I 
always get frustrated by the complexity of having multiple branches locally and 
the amount of work required to merge the remote changes on the branch I'm 
working on.

- Ryosuke


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Help with review of EFL CMake patches?

2010-05-03 Thread Adam Treat
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

2010-04-21 Thread Adam Treat
Can someone from Apple comment on whether it is possible to include the 
sources to CMake and then the CMake could bootstrap itself with only 
dependency on the compiler?  This would seem an acceptable solution, no?

Adam

On Tuesday 20 April 2010 01:06:43 pm Bradley Nelson wrote:
 Would prebuilt checked-in binaries be an option? Can cmake run out of an
 arbitrary directory?
 
 -BradN
 
 On Tue, Apr 20, 2010 at 5:25 AM, Bill Hoffman bill.hoff...@kitware.comwrote:
  On 4/20/2010 5:13 AM, Maciej Stachowiak wrote:
   1) None of the Mac builders have CMake installed.
   
  2) The organization that maintains the Mac builders is not willing to
  let teams use any build systems to build that do not come with the OS,
  or to install any custom binaries on the builders, because builds need
  to be reproducible.
  
  So, long term is there a way for CMake to come with the OS?  I mean gmake
  is part of the OS, python seems to be OK, how does a tool get promoted to
  such a level?
  
   3) CMake is not part of the standard Mac OS X install for any shipping
   
  version of Mac OS X.
  4) LLVM compiles using a separate Makefile-based (and apparently
  autoconf and autogen based) build system in OS builds.
  5) LLVM uses CMake to build on Windows.
  6) The build organization is more willing to install custom tools on
  Windows builders.
  
  I think this rules out using CMake to build the mac port. Even if we got
  it set up, we'd need to maintain some kind of parallel build system for
  production builds via the build farm, which would negate the benefit. It
  might be possible to use CMake for Apple's Windows port, but if we
  switch away from native project formats at all, ideally we'd like to
  switch both ports to the same build system.
  
  I am wondering if you could include the sources to CMake inside the
  source tree for the Mac build farms.  CMake really only depends on the
  C++ compiler, and that is part of the OS.  You could use CMake's
  bootstrap script to build it.   Then run that CMake to generate the
  build.  I could help you create a lean CMake that would only build the
  features used for the build of WebKit.
  
  Since gyp does not require any special software to be installed merely
  to build, it seems like a more plausible option at the moment.
  
   Note: this is not to hate on CMake, I just don't want to end up in a
   
  position where we have to maintain two parallel build systems for the
  Mac port, or fight with other organizations about the operation of the
  build farm. Requiring CMake to be installed at build time seems like a
  showstopper from that point of view.
  
   So, rather than install one program, Apple would rather have one of its
  
  developers maintain a forked build system.  I would of course like to see
  this change.   I would think it would be possible to change this. I
  suppose if enough tools that Apple uses move to CMake, it would become
  OK.  Anyway, what do think about building CMake with the project?
  
  -Bill
  
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake vs. Apple's build farm

2010-04-21 Thread Adam Treat
CMake is BSD style license so I don't think that is a problem.  I understand 
that a lot of this is hypothetical and the last thing we want is to make life 
more difficult for our developers.  I'm just trying to understand up front 
whether or not there are legitimate show stoppers before people go through a 
lot of effort trying to convert Apple's Windows port to a CMake build for demo.

Adam

On Wednesday 21 April 2010 02:24:26 pm Darin Adler wrote:
 On Apr 21, 2010, at 9:45 AM, Adam Treat wrote:
  Can someone from Apple comment on whether it is possible to include the
  sources to CMake and then the CMake could bootstrap itself with only
  dependency on the compiler? This would seem an acceptable solution, no?
 
 Hard to comment on something that’s hypothetical, but given the high level
 description, it’s not impossible.
 
 Part of this depends on the license for CMake.
 
 And it will be a lot of work for someone at Apple. The platforms where this
 sort of thing is most difficult are older ones where WebKit is built with
 old versions of development tools. Even small changes to the build system
 create challenges for my team here at Apple. We do our best to hide this
 complexity and prevent it from directly affecting the others working on
 WebKit.
 
 -- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Fwd: CMake WebKit-EFL: initial preview

2010-04-20 Thread Adam Treat
I'd really like to see this on bugs.webkit.org with a proper patch splitting 
out the CMake portion.  I understand that this is primarily motivated by your 
desire to see EFL port build, rather than to solve the build system problem, 
but this *DOES* add a new build system to the tree.  I think we have to see if 
we can get the Apple showstopper cleared up.  I think installing CMake sources 
and getting Bill's help to create a streamlined CMake binary is a great idea.

Adam

On Tuesday 20 April 2010 08:29:55 am Gustavo Sverzut Barbieri wrote:
 On Mon, Apr 19, 2010 at 11:34 PM, Patrick Roland Gansterer
 
 par...@paroga.com wrote:
  Hi,
  
  Gustavo Sverzut Barbieri:
  Find attached 2 patches.
  
  ? ?- WebKit-EFL-CMake_All-Missing-Patches.patch is a bundle that
  implements CMake support for WebKit-EFL and also adds the missing
  patches to make it compile (but runs with some bugs, needs updating to
  some api changes). Apply it if you want to compile the port (also get
  EFL from svn, see http://svn.enlightenment.org/)
  
  ? ?- WebKit-EFL-CMake.patch is just the CMake support, a single
  CMakeLists.txt and support *.cmake modules
  
  Please take a look if you are interested in CMake for WebKit-EFL.
  
  If you know CMake already, review it and send comments. My team just
  started with CMake some days ago.
  
  Can you please post the patch at bugs.webkit.org.
 
 will do as soon as we get the .pc generated and installed, otherwise
 the external programs cannot know how to link to it.
 
  Maybe you can split it into a CMake and a other stuff part. (Was it
  already before you merged it?)
 
 It is already, the patch is at
 http://people.profusion.mobi/~gustavo/WebKit-EFL-CMake.patch
 
  I'd like to give you some feedback at the bug comments. The CMake file
  should be split into different projects for example.
 
 Hum... I saw everywhere that it was common to split in multiple
 directories, particularly for JavaScriptCore and WebCore. But given
 that I wanted to keep it simple, I forced it to be one single file to
 make merge into SVN easier. I was also worried about the propagation
 of settings and flags to the sub-folders. But yes, I notice that it
 will make easier to use INCLUDE_DIRECTORIES() as we'd just have one
 target per directory.
 
 Our primary goal is not to join into the recent GYP x CMAKE
 discussion, but we need our EFL port fully landed to avoid the
 overhead we're doing now. We were using the GTK autotools, as we were
 more familiar with it, but given it is slow and messy, the GTK guys
 did not want to merge our patches right away, requesting a cleanup of
 existing code first. We did part of the cleanup and CMake in parallel,
 but CMake worked out quite nice and we don't plan to use GTK's
 autotools anymore (but we did send the cleanup we achieved until now).
That is to say that making it simple to be merged is our first aim.
 
 One more thing I'd like to kindly ask you is if you can also post
 patches to the CMake files. This is because our team is already
 suffering to match the latest WeKit changes (we have already a huge
 queue waiting to be merged, and now patches have to be rebased and so
 on). So the more help, the better! :-)
 
 BR,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [webkit meeting notes] build systems

2010-04-16 Thread Adam Treat
I am very skeptical that it is feasible to write a gyp generator that would 
output QMake files.  There is a log of magic in those QMake files.  My sense is 
that it would not be trivial by any means.

Plus, I don't like the idea of a meta-meta generators.  Seems way to mickey-
mouse to me.

Adam

On Friday 16 April 2010 12:42:01 am Peter Kasting wrote:
 On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier 
kev...@theolliviers.comwrote:
  Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're
  probably better off trying to synchronize the build systems automatically
  in some way. My perception is that Qt developers will want to use qmake,
  GTK will want to use autotools, etc. and while some build systems could
  certainly be merged (e.g. as you say the Win and Mac projects for WebKit
  itself could be gyp-generated), I don't think we'll ever really narrow
  it down to one master system for a variety of reasons. I do, however,
  think we may be able to narrow the 'build system updating' process down
  to one step / one script that updates all ports simultaneously, and do
  so without too much effort.
 
 If I'm not mistaking you, that seems to be the route Evan is discussing,
 with his concrete proposal being to investigate the feasibility of making
 gyp be the mechanism by which various different build systems can be
 generated from a single place (rather than seven).  Or is this not what you
 were saying?
 
 Since most build systems out there have their data stored in either XML or
 
  plain text, converting a build file list from one build system's data
  format to another is probably not more than a few hours of Python
  hacking, if that.
 
 Indeed, we already have MSVC/XCode/makefile generators for gyp, I would
 assume that given those, a generator for e.g. qmake wouldn't be hard.
 
 I really think someone should seriously consider investing some time and
 
  resources into improving this issue though, updating a build system
  doesn't take long but updating 7-10 build systems on almost a daily
  basis probably adds up to some pretty significant amount of time and
  energy that could probably be spent on better things.
 
 I think that is the shared viewpoint that has led to this discussion.
 
 PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake as a build system?

2010-04-16 Thread Adam Treat
On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote:
 Hi,
 
 Adam Treat (tr...@kde.org) suggested that I join this list to talk about
 CMake as an option for a unified cross platform build solution.  My name
 is Bill Hoffman.  I am the lead CMake developer.  My company Kitware
 created and supports CMake.  I think CMake would have a lot to offer the
 WebKit developers.
 
 If you are not familiar with CMake, I did a google tech talk in December
 which can be found here:
 http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata
 
 Another article about how KDE switched to CMake can be found here:
 Why the KDE project switched to CMake -- and how
 http://lwn.net/Articles/188693/
 
 If you are interested in moving to CMake, I would be interested in
 helping.  If you have any questions about CMake, fire away!
 
 Thanks.
 
 -Bill

I asked Bill to introduce himself here because I think CMake represents the 
best hope for WebKit to find a way out of the current build system 
proliferation we are experiencing.  Of the meta-buildsystems in existence I 
think CMake is by far the most powerful and mature.  CMake is by far the most 
widespread and supported.  It is already used successfully by Open Source 
projects of a comparable scope to WebKit and with similar cross-platform 
needs: LLVM, KDE, Boost.

I know that WebKit already has GYP and QMake meta-buildsystems, but to my 
knowledge both are inferior to CMake.  In fact, I do not think CMake is 
lacking in any important way to the features of GYP.

What's more, the WebKit project has already had a CMake based buildsystem.  
This is what the 'Unity' nascent QtWebkit port used originally.  I think we 
should re-introduce it and seriously consider using CMake as a cross-platform 
solution to our build system proliferation issues.

I highly encourage you all to view the google tech talk above as it gives a 
great introduction to CMake.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake as a build system?

2010-04-16 Thread Adam Treat
Sure.  Having Bill's and Kitware's help will hopefully make it easier to 
produce such a demo using CMake.  I pledge to help.

We can start with this:

http://trac.webkit.org/log/trunk/CMakeLists.txt?rev=17853

Cheers,
Adam

On Friday 16 April 2010 05:34:45 pm Eric Seidel wrote:
 I don't see this as a decision needing pre-approval.
 
 This is a decision needing code.  No one has tried to make Mac, Win,
 or other ports use a common system yet.  Obviously converting them in
 the end requires buy-in from those ports.  But producing a demo
 doesn't/shouldn't.
 
 I eventually plan to look at this task.  When I do, I'll take a peek at
 CMake.
 
 Someone just needs to sit down and build something.  Then we can make
 an informed decision.
 
 -eric
 
 On Fri, Apr 16, 2010 at 2:29 PM, Adam Treat tr...@kde.org wrote:
  On Friday 16 April 2010 05:10:25 pm Bill Hoffman wrote:
  Hi,
  
  Adam Treat (tr...@kde.org) suggested that I join this list to talk about
  CMake as an option for a unified cross platform build solution.  My name
  is Bill Hoffman.  I am the lead CMake developer.  My company Kitware
  created and supports CMake.  I think CMake would have a lot to offer the
  WebKit developers.
  
  If you are not familiar with CMake, I did a google tech talk in December
  which can be found here:
  http://www.youtube.com/watch?v=8Ut9o4OdSC0feature=youtube_gdata
  
  Another article about how KDE switched to CMake can be found here:
  Why the KDE project switched to CMake -- and how
  http://lwn.net/Articles/188693/
  
  If you are interested in moving to CMake, I would be interested in
  helping.  If you have any questions about CMake, fire away!
  
  Thanks.
  
  -Bill
  
  I asked Bill to introduce himself here because I think CMake represents
  the best hope for WebKit to find a way out of the current build system
  proliferation we are experiencing.  Of the meta-buildsystems in
  existence I think CMake is by far the most powerful and mature.  CMake
  is by far the most widespread and supported.  It is already used
  successfully by Open Source projects of a comparable scope to WebKit and
  with similar cross-platform needs: LLVM, KDE, Boost.
  
  I know that WebKit already has GYP and QMake meta-buildsystems, but to my
  knowledge both are inferior to CMake.  In fact, I do not think CMake is
  lacking in any important way to the features of GYP.
  
  What's more, the WebKit project has already had a CMake based
  buildsystem. This is what the 'Unity' nascent QtWebkit port used
  originally.  I think we should re-introduce it and seriously consider
  using CMake as a cross-platform solution to our build system
  proliferation issues.
  
  I highly encourage you all to view the google tech talk above as it gives
  a great introduction to CMake.
  
  Cheers,
  Adam
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CMake as a build system?

2010-04-16 Thread Adam Treat
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?

2010-04-16 Thread Adam Treat
On Friday 16 April 2010 09:58:17 pm Bill Hoffman wrote:
  Also: how hard is the dependency on being installed? Is this a solvable
  problem if it turns out to be a showstopper for some folks?
 
 It has to be installed, if this is a show stopper, then it is a show
 stopper.

To be clear, it just has to be in the path, right?  Which I think could be 
managed ;)

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Adam Treat
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

2010-04-09 Thread Adam Treat
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

2010-04-09 Thread Adam Treat
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

2010-04-08 Thread Adam Treat
Hi,

Can someone please point to the bug report and the forum where this 
development was discussed by the greater WebKit community?

Cheers,
Adam

On Thursday 08 April 2010 08:58:22 pm Maciej Stachowiak wrote:
 On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote:
  I suppose I could wait until you land the patches and see by myself,
  but:
  
  - In the wiki you mention that one goal of the new framework is to
  provide a stable C-based API. Is this meant as a public API for
  WebKit, the same in all platforms (like JSC), or a stable internal API
  for embedders to use in order to implement their native APIs on top?
  
  From some lines in the wiki (like WKView wrapping native objects) it
  
  seems like you want to do the former, but that seems like quite a
  massive effort and the loss of an important selling port of the
  various WebKit ports.
 
 It will be available as a public API, but as Darin explained, it's up
 to individual ports whether to wrap this API, expose it directly, or
 do some combination. For the Mac OS X API, we will be doing a
 combination.
 
  - Does your new framework require any significant changes in WebCore?
  Could you briefly summarize them?
 
 No WebCore changes are required - it works with the existing WebCore.
 
  - Do you see valid usecases in the long term for the traditional
  ports or are your plans to quickly transition all code to the new
  system as soon as it's ready?
 
 I think that would be up to the individual ports. We expect that on
 Mac OS X, we will have to support the classic WebKit API for a long
 time, perhaps indefinitely, in parallel with the new WebKit2-based API.
 
 Regards,
 Maciej
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Announcing WebKit2

2010-04-08 Thread Adam Treat
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote:
 On Apr 8, 2010, at 6:23 PM, Adam Treat wrote:
  Can someone please point to the bug report and the forum where this
  development was discussed by the greater WebKit community?
 
 The time for that discussion is now. The forum is here.
 
 I suggest we use this mailing list, not a bug report.

Isn't that a little cart before the horse?  It is already actively being 
landed...

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [Bulk] parallel painting

2010-04-05 Thread Adam Treat
I think we'd be interested to see a cross-platform version from the 
perspective of the OpenVG graphics backend.

On Sunday 04 April 2010 01:32:54 am Zoltan Herczeg wrote:
 Hi,
 
 I am working on a parallel painting feature for WebKit (bug id: 36883).
 Basically it records the painting commands on the main thread, and replay
 them on a painting thread. The gain would be that the recording operation
 is cheap. Currently it is Qt specific, but I could make it more platform
 independent if other ports are interested.
 
 Zoltan
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] webkit installation on linux

2010-03-11 Thread Adam Treat
This is not the correct forum for these types of questions.

http://lists.webkit.org/mailman/listinfo/webkit-help

This above is a better forum, but such basic build questions should likely be 
solved with google and a bit of elbow grease.

Cheers,
Adam

On Thursday 11 March 2010 10:24:20 am Shivaprasad P wrote:
 Hi all,



 I want to install webkit on fedora fc7 linux.

 I installed gperf-3.0.4, glib 2.21.6 and downloaded
 WebKit-r55740 version got from
 http://nightly.webkit.org/builds/trunk/src/1 .

 I am getting following error:

  configure: error: Cannot find icu-config. The ICU library is needed.



 Can anybody tell howto resolve this error and is it I am installing
 right webkit version for fedora linux fc7?



 Regards

 Shiv

 The information contained in this e-mail message and in any
 attachments/annexure/appendices is confidential to the
 recipient and may contain privileged information.
 If you are not the intended recipient, please notify the
 sender and delete the message along with any
 attachments/annexure/appendices. You should not disclose,
 copy or otherwise use the information contained in the
 message or any annexure. Any views expressed in this e-mail
 are those of the individual sender except where the sender
 specifically states them to be the views of
 Toshiba Embedded Software India Pvt. Ltd. (TESI),Bangalore.

 Although this transmission and any attachments are believed to be
 free of any virus or other defect that might affect any computer
 system into which it is received and opened, it is the responsibility
 of the recipient to ensure that it is virus free and no responsibility
 is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
 damage arising in any way from its use.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [Bulk] how to get response in QtWebKit

2010-03-11 Thread Adam Treat
On Thursday 11 March 2010 10:50:19 am Meir Yanovich wrote:
 Hello all im beginner with QtWebKit i build simple web frame that loaded
 page ( server side ) and when from this page i submit data i like to catch
 the response string from the server in the c++ side how can i do that ?

Again, this is not the correct forum for these questions.  This mailing list 
exists for WebKit contributors to discuss ongoing development of WebKit 
itself.

You can use this forum for your questions:
http://lists.webkit.org/mailman/listinfo/webkit-help

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Unofficial reviews (WAS: Why I'm reviewing patches outside my area (and why you should too))

2010-03-10 Thread Adam Treat
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

2010-01-27 Thread Adam Treat
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?

2010-01-22 Thread Adam Treat
On Friday 22 January 2010 12:09:14 pm Darin Adler wrote:
 On Jan 22, 2010, at 7:16 AM, Christopher White wrote:
  Is it possible to save the DOM resulting from the parsing of HTML / CSS
  into a file and then read it back instead of re-parsing the HTML (similar
  to Java object serialization).

 WebKit has a feature called web archives that does something like this.

Correct me if I'm wrong, but he said without re-parsing.  The WebArchive 
definitely needs to be reparsed, right?

Christopher White: I don't think what you are asking for exists.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Question about PopupMenuClient

2010-01-07 Thread Adam Treat
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?

2010-01-06 Thread Adam Treat
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?

2009-12-10 Thread Adam Treat
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?

2009-12-10 Thread Adam Treat
On Thursday 10 December 2009 03:16:51 pm Peter Kasting wrote:
 Yeah, I'm not sold.  But oh well.  I think I was getting too irked, when
 really we're just both giving our opinions on how we want the style guide
 to work.  There's nothing wrong with having opinions, or disagreeing.

 Besides, I've been on enough bugs with you to know that your judgement is
 solid.  If it comes down to trusting that judgement, that's not too bad a
 fate.

Thanks Peter :)

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Resolution on switch statement indentation

2009-12-09 Thread Adam Treat
On Wednesday 09 December 2009 10:26:24 am Chris Marrin wrote:
 I saw another patch get rejected today because of switch statement
 indentation. We discussed this last week, and I saw a lot of support
 for my proposal of indenting case labels from their switch. But the
 discussion did not end in resolution. To summarize, here are the
 options mentioned:

 1) Case labels always have the same indentation as their switch
 (today's rule)
...
 Anyway, how do we come to resolution on this?

What is wrong with keeping the current rule?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Resolution on switch statement indentation

2009-12-09 Thread Adam Treat
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

2009-12-09 Thread Adam Treat
On Wednesday 09 December 2009 02:04:07 pm Darin Adler wrote:
 On Dec 9, 2009, at 10:57 AM, Adam Treat wrote:
  Ok, well FWIW I disagree that the current rule makes things hard to read
  and I do not like the idea of changing it. I object on the same grounds
  as the other recent styling change proposals as well as substantively
  that it makes anything easier to read.

 Sorry to keep this topic open — I try to stay out of these — but this one
 is slightly different than the namespace indenting or whatever else was
 recently discussed in that there is still a roughly 50/50 split in existing
 code despite the style guide listing an unambiguous rule.

 -- Darin

Yep, that does distinguish.  That being said, my personal preference would be 
either to keep the current rule and change the code to meet it or even better 
just eliminate the rule altogether since the community hasn't been following 
it anyways.  That speaks negatively to the real world value of the rule IMHO.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Should we ever change style guidelines?

2009-12-09 Thread Adam Treat
On Wednesday 09 December 2009 04:02:07 pm Maciej Stachowiak wrote:
 I have thought over your comments about not changing the style
 guidelines at a whim.

 I think you make a very good point: the most important thing about the
 style guidelines is that there is one way to do things, and that's
 more important than having the very best way. In particular, anyone
 who is looking to change the style guidelines to best reflect their
 personal preferences is thinking about it the wrong way. And making
 lots of changes could lead to useless code thrash. So, your argument
 almost made me back off on the proposed style rule changes.

 However, I don't want to get so set in our ways that we never dare to
 change anything about the style guidelines. One principle that's
 important to the WebKit project is willingness to change things for
 the better, even if there is a short-term cost in terms of disruption.
 We're willing to rename classes and functions, rename files, and break
 internal interfaces if that makes the code better. In the case of the
 style guidelines, how do we balance this way of thinking with the
 desire to avoid thrash and changing on a whim? I think something like
 the following should be our meta-guidelines for when to change the
 style guide:

Good point.

 1) If an issue or a particular case is not addressed in the style rule
 at all, then we should be willing to add a new rule.

I disagree with this.  I think the heavily favored presumption should be 
against adding new rules.  If we discover some supremely annoying 
inconsistency then that is one thing, but it is important to note that *we do 
not need* a rule for every possible different type of style.  I like having a 
consistently styled codebase, but I also like having the flexibility to 
exercise good judgement.  With every new rule to the style guide I fear we 
lose the latter and become ever more pedantic about often trivial issues.

Rather, I'd prefer to think of the style guidelines as just that: guidelines.  
In the end, I believe both patch authors and reviewers should use good common 
sense just like in any other aspect of our codebase.  If for some reason the 
style guidelines are problematic in a particular corner case, then I think we 
should have the flexibility to use our common sense.  I think this already 
occurs, but perhaps it is good to spell out?

I'd like to go back to thinking of the style guidelines as a *guide* for patch 
authors into the common coding style of the community.  What I suspect is 
happening (which concerns me), is the style guidelines being used to work 
around the problems we're encountering scaling the review queue.

If we are to continue on the road of ever more stringent adherence to the 
style strikeguidelines/strikerules, then I think we should exact an ever 
heavier burden on adding to or modifying those rules.

 2) If we failed to fully consider the consequences of a rule when we
 first wrote it down, whether in general or in some particular case,
 then we should consider revising it to address the unanticipated issues.

Sure.

 3) If we have overwhelmingly strong evidence that a particular change
 would aid readability, even though the issue in question had been
 considered before, then we can consider changing. But there should be
 a heavy presumption in favor of the current rule, and if there is not
 consensus on the change, we should lean towards not changing.

Fine with that.

 4) If the code actually follows a different pattern than the formal
 rule, and we see no strong advantage to the rule, we should consider
 changing the rule to match the code.

Or perhaps we get rid of the rule?

 I think in the case of case labels, we have a bit of #2 going on. I
 don't think we considered the possibility of blocks inside the case
 label, or at least when we were creating these rules I don't think we
 were aware that there are some cases where using braces is essential,
 so the solution would be to leave them out. The only reason it's every
 truly needed to use braces is if you declare a variable with a type
 that has a constructor or destructor, and I'm pretty sure I at least
 hadn't thought of this when we made the rule.

switch (type) {
case A:
{
Foo foo;
break;
}
case B:
default:
return;
}

That's what I've been using and I think this passes the current rule.

 In the case of braces around single-line clauses, I think we also
 didn't fully consider the impact when you have a lengthy if chain and
 a mix of single-line and multi-line statements. So I think there too,
 #2 applies. However, we definitely *did* consider if statements with
 no else, and two-clause if/else statements, and decided we were ok
 with the consequences of the rule.

Well, people still disagree whether this is a readability improvement.  And 
while I am sympathetic that it is, I still consider mine to be a subjective 
opinion and therefore not a good enough reason to change the rule. 

Cheers,

Re: [webkit-dev] Should we ever change style guidelines?

2009-12-09 Thread Adam Treat
On Wednesday 09 December 2009 07:03:51 pm Peter Kasting wrote:
 But even what is trivial is a judgement call.  In general people don't
 disagree about issues where they believe disagreement is a waste of time.
...
 And I don't.  Who is right?  More importantly, how will you prevent us from
 starting this debate on a bug?

I won't?  If you as a reviewer consider the indentation of case labels to be a 
non-trivial issue, then exercise your good judgement in patch review and I'll 
trust that as a reviewer you will do a good job.

 It's well-established that (a) not enforcing past rules as well as we're
 doing now and (b) changing rules without changing the whole codebase to
 comply contribute to this.  Existing inconsistency is not evidence that
 inconsistency is fine, or even desirable.

I'm not arguing against consistency.  I'm arguing that there should be a heavy 
burden before we adopt more or modify the existing style guidelines.  And that 
reviewers should have the freedom to interpret the guidelines as guides that 
almost always are correct and should be followed absent a good reason and not 
rules that should be enforced pedantically so sayeth $DIETY.

 Wasting a few dozen comments arguing the same issue with the same people in
 several different bugs is correctly termed a fiasco in my opinion.  By
 contrast the numerous bugs I've seen where authors promptly corrected style
 violations in their patches and reposted them have gone quite smoothly.

Lack of flexibility and/or enforcing the guidelines pedantically can also be a 
problem though.

 And we are continually moving more in the direction of automating and
 streamlining these actions so that patch authors get feedback as quickly
 and consistently as possible and reviewers don't have to bother thinking
 about things like this.  That seems like a good direction to me.

I like the style checker.  That is why I helped write parts of it.  However, I 
still want reviewers to have the flexiblity to think and make judgement calls 
about style issues.  Something that I think was practiced in the past and 
should be continued.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

2009-12-04 Thread Adam Treat
On Thursday 03 December 2009 02:30:17 pm Kenneth Russell wrote:
 In the WebKit WebGL implementation I've frequently encountered the
 case where the else clause in a single if/else is a one-liner, and I
 find it both ugly and error-prone to have to remove its braces. I'd
 really like to be able to use braces on both arms.

 Perhaps existing code could be grandfathered in but new or modified
 code required to conform to the rule Peter proposes.

 -Ken

I'd like to lodge an objection on the grounds that the style guide is a matter 
of subjective opinion and rationally only serves to make our code consistent. 
I do not like changing this style guide as the fashion changes.

However, as Hyatt might note I do not have a personally substantive problem 
with this particular change as I'd actually prefer this if the style guide 
were being made up today.

It seems we keep changing the style guide as fashion changes.  It is meant to 
ensure consistency and readability.  This is a purely subjective change and I 
think unwarranted.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] TARGET_OS_EMBEDDED

2009-12-04 Thread Adam Treat
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

2009-12-04 Thread Adam Treat
On Friday 04 December 2009 12:17:03 pm Jeremy Orlow wrote:
 I'm not necessarily disagreeing with your conclusion, but I have to ask:
 can you think of an example of a style change that isn't subjective and/or
 something that can change as the fashion (or, more likely, the developers
 working on the project) changes?  Even stuff like the namespace change
 really depends on your development style (to determine whether or not you
 care about those 4 extra spaces wasted).

Very little of it is not subjective.  The main thing the style guide gives us 
is consistency.  And that I am fully supportive of.  But a lot of it is merely 
taste.  The compiler excepts both.  Two developers fully informed and both of 
great technical prowess can reasonably disagree on almost all points of the 
style guide.  That meets my definition of subjective for this purpose.

Regarding the namespace change, I objected to that change too (and for the 
very same reasons) if you look through the archives.

I don't think we should be changing the style guide for anything besides 
clarifications of currently unwritten rules.  No matter how the fashion may 
change or how developers may change.  Changing the rules throws consistency 
out the window which is, I believe, the greatest benefit of having a style 
guide.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

2009-12-04 Thread Adam Treat
On Friday 04 December 2009 04:22:57 pm Dirk Pranke wrote:
 On Fri, Dec 4, 2009 at 9:39 AM, Adam Treat tr...@kde.org wrote:
  I don't think we should be changing the style guide for anything besides
  clarifications of currently unwritten rules.  No matter how the fashion
  may change or how developers may change.  Changing the rules throws
  consistency out the window which is, I believe, the greatest benefit of
  having a style guide.

 While I agree with your points re: subjectivity, and I agree that any
 two competent programmers can disagree on any
 points, it is also true that some practices can be shown to be more
 reliable, maintainable, or readable, and those
 practices do change over time, partially as technology changes and
 partially because this is a social process.

You can't show that any practice is more readable than another because it is 
subjective as you admit.  People can argue over the readability of different 
style options and come to different conclusions much as has been done in this 
long thread.

As for technology changing, what do you think drives this particular style 
change other than the subjective opinions of a set of developers?

 Dunno if this changes any of your thinking or not ...

Sorry, not really.

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] virtual functions in ChromeClient and other clients

2009-10-22 Thread Adam Treat
If i remember correctly another strike against this is SVG.  I believe that 
SVG uses a different set of empty clients.  This would make that more difficult?

On Thursday 22 October 2009 03:29:28 pm Yong Li wrote:
 Oops, even m_page is a data member.

 Hm... I need to think more about it.

 -Yong

 - Original Message -
 From: Yong Li yong...@torchmobile.com
 To: Adam Barth aba...@webkit.org
 Cc: WebKit Development webkit-dev@lists.webkit.org
 Sent: Thursday, October 22, 2009 3:28 PM
 Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
 clients

  Usually, those clients call WebPage or WebFrame to access the data
  members.
 
  For example:
 
  ChromeClient::doSomething()
  {
 m_page-doSomething();
  }
 
  -Yong
 
  - Original Message -
  From: Adam Barth aba...@webkit.org
  To: Yong Li yong...@torchmobile.com
  Cc: WebKit Development webkit-dev@lists.webkit.org
  Sent: Thursday, October 22, 2009 3:25 PM
  Subject: Re: [webkit-dev] virtual functions in ChromeClient and other
  clients
 
 
  How would the class implementing ChromeClient hold any data members?
  I guess we could use pimpl...
 
  Adam
 
  On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
  Hi All,
 
  ChromeClient and other clients defined in webkit are using a lot of
  WebCore
  objects. So it seems impossible to provide a ChromeClient from another
  binary other than webkit itself. In other words, ChromeClient is almost
  always implemented in a static lib that's linked with WebCore together.
 
  If that's true, why do we need those virtual functions? One reason
  might
  be for this case:
 
  class WebPage: public ChromeClient, public EditorClient, public . {
  };
 
  But I see most ports implement these clients with single classes. If we
  can
  make this mandatory, then we can remove these virtual words from these
  client interface, and then the compilers could make those functions
  inline
  whenever suitable. I guess this could boost performance a little bit.
 
  Best regards,
 
  Yong Li
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Calling All Reviewers

2009-08-07 Thread Adam Treat
On Friday 07 August 2009 05:51:57 pm Eric Seidel wrote:
 We also definitely need to fix our tools to make it impossible to post a
 patch w/o a ChangeLog, and impossible to post a patch that doesn't pass
 check-webkit-style.

This is a bad idea.  check-webkit-style still has false positives and is very 
new.  It has been designed to never be free of false positives in fact.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] freeing static variables

2009-07-30 Thread Adam Treat
On Thursday 30 July 2009 02:55:18 am Zoltan Herczeg wrote:
 Hi,

 any thoughts on this? I hope my qestion was clear :) I would like to pack
 the static declarations into wrapper classes, so we can add platform
 and/or compilation mode (debug/release) dependent functionality to all
 static variables (i.e: freeing them on exit).

 Zoltan

I've tried this before and it didn't work out so well.  The order in which you 
free them becomes very important and error prone.  

And, of course, whatever solution you make has to be optional and easy to 
maintain as the default policy in WebKit is to not care - by design - about 
cleaning up after static globals on exit as that is left to the OS.

Another strategy for the embedded case where you want to free everything on 
exit is to create a custom memory handler that will do this for you.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] JavaScript code that access the DOM tree

2009-07-30 Thread Adam Treat
On Thursday 30 July 2009 08:57:53 am Luka Napotnik wrote:
 Hello.

 I'm searching for the JavaScriptCore code that can access the DOM
 tree. An example would be JavaScript code that changes the image
 source of an IMG dom element. Any good pointer on this subject?

 Greets,
 Luka

This is not an appropriate topic for this mailing list as webkit-dev is for 
discussion related to the development of the WebKit rendering engine.  It is 
not for answering generic JavaScript questions.  Thanks!

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Webkit Build Error on Windows (Urgent)

2009-07-22 Thread Adam Treat
This thread is not appropriate for webkit-dev.  There is a new mailing list - 
webkit-help - which has been setup for threads of this nature.  Please use the 
other mailing list and keep webkit-dev focused on webkit development.

http://lists.webkit.org/mailman/listinfo.cgi/webkit-help

Cheers,
Adam

On Wednesday 22 July 2009 07:45:52 am mjbh wrote:
 Hi

 Thanx Niilesh.  Cannot find file: \usr\bin\WebKit\WebKit.pro Error
 occurred due to qmake not able
 understand the cygwin style path. I have modified webkitdir.pm to generate
 windows style path.
 then I got the below message.

 bash-3.2$ WebKitTools/Scripts/build-webkit --cairo-win32 --debug
 unix DIR: '/usr/bin/WebKit'
 WIN DIR: 'D:\cygwin\bin\WebKit'
 Qmakebin Value: 'qmake'
 buildArgs Value: '-r
 OUTPUT_DIR=D:\cygwin\bin\WebKit\WebKitBuild/Debug_Cairo D:\
 cygwin\bin\WebKit\WebKit.pro CONFIG-=release CONFIG+=debug'
 Calling 'qmake -r OUTPUT_DIR=D:\cygwin\bin\WebKit\WebKitBuild/Debug_Cairo
 D:\cyg
 win\bin\WebKit\WebKit.pro CONFIG-=release CONFIG+=debug' in
 D:\cygwin\bin\WebKit
 \WebKitBuild/Debug_Cairo

 Reading D:/cygwin/bin/WebKit/WebCore/WebCore.pro
 [D:/cygwin/bin/WebKit/WebKitBui
 ld/Debug_Cairo//WebCore]
 c:\Qt\4.4.3\bin\rcc.exe: File does not exist
 '..\..\..\WebCore\inspector\front-e
 nd\WebKit.qrc'
 c:\Qt\4.4.3\bin\rcc.exe: File does not exist '..\..\..\WebCore\WebCore.qrc'
 c:\Qt\4.4.3\bin\rcc.exe: File does not exist
 '..\..\..\WebCore\inspector\front-e
 nd\WebKit.qrc'
 c:\Qt\4.4.3\bin\rcc.exe: File does not exist '..\..\..\WebCore\WebCore.qrc'
 Reading D:/cygwin/bin/WebKit/JavaScriptCore/jsc.pro
 [D:/cygwin/bin/WebKit/WebKit
 Build/Debug_Cairo//JavaScriptCore]
 Reading D:/cygwin/bin/WebKit/WebKit/qt/QtLauncher/QtLauncher.pro
 [D:/cygwin/bin/
 WebKit/WebKitBuild/Debug_Cairo//WebKit/qt/QtLauncher]
 Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/tests.pro
 [D:/cygwin/bin/WebKit/Web
 KitBuild/Debug_Cairo//WebKit/qt/tests]
  Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebframe/qwebframe.pro
 [D:/cygwin
 /bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebframe]
  Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebpage/qwebpage.pro
 [D:/cygwin/b
 in/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebpage]
  Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebelement/qwebelement.pro
 [D:/cy
 gwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebelement]
  Reading
 D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebhistoryinterface/qwebhistoryin
 terface.pro
 [D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebh
 istoryinterface]
  Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebview/qwebview.pro
 [D:/cygwin/b
 in/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebview]
  Reading D:/cygwin/bin/WebKit/WebKit/qt/tests/qwebhistory/qwebhistory.pro
 [D:/cy
 gwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//qwebhistory]
  Reading
 D:/cygwin/bin/WebKit/WebKit/qt/tests/benchmarks/painting/tst_painting.p
 ro
 [D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//benchmarks/p
ai nting]
  Reading
 D:/cygwin/bin/WebKit/WebKit/qt/tests/benchmarks/loading/tst_loading.pro

 [D:/cygwin/bin/WebKit/WebKitBuild/Debug_Cairo/WebKit/qt/tests//benchmarks/l
oadi ng]

 ===
  WebKit is now built. To run QtLauncher with this newly-built
  code, use the WebKitTools/Scripts/run-launcher script.

  NOTE: WebKit has been built with SVG support enabled.
  QtLauncher will have SVG viewing capabilities.
  Your build supports the following (optional) SVG features:
   * Basic SVG animation.
   * SVG as image.
   * SVG fonts.
   * SVG foreign object.
   * SVG use support.
 ===

 but I when invoke the run-launcher, I am getting the below error:

 bash-3.2$ WebKitTools/Scripts/run-launcher
 Starting webkit launcher, running against the built WebKit in
 D:/cygwin/bin/WebK
 it/WebKitBuild/Release/lib...
 Can't exec D:/cygwin/bin/WebKit/WebKitBuild/Release/bin/QtLauncher: No
 such fi
 le or directory at WebKitTools/Scripts/run-launcher line 68.
 Died at WebKitTools/Scripts/run-launcher line 68.
 bash-3.2$

 If I tried to build through the Qt command prompt using nmake, I am getting
 the below Error:
 ( I am using Qt 4.4.3 )

 D:\cygwin\bin\WebKit\WebKitBuild\Debug_Cairo\WebCorenmake -f
 Makefile.Debug

 Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
 Copyright (C) Microsoft Corporation.  All rights reserved.

 perl D:/cygwin/bin/WebKit/JavaScriptCore/pcre/dftables
 generated\debug\c
 hartables.c --preprocessor=cl /E
 Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for
 80x86
 Copyright (C) Microsoft Corporation.  All rights reserved.

 cl : Command line warning D9002 : ignoring unknown option
 '/tmp/dftables-FjM3m7_
 1.in'
 cl : Command line error D8003 : missing source filename
 Use of uninitialized value $pcre_internal{tables_length} in printf at
 D:/cygwi
 n/bin/WebKit/JavaScriptCore/pcre/dftables 

Re: [webkit-dev] QWebElement not found in Qt 4.5.2

2009-07-22 Thread Adam Treat
This thread is not appropriate for webkit-dev.  There is a new mailing list - 
webkit-help - which has been setup for threads of this nature.  Please use the 
other mailing list and keep webkit-dev focused on webkit development.

http://lists.webkit.org/mailman/listinfo.cgi/webkit-help

Cheers,
Adam

On Wednesday 22 July 2009 03:20:14 am Ashok N N wrote:
 Hi,
   I am compiling QtWebKit for the first time with Qt 4.5.2. At the very end
 of compilation, I see linking errors for QWebElement (among others). And
 searching around I did not find the header file qwebelement.h included in
 Qt4.5.2. And searching online I found that QWebElement is released in Qt
 4.6 (http://chaos.troll.no/~tavestbo/webkit/domapi/qwebelement.html).

   I was wondering how the current code is compilable in this situation? Is
 there a flag that can be set to disable this part of the code? The actual
 changes to WebKit were done in rev 42238.

 thanks,
 ashok

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Compiling WebKit (any flavor) for ARM

2009-07-22 Thread Adam Treat
This thread is not appropriate for webkit-dev.  There is a new mailing list - 
webkit-help - which has been setup for threads of this nature.  Please use the 
other mailing list and keep webkit-dev focused on webkit development.

http://lists.webkit.org/mailman/listinfo.cgi/webkit-help

Cheers,
Adam

On Wednesday 22 July 2009 06:55:24 am Ashok N N wrote:
 Hi,
   I've gone through some of the posts related to compiling WebKit for ARM
 but found them to be conflicting. One of them says that just setting the
 QMAKESPEC should work fine while others mentioned compiling the tool chain
 for cross compilation etc. Can somebody help me with any instructions for
 compiling WebKit for ARM? Also is there a guide to the build system being
 used? I see that build-webkit tries to identify the architecture etc and
 invoke specific build functions like buildQMakeQtProject() etc.

 thanks,
 ashok

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] loading webpage on webkit_gtk has error of font

2009-07-22 Thread Adam Treat
If you believe you've found a bug the correct thing to do is to post a bug on 
bugs.webkit.org.  See here:

http://webkit.org/quality/reporting.html

Otherwise, generic queries of this form should probably be asked on the 
webkit-help mailing list:

http://lists.webkit.org/mailman/listinfo.cgi/webkit-help

Thanks,
Adam

On Wednesday 22 July 2009 12:40:47 am deuxliquid wrote:
 Hi all,
 I built webkit on gtk. Then run Gtklauncher but the font of webpage is so
 blur. Any one gives me some advices?
 Thank you in advance!



   Vui vẻ chat thêm trên nhiều blog và website. Hãy thử dùng ứng dụng
 Pingbox online. http://vn.messenger.yahoo.com/pingbox/

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] TeaShark

2009-07-22 Thread Adam Treat
This thread is not appropriate for webkit-dev and indeed, not appropriate for 
any webkit list in general.  TeaShark is only tangentially related to WebKit 
and the WebKit developers have no special knowledge of this third party 
product.  For queries about TeaShark or any client application that happens to 
use WebKit: you should ask the client authors directly.

Cheers,
Adam

On Tuesday 21 July 2009 11:09:46 pm Hieu Le Trung wrote:
 Hi,



 According to the following archive
 http://lists.macosforge.org/pipermail/webkit-dev/2007-September/002427.h
 tml

 I wonder if there is source code release of TeaShark or not.



 Thanks,

 -Hieu

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Changes to prepare-ChangeLog

2009-07-15 Thread Adam Treat
On Wednesday 15 July 2009 03:59:53 pm John Abd-El-Malek wrote:
 I don't want to open the can of worms that is git vs other source control
 systems.  However given that the instructions for developing WebKit are for
 svn and there already exists svn-apply/unapply scripts, I think there are
 enough WebKit devs using svn that warrant improving this process flow.

I think Maciej recently posted a very good action plan for how we can improve 
the contribution process.  In that action plan it was suggested that certain 
things can be done first (Phase #1 and Phase #2) and then for things that might 
involve a look at other revision control systems (Phase #3) we can look at 
those after.

This would seem to fall into Phase #3.

I think Maciej's was a good action plan.

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Patch process - let's make it better

2009-07-15 Thread Adam Treat
On Friday 10 July 2009 06:55:59 pm Maciej Stachowiak wrote:
 * Phase 1 *

 A) Make it really easy to submit a patch. Eric's bugzilla-tool is
 close to being there. I'm going to help him refine this tool to the
 point that submitting a patch has only one step - a single command
 will make the patch, file a bug if needed, attach the patch to the
 bug, and flag it for review.

 B) Make it really easy to commit a patch. Again, I think bugzilla-tool
 is the right path to achieving this.

 C) Improve the way we get attention from reviewers. I think we should
 do three things here:
  C.1) Split review queues, based on our emerging [Bracket]
 convention for patches needing specialized review. If we find more
 areas of specialty besides ports, we can add new [Bracket] tags.
  C.2) Improve the quality of emails sent
  C.3) Highlight in a special way patches that have been waiting
 for review longer that some minimum period (a week?). These could be
 highlighted visually in the review queue, and maybe would send extra
 review request emails automatically.

Speaking of your action plan... I've had a look at C.3 and was going to try to 
modify the bugzilla tools to highlight as you suggested.  But after looking at 
the review queue over the last few days I'm not sure it is necessary or that 
it would help to fix the problem.

http://www.webkit.org/pending-review

The page above already lists the review queue sorted by date.  Over the last 
few days the queue has numbered in the 100's.  A significant fraction (50%+) 
are older than a week.  I could highlight them, but if it is already ordered 
by date and the highlight will encompass more than half the queue... what's 
the point?

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Review Queue needs some more attention

2009-07-14 Thread Adam Treat
We have close to 100 patches that need attention in the review queue.

http://www.webkit.org/pending-review

I count five or six for the Qt port.  Eight for the GTK port.  Several for the 
Haiku port where a decision should probably be made.  And several for the ARM 
Jit work and the custom memory allocator.  I'm going to try and go through 
what I can, but if any other reviewers have some time...

Cheers,
Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Fwd: Review queue needs love

2009-06-19 Thread Adam Treat
On Friday 19 June 2009 02:05:23 pm Drew Wilson wrote:
 I was more specifically wondering if there was something about this patch
 that made it not show up on the list Eric provided below. My concern is
 because the bugfix came from a google.com address, it might have been
 getting lumped in with the oh, must be Yet Another Chromium Patch so I
 won't worry about it list, which if true has troubling implications given
 that there are an increasing number of Googlers that are making
 contributions to WebKit that have nothing to do with Chromium.

Your concern seems rather odd given that Eric is a Google employee.  Moreover, 
the link that started this thread was given by Maciej and your bug is indeed 
found in that list:

https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F

Cheers,
Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Review queue needs love

2009-06-18 Thread Adam Treat
On Thursday 18 June 2009 05:39:04 pm Oliver Hunt wrote:
 I reviewed quite a few last night as well.  At the moment there appear
 to be a large number of chromium, gtk, and qt specific patches up for
 review -- it would be great if reviewers for those ports went through
 them all :D

I went through all the Qt ones today after Maciej made his request.  I think 
there is only one outstanding Qt related one at the moment...

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] MIPS port problem - cti_op_put_by_id slow case problem

2009-06-17 Thread Adam Treat
On Wednesday 17 June 2009 05:12:41 pm Jeremy Orlow wrote:
 If so, why not just develop in the open?

I'm just guessing here... but probably for the same rough combination of 
reasons that Google didn't develop Chromium in the open before it was publicly 
announced... or for the same rough combination of reasons that Apple didn't 
develop the new ARM JIT support in the open before it was publicly announced. 

Same goes for lots of initial features or ports that the various companies 
involved in WebKit have eventually contributed.

It would be nice if every change that is envisioned will eventually be merged 
back into the official repository to be developed in the open, but that is just 
not realistic given the commercial world we live in.

That said, if a company is determined to initially develop such things behind 
a closed door, then they should have no expectation that the greater community 
will help with any obfuscated technical questions given that we aren't privy 
to what's going on behind that closed door.  At least that's how I see it.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] [Bulk] Re: MIPS port problem - cti_op_put_by_id slow case problem

2009-06-17 Thread Adam Treat
On Wednesday 17 June 2009 06:24:32 pm Adam Treat wrote:
 It would be nice if every change that is envisioned will eventually be
 merged back into the official repository to be developed in the open, but
 that is just not realistic given the commercial world we live in.

I would also add that in my personal opinion and experience the business 
reasons often cited for hiding behind a closed door during the initial 
development of a new feature are dubious at best and real hindrances (even 
crippling hindrances) at worst.

Too often I think companies involved with Open Source choose to develop some 
new feature behind a closed door almost as an a priori default position.  In 
my experience this often leads to a lot of headaches when interacting with the 
community much as we are starting to see here.  Moveover, the actual business 
value of such initial closed development is often just assumed.  

I think it would behoove companies that are involved with WebKit to rethink 
these initial assumptions and actually make sure that whatever PR value they 
get from announcing there brand new swanky feature that has been developed 
behind a closed door, is actually greater than the negative repercussions that 
come from doing so.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] opera unite api: extensions to add web server capability to browser engines

2009-06-16 Thread Adam Treat
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

2009-03-05 Thread Adam Treat
Has there been any progress with this effort?  Specifically, I'm wondering if 
there is a bug on bugs.webkit.org that we are using to track this task.

Cheers,
Adam

On Friday 14 November 2008 5:53:56 pm Adam Barth wrote:
 Ok.  I'll file a bug report at http://bugreport.apple.com/ with
 several things that should be easy to change.  In parallel, we can
 investigate moving the sniffing algorithm to WebKit.

 Thanks,
 Adam

 On Fri, Nov 14, 2008 at 2:40 PM, Darin Adler da...@apple.com wrote:
  On Nov 14, 2008, at 2:32 PM, Adam Barth wrote:
  One disadvantage of moving the algorithm is that we might make some
  unintended changes.
 
  Another disadvantage is that any other Mac OS X libraries or applications
  that rely on the sniffing done by CFNetwork will no longer get the same
  results as WebKit clients.
 
  Also, I don't think we've established yet if we can turn off the sniffing
  in CFNetwork and keep the other desirable CFNetwork features working.
  There are a number of closely related features, such as the one that
  determines the suggested filename for a download.
 
  I think the concept of moving the sniffing into WebKit is great if we can
  execute it successfully. I'm worried that it may be difficult to do that
  in the Mac OS X version and the Windows version used by Safari.
 
 -- Darin

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Questions about expected test results

2009-02-25 Thread Adam Treat
On Wednesday 25 February 2009 1:41:50 pm Sami Kukkonen wrote:
 Being new to WebKit this is confusing so I have a couple of questions:

 1.Why doesn't trunk-qt-linux-release run layout tests? Is it known
 and expected that hundreds of them will fail?

The buildbot for the QtWebKit port does not currently execute layout tests.  
This is a known issue and is being worked on.  Torch Mobile plans on hosting a 
new buildbot for the QtWebKit port that will have the layout tests turned on.

It is known that lots of tests do not currently pass.  That is a result of 
some bitrot in the implementation of DRT for the Qt port, but it is being 
worked on.  Lots of the failures are a result of problems with DRT rather than 
the Qt port itself.

 2.Why does trunk-qt-linux-release report jscore-test as passed
 when results file contains 50 failures?

Again, the current Qt buildbot has issues, but a plan is in place to fix this.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Questions about expected test results

2009-02-25 Thread Adam Treat
On Wednesday 25 February 2009 3:12:14 pm Sami Kukkonen wrote:
 OK, thanks. I'll ignore the failures for now and I can also use GTK as
 my reference build since it seems to pass almost all of the layout
 tests.

Actually the Qt port passes more tests right now (not by much) than the GTK 
port.  Both are skipping an enormous amount of tests via the Skipped files.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Turning off rendering in WebKit

2009-01-14 Thread Adam Treat
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

2009-01-12 Thread Adam Treat
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

2008-11-24 Thread Adam Treat
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...

2008-06-20 Thread Adam Treat
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

2008-06-08 Thread Adam Treat
Hi Nina,

If I understand correctly, you are loading a page in QtWebKit and then using 
the QWebFrame::toHtml() method to retrieve the actual markup which is missing 
closing tags.  

If the html is missing *all* closing tags then this sounds like a bug in the 
toHtml method.  If the html is missing only *some* closing tags then this is 
not remarkable as of course the html does not need to be well formed for 
webkit to display it.

This is hard to know since we have no details about what page you are 
trying to load and or any other details that normally go into a bug report.  

If you believe you've discovered a bug then by all means fill out a bug on 
bugs.webkit.org. This website is not the right place for these kinds of bug 
reports.

Adam

On Sunday 08 June 2008, nina wrote:
 Thanks David  for response,

 I want to load an html page with webkit then contruct his dom tree, I
 use Qt4.4 which integrate Webkit.

 QWebView v;
 QString frameText = v . page() - mainFrame() - toHtml();  Loading the
 page


 void Charger::Dom-tree(QDomNode node) Function which construct dom
 tree for html page loaded
 {

   if  (node.hasChildNodes ())
 {
listnode = node.childNodes();
for(i=0; ilistnode.length() ; i++) {
   e = node.toElement();
  
 Dom-tree(listnode.item(i)); }
 }



 }


 This failed, because there is some missing closings tags !!!
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Async IconDatabase and reading icons from disk on startup

2008-05-11 Thread Adam Treat
Hi,

I do not understand how a client application should use IconDatabase to 
display icons given its async nature.

It would seem that a client application should call 
iconDatabase()-iconForPageURL() when it needs to display a particular icon 
on startup.  However, the way IconDatabase is written it appears that the 
client application would need to call this method *twice* before being able 
to retrieve the actual icon from disk.

The only time image data is actually read from disk is in 
IconDatabase::readFromDatabase() and the only icons it reads are marked by 
the set of icons in m_iconsPendingReading.  However, the only time 
IconRecord's are actually *added* to m_iconsPendingReading is in 
IconDatabase::iconForPageURL()...??

So, it appears a client application has to call IconDatabase::iconForPageURL 
twice before being able to actually retrieve the icon image data.  Once for 
scheduling it to be read from disk and a second time to actually retrieve 
it??!!

What am I missing?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Async IconDatabase and reading icons from disk on startup

2008-05-11 Thread Adam Treat
On Sunday 11 May 2008, Darin Adler wrote:
 On May 11, 2008, at 5:08 PM, Adam Treat wrote:
  It would seem that a client application should call iconDatabase()-
 
  iconForPageURL() when it needs to display a particular icon on
 
  startup. However, the way IconDatabase is written it appears that
  the client application would need to call this method *twice* before
  being able to retrieve the actual icon from disk.

 The client should call retainIconForPageURL as soon as it discovers it
 will need the icon for a particular URL.

 Later, dispatchDidAddIconForPageURL will be called on the client when
 that icon is available.

How is it actually read from disk then?  Looking at the code... the only time 
it is actually read from disk is in IconDatabase::readFromDatabase and even 
then it only reads in icons that are flagged in m_iconsPendingReading.  And 
when grepping the code the only time I see that an icon is inserted into 
m_iconsPendingReading is when iconForPageUrl is called??

 At that point, the client can call iconForPageURL to get the icon.

 If the icon is no longer needed, the client should call
 releaseIconForPageURL.

  -- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Async IconDatabase and reading icons from disk on startup

2008-05-11 Thread Adam Treat
On Sunday 11 May 2008, Darin Adler wrote:
 Or you could do as Safari does and call iconForPageURL twice; the
 first time it's display the icon if we already have it but the
 second time it's I heard you have a new icon, lets display the new
 icon we now know about.

 It would probably be cleaner if triggering the load of the icon was
 completely separate from actually fetching the icon data.

Right.  I would suggest that iconForPageURL should always return 0 unless and 
until readIconForPageURLFromDisk is called which actually triggers the load. 

It should be noted that *nothing* currently uses 
readIconForPageURLFromDisk() ;)

I guess I just couldn't believe that Safari calls iconForPageURL twice.  It is 
very unclear API.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] QWebNetworkManager triggering a memleak in Qt

2008-01-03 Thread Adam Treat
Hi,

I've checked and this appears to be the case in both Qt 4.3.2 and Qt 4.4 
snapshot...

==7746== 4 bytes in 1 blocks are definitely lost in loss record 5 of 507
==7746==at 0x4022765: malloc (vg_replace_malloc.c:149)
==7746==by 0x5CB16C4: qMalloc(unsigned) (qglobal.cpp:1964)
==7746==by 0x5D7E43C: queuedConnectionTypes(QListQByteArray const) 
(qobject.cpp:67)
==7746==by 0x5D82E5A: QObject::connect(QObject const*, char const*, 
QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2567)
==7746==by 0x80513D2: QObject::connect(QObject const*, char const*, char 
const*, Qt::ConnectionType) const (qobject.h:291)
==7746==by 0x4B38C6C: QWebNetworkManager::QWebNetworkManager() 
(qwebnetworkinterface.cpp:432)
==7746==by 0x4B38D5F: QWebNetworkInterface::QWebNetworkInterface(QObject*) 
(qwebnetworkinterface.cpp:906)
==7746==by 0x4B38DE6: QWebNetworkInterface::defaultInterface() 
(qwebnetworkinterface.cpp:890)
==7746==by 0x4B38E36: QWebNetworkManager::self() 
(qwebnetworkinterface.cpp:438)
==7746==by 0x4AFAFD7: WebCore::ResourceHandle::start(WebCore::Frame*) 
(ResourceHandleQt.cpp:134)
==7746==by 0x49E9280: 
WebCore::ResourceHandle::create(WebCore::ResourceRequest const, 
WebCore::ResourceHandleClient*, WebCore::Frame*, bool, bool, bool) 
(ResourceHandle.cpp:53)
==7746==by 0x4970831: 
WebCore::MainResourceLoader::loadNow(WebCore::ResourceRequest) 
(MainResourceLoader.cpp:377)

QObject is allocating memory for this queued connection that is apparently 
never freed.

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Webkit-QT and DOM

2007-09-15 Thread Adam Treat
On Saturday 15 September 2007, william lee wrote:
 And also the API or signal to handle before navigate to somewhere.
 This is really useful, to check something before navigate. I can't find it.

It is in QWebPage:

virtual NavigationRequestResponse navigationRequested(
QWebFrame *frame, 
const QWebNetworkRequest request, 
NavigationType type);

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Webkit-QT and DOM

2007-09-14 Thread Adam Treat
On Friday 14 September 2007, [EMAIL PROTECTED] wrote:
 Hello,

 I am using Webkit-QT under Windows, and I need to access to the DOM tree.
 Anyone has an idea on how to do that? Is there some plan to add it to the
 Webkit-QT interface?

Funny.  We have been discussing such an API recently, but it is not done yet.  
For now we have no API for accessing the DOM, but that is likely to change 
soon.

Cheers,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit and Konqueror

2007-09-14 Thread Adam Treat
On Friday 14 September 2007, Andre-John Mas wrote:
 Hi,

 Does anyone know whether WebKitQT has advanced far enough for us
 to start seeing an alpha build of Konqueror using WebKit?

Sure.  Just install the WebKitPart in playground and you'll see Konqueror 
render with QtWebKit.

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit and Konqueror

2007-09-14 Thread Adam Treat
On Friday 14 September 2007, Mike Hommey wrote:
 On Fri, Sep 14, 2007 at 11:21:39AM -0400, Adam Treat [EMAIL PROTECTED] 
 wrote:
  On Friday 14 September 2007, Andre-John Mas wrote:
   Hi,
  
   Does anyone know whether WebKitQT has advanced far enough for us
   to start seeing an alpha build of Konqueror using WebKit?
 
  Sure.  Just install the WebKitPart in playground and you'll see Konqueror
  render with QtWebKit.

 BTW, is the WebKitPart living under WebKitQt in webkit svn up to date
 and buildable ?

No, I believe the one living in KDE's playground is the correct one.  I 
imagine the one living in webkit svn is scheduled for removal...

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKitQt build issue: pthread.h

2007-09-13 Thread Adam Treat
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

2007-08-28 Thread Adam Treat
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

2007-07-18 Thread Adam Treat
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: Fw: Re: Re: [webkit-dev] Why QtLauncher doesn't load pages from internet ?

2007-07-09 Thread Adam Treat
On Monday 09 July 2007, vic burka wrote:
 -Original Message-
 From: vic burka [EMAIL PROTECTED]
 To: Adam Treat [EMAIL PROTECTED]
 Date: Mon, 09 Jul 2007 18:31:47 +0400
 Subject: Re: Re: [webkit-dev] Why QtLauncher doesn't load pages from
 internet ?

  I'm using gperf 3.0.3 - I built it from source.

GNU gperf 3.0.2 here.

Make sure that qmake can find it!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Error when building QT port on Linux

2007-06-27 Thread Adam Treat
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

2007-05-21 Thread Adam Treat
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

2007-05-20 Thread Adam Treat
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

2007-04-16 Thread Adam Treat
On Monday 16 April 2007, Sebastien Le Faou wrote:
 Hi everybody,

 I want to build Webkit with Qt on Windows.

Building WebKit with Qt on Windows is not supported at this moment.  The 
WebKit Qt developers have been talking about a plan to support this in the 
future, but it remains a task for another day.

Cheers,

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] how to build Webkit with qt-4.2.3 on Windows

2007-04-16 Thread Adam Treat
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