Re: [webkit-dev] Re: Qt's default webkit user agent

[Lars Knoll]

On Tuesday 12 February 2008, Alp Toker wrote:
> (It's disappointing to see the growing number of WebCore changes in Qt's
> git tree that could benefit the whole project. Are you planning to
> submit these changes for review?)

All of our changes are supposed to go into trunk. This is not always happening 
immediately unfortunately, but we currently have merged all changes until two 
weeks ago into trunk. So saying the number of changes in our tree is growing 
is IMO not really correcy. We're currently trying to get our Qt 4.4 beta out, 
and are therefore a bit slow with merging and submitting our changes.

But one large change we did (fixing a crash with navigator.plugins and 
autogenerating the bindings) is now hanging in the review queue for almost 4 
weeks. We currently can't afford to wait that long for some fixes to go in. 
Most of us can't hang our on IRC late every evening neither which seems to be 
often a requirement to push things forward.

As I said earlier, we don't like working outside svn, but with having a 
deadline to release a product and with WebKit trunk currently moving ahead 
and implementing new features we didn't really have a choice. 

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

Re: [webkit-dev] I hope I'm posting this in the right place - QtWebkit from git (Qt)

[Lars Knoll]

On Thursday 10 January 2008, Mark Rowe wrote:
> On 10/01/2008, at 16:58, Chris Fuenty wrote:
> > Using Qt's Git repo, Is this able to be successfully compiled on
> > Win32?  I'm running into a few issues, but I can post them after I
> > get conformation that this can be compiled on win32, or if it's
> > targeting Linux at this current time (with the whole KDE4 ordeal).
> > If I'm posting this in the wrong list, is there anybody who can lead
> > me to the right list?
>
> I have no idea of the state of the Windows support in any non-
> webkit.org repositories, but the Qt support in SVN currently builds
> fine on Windows.  See
> 
>  > for information about how to build, and
>  >   > current status of the build.

The qtwebkit branch in git should build just fine on Windows. 

Best regards,
Lars
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New open committer and reviewer policy

[Lars Knoll]

On Saturday 01 December 2007 01:50:04 Maciej Stachowiak wrote:
> See announcement here:
> http://webkit.org/blog/146/new-open-committer-and-reviewer-policy/ And
> document here: http://webkit.org/coding/commit-review-policy.html
>
> We'll try to get mailing lists for reviewers and committers set up as
> fast as possible and would like to use this community-driven policy to
> choose all future committers and reviewers.

Wow! This is great news :)

Thanks a lot!
Lars
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Re: Comments on ProjectVision document

[Lars Knoll]

On Thursday 29 November 2007, Maciej Stachowiak wrote:
> On Nov 25, 2007, at 12:34 PM, Lars Knoll wrote:
> > I would prefer a discussion on the mailing list. I think it's
> > important that
> > everyone contributing to the project can state it's opinion and hear
> > all
> > arguments.
>
> Sounds good to me.
>
> Here's some parts I can comment on briefly:
> > Commit and review rights
>
> I agree that we should have a fair and open policy on commit and
> review rights. Notwithstanding Alp's remarks that Apple has been
> reasonable in administering this, I think open source projects thrive
> on openness. I'm hoping we can improve the situation soon. One thing
> we are working on now is putting together a complete list of current
> committers anr reviewers to publish on the wiki.
>
> > Project planning should become more transparent. The mailing list
> > should be used for larger discussions or decisions that affect all
> > platforms, to give all involved parties a chance to comment.
>
> I agree that large changes should be discussed on the mailing list.
> I'll try to post information about Apple's near to mid term feature,
> performance and architecture goals for the project to inform everyone
> and for discussion.

Thanks. I think your mail there is a good start :)

> > * Platforms need to have an idea of when to expect the next stable
> > WebKit version.
> > * Releases should be time based.
> > * Release schedules and a (loosely defined) roadmap should be
> > discussed and agreed upon inside the community.
>
> These requests are pretty challenging to meet. We have a few
> conflicting constraints:
>
> 1) Currently more than half of development, and probably a bigger
> proportion of core cross-platform work, is done by Apple engineers.
> Also, most dogfood testing is currently done on the Mac platform via
> nightlies. That means it is strongly advantageous to be relatively in
> sync with Apple's release cycles; otherwise we'll be forced to do
> stabilization and feature development based on Apple product cycle in
> a vendor branch instead of on trunk. I think that would be a bad thing
> for the project as a whole, since Apple's Safari releases would end up
> out of sync with project releases.
>
> 2) Apple's general policy is to not comment on future product
> releases, either dates or features. For the WebKit open source
> project, it is obviously important to have shared discussion of the
> overall roadmap. So we finesse this by discussing plans and roadmap in
> general, and not details of the timetable.

I do agree that it makes sense to sync webkit releases with Safari releases. 

Not having a date for these is however a large challenge for others. If we 
don't have an idea, we can't really plan which WebKit version to base 
ourselves upon for Qt 4.5. This in turn implies that we can't tell our 
customers or the open source community which new features WebKit in Qt 4.5 
will contain.

> 3) As more organizations and companies ship WebKit-based products,
> there will be more different vendor release cycles to consider.
>
> I can tell you that Apple's drive for stable WebKit releases is likely
> to become more frequent now that Safari 3 is out, and we are unlikely
> to see a gap as big as the Safari 2 --> Safari 3 gap for the
> foreseeable future.
>
> We'll probably have to evolve our approach over time.

Yes :)

> > * The webkit.org/blog should aggregate the blogs of all contributors
> > (Surfin' Safari and blogs of external contributors)
>
> I think I'd like to keep Surfin' Safari as a blog for WebKit
> contributors where we also post occasionally Apple-focused info, and
> where any significant contributor is welcome to post. But I think we
> should add a planet.webkit.org type aggregator which includes Surfin'
> Safari and other WebKit contributor blogs.

Sounds good to me. The main thing is that it would be great to have a central 
place where all WebKit related blogs/news appears. Currently you have to 
search on lots of different places for blogs about WebKit (labs.trolltech.com 
and planetkde.org for the Qt port, planet.gnome.org for the Gtk port and 
other places for other people). This is IMO unfortunate as it doesn't give 
the public a good enough view on how large the community really is.

> > * The main webpage and the navigation bar should be platform agnostic
>
> I think the main page mostly is. Many of the pages linked from the
> sidebar have Mac or Safari specific info. However, that's not a matter
> of policy but just happens to be what the pages started with. The
> content is all in SVN and we welcome patches to

Re: [webkit-dev] Re: ProjectVision

[Lars Knoll]

On Friday 23 November 2007 23:59:25 Maciej Stachowiak wrote:
> On Nov 23, 2007, at 9:31 AM, Alp Toker wrote:
> > http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&ver
> >sion=1
> >
> > Please revert this change until the topic has been discussed on the
> > mailing list or bug tracker. You can't just make up a project vision
> > like that.

The page clearly states that these are ideas of the people working on the Qt 
port of WebKit. George, Adam, Simon and myself had a face to face meeting 
last week, and this came up there, so we thought it's best to put things 
together before it get's lost in the day to day work again. This is by no 
means something we want to impose on the project, it's the things we feel 
could be changed and improved over time.

> I don't think this page is meant to represent an opinion of the whole
> project, but rather a set of requests from the QtWebKit developers
> from the project as a whole. I think it would be a good idea to
> discuss the substance of the requests on the mailing list. I have
> already discussed some offline with Lars and George. Are you guys up
> for discussing these topics by email? I am also happy to discuss
> further off-list.

I would prefer a discussion on the mailing list. I think it's important that 
everyone contributing to the project can state it's opinion and hear all 
arguments.

> > It would be great if the Qt developers could also make more use of
> > the bug tracker and allow for peer review from the wider WebKit
> > team. Unilateral commits by Qt guys have broken other builds
> > recently wasting everyone's time.

I don't think we have committed many changes that affected cross platform 
code. At least 95% of what we've done was purely inside the Qt specific 
parts. If we broke someone else's build I apologize, but usually we are 
tracking the buildbots after our changes to make sure we fix up any breakages 
that should happen.

> Actually, I'm somewhat concerned as well about the QtWebKit work
> drifting away from the core somewhat. Doing work primarily in a
> separate repository and then pushing changes upstream creates a
> situation where the Qt developers communicate less with the rest of
> the project, and makes other developers less aware of their changes.

Just as a sidenote: Part of the communication problem is that efficient 
communication currently requires being on IRC all the time. I just got my 
second child a few weeks ago, and honestly do currently not have the 
possibility to do that.

> It also means more distance from project infrastructure like the
> buildbots.
>
> Qt guys, is there anything we could do to make it easier for you to
> work directly in the webkit.org repository?

The reasons are purely technical. The main reason we work as we do for the 
moment is that we need to stabilize our tree. We want to ship WebKit as part 
of Qt 4.4 in Q1/2008 and are now going into a feature freeze and 
stabilization phase for the Qt port.

To be able to get a stable product out, we decided to base the stuff that will 
go into Qt 4.4 on the Safari-3 branch. Now Apple stated clearly (and I 
completely agree to that), that the Safari-3 branch is something they want to 
control, which means that we have to do our work in a branch of our own that 
tracks Safari-3. Doing that in SVN is a real pain and would be a huge waste 
of time we don't currently have.

There is quite some work remaining to turn the Qt port into a completely 
polished release, so we unfortunately have to focus our resources on that 
branch.

We are however trying our best to continue tracking trunk as well, but our 
resources are a bit strained just now, as we are currently trying to tie Qt 
4.4 together. It should however get better in a few weeks from now when we 
enter our bug fixing phase for 4.4.

As to what would make it easier to work in the webkit.org repository: 
Currently our main problem is the version control system used, that makes it 
very hard to work on a branch that follows another branch.

I am not really happy that we are currently doing most work outside of the 
main repository, but we didn't see another possibility to make things work 
for us. 

That being said, our repository is basically a git mirror of SVN and does 
automatically pull in all changes happening in trunk. It's not that much 
different from other people using git on top of SVN apart from it being a 
more collaborative effort.

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

Re: [webkit-dev] Just a few ?'s about the Qt WebKit port...

[Lars Knoll]

On Friday 19 October 2007, Fuenty, Chris wrote:
> .As I'm reading on
> http://trac.webkit.org/projects/webkit/wiki/QtWebKitTodo I notice a few
> things that spark interest...
>
> #1: New HTTP Stack, Does this currently use any Stacks provided by the
> Qt Toolkit?  From some usage with QtWebKit, I see no noticeable problems
> with it..  Could someone fill me in on why this would be beneficial?

You don't immediately notice any problems, but trust me there are some. We are 
working on a new network stack for Qt, which we will integrate with for 
QtWebKit once it's ready.

> #2 QWebCookieJar < - > QWebNetInterface : How would this be done.  Does
> the QCookieJar automatically fetch the cookies from WebCore?  Or is it
> just pretty much useless at the current state.  I notice that it will
> save cookies for sessions (IE: goto a forum and login, it will save
> cookies until that QWebPage is destroyed).  What would be a good logical
> approach to keep cookies in a QCookieJar and keep them saved.

This relates to the new networking stuff above as well, as the new stack will 
likely contain some APIs to make cookie management easy.

> #3: NSPlugin Support: Is there any good API documentation on how you can
> use this (or specifically, in Qt projects).  Any API support for
> NSPlugins I have found is just for creating plugins, not being able to
> use them.

No, there's no docs available currently and the nsplugin support for QtWebKit 
is something that has to wait until a few other things in QtWebKit are done.

Cheers,
Lars

>
> Thanks.
>
> c
> ___
> 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] Is WebKit really working with QT4 ?

[Lars Knoll]

Lionel,

don't use that ubuntu package for Qt4. It's based on qt 4.3.0 beta1, and there 
have been some API changes between beta1 and 4.3.0 final. Get yourself Qt 
4.3.1 or 4.3.2 from www.trolltech.com, and use that.

QtWebKit is still work in progress, but most things do actually work (even 
though you'll see tons of notImplemented warnings).

Lars

On Wednesday 17 October 2007, Lionel Jive wrote:
> Guys,
>
> i'm a newbie for QT and WebKit.  can please somebody clear me up ?
>
> I can successfully build WebKit with QT4 (libqt4-dev-kdecopy), but when
> i run it i get no rendering and some error message such as:
>
> FIXME: UNIMPLEMENTED: ../../../WebCore/platform/qt/WidgetQt.cpp:120
> (virtual void WebCore::Widget::show())
> FIXME: UNIMPLEMENTED:
> ../../../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:195 (virtual
> void WebCore::FrameLoaderClientQt::forceLayoutForNonHTML())
>
> and when i have a look at FrameLoaderClientQt.cpp if see numerous
> functions that only call notImplemented() ;
>
> does WebKit fully work with QT, or is it a work in progress ?
>
> Thanks,
> Lionel


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

Re: [webkit-dev] Should we consider switching to git over svn?

[Lars Knoll]

I'll just add my 2 cents here. I'm very much in favor of switching over to git 
at some point. There are many reasons for that, but I'll try to highlight the 
main ones that come to my mind (in addition to the ones Oliver mentioned 
already):

* local repository and working offline: I often have to work offline (e.g. 
when travelling). With svn this is a pain (yes, I know about svk, but then 
I'm better off using git-svn) to do. git-svn solves most of it for me.

* smaller and more atomic submits: We've been using git quite a bit internally 
in Trolltech now. What we've seen from all people that have moved over to 
using git is that submits become a lot smaller and more atomic. With svn, you 
have to create one patch that makes it all work before being able to get a 
review. With git it's trivial to ask for review of a series of commits that 
belong together.

* easy branching and merging: Larger refactoring work is currently very hard 
to do without creating large disturbances for all ports/platforms. This will 
just get harder as more ports start to appear. In git it's very easy to 
create a branch for the refactoring work, start out on one port, then fix up 
all the other ports and once everything is done merge the branch back.

* tracking a branch: For our first release we want to track the branch that 
will be shipped on Leopard as close as possible. However we might need to add 
some changes on top that might conflict with the submit policy Apple would 
like to see for that branch. Following that branch in git is trivial by just 
pulling in all changes from Apples branch in regular intervals. In svn it's a 
pain to do. At the same time we want to make sure all our changes also make 
it into the development branch, which again is a real pain in svn.

* Branches and merging: To put it short: Support for branches in svn sucks big 
time. Oliver spend a lot of time rebasing the feature branch onto current 
ToT. With a vcs that has good support for branching and merging built in, 
this time could have been significantly reduced, esp as the feature branch 
would have merged in regular intervals from ToT to keep the diff at a 
minumum.

* Lots of cool features for advanced usage: git-bisect, git-stash, 

* No more need for a ChangeLog ;-)

* Last but not least: Internally in Trolltech a lot of developers are 
currently using git on top of perforce¹. Every single developer that has 
tried git and come over the initial learning curve loves it and doesn't want 
to move back to perforce. The only thing they complain is that we currently 
still have perforce underneath.

Cheers,
Lars

¹ Just a note on perforce: it's similar in many ways to svn by being a 
centralized VCS. The main difference is that perforce has decent support for 
branching and merging branches. In addition git-p4 is a lot faster and more 
convenient than git-svn (it includes e.g. all our branches).

On Tuesday 09 October 2007, Oliver Hunt wrote:
> In recent weeks/months a number of webkit developers have started
> using Git for day to day development, and have found it very useful.
> Git is yet another revision control system, but unlike RCS's such as
> cvs and svn it allows local branches and makes merging branches much
> easier.  In addition to making bracnhes much more manageable, it has
> a few other advantages:
>* Speed: Git is much faster than svn (which becomes very valuable
> on windows,
>* History: Git's history is much nicer than that of svn,
> especially with regards to patches submitted by people without commit
> rights, as it is able to distinguish the author of a patch from the
> person who committed it.
>* Collaboration:  It is possible for people to publish their git
> tree's in a way that allows them to be tracked by others, allowing
> people to collaborate on bugs and/or features much more easily
> without actually committing to a central repository.
>
> Unfortunately, git is still not as user friendly as svn, and has a
> relatively steep learning curve (largely due to it using some similar
> commands to svn for completely different purposes :-/ )
>
> On the other hand, those of us using git currently have to use the
> git-svn bridge which, while functional, is somewhat slow.  I think
> (and i'm hoping others agree) that despite the slightly more complex
> interface the improved merging, branching, and speed mean that we
> should seriously consider switching to git as our primary RCS.
>
> Any comments from others are welcome.
>
> --Oliver
> ___
> 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] Should we consider switching to git over svn?

[Lars Knoll]

On Tuesday 09 October 2007, Timothy Hatcher wrote:
> I think Git is rather slow on Windows I hear.

Yes, it's quite a bit slower than on Unix systems. But there has been quite a 
bit of work happening lately on the windows port speeding it up 
substantially. It's now pretty usable for us (Qt development) internally.

Lars

>
> On Oct 8, 2007, at 9:29 PM, Oliver Hunt wrote:
> >  * Speed: Git is much faster than svn (which becomes very valuable
> > on windows,
>
> — Timothy Hatcher


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

Re: [webkit-dev] Netscape API plugins for WebKit on Linux

[Lars Knoll]

On Monday 08 October 2007, Song Yuan wrote:
> Hi,
>
> I successfully built WebKit based on Qt port on Ubuntu. The "browser"
> in Qt window works really fine. But when I tried the test cases in
> "/LayoutTests/plugins" that uses Netscape API, none of them works as
> expected. I'm wondering how the progress is on WebKit/Qt port right
> now, especially regarding plugins that use Netscape API.

Netscape plugins do currently not work with the Qt port. This is something 
that is on our Todo list however.

The main issue here is that it's not straightforward to do NS plugins on 
Linux. We basically have to do them out of process due to library dependency 
issues. But that is non-trivial due to the fact that NS plugins expose a 
synchronous scripting bridge between the web page and the plugin.

> Two questions about it though:
>
> 1) The source code corresponding to the plugins used in test web pages
> in "/LayoutTests/plugins" like the one with MIME type of
> "application/x-webkit-test-netscape" seems to be located at
> "/WebKitTools/DumpRenderTree/TestNetscapePlugIn.subproj", which is
> organized as Xcode project. Does Qt port on Linux share the same
> source code for plugin here?

No, the Qt version of DumpRenderTree doesn't currently share any source code 
with the one for OS X.

> 2) In WebKit on Mac, source code of plugin is built with "Info.plist"
> in the same package ("Cocoa Bundle" template) to be deployed in
> "/Library/Internet Plug-Ins/" directory. As to WebKit on Linux, which
> is the directory to deploy plugin? Is the source code built into
> shared object, just like what Firefox on Linux did?

We currently add a small Qt based test plugin to DRT. This is linked 
statically into DRT. Apart from that QtWebKit searches for plugins in 
QT_INTALL_PREFIX/plugins.

Hope that answers your questions,
Lars

>
> Thanks in advance!
>
> /Song
> ___
> 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] Qt/Win32 build environment

[Lars Knoll]

On Friday 17 August 2007 15:21:27 Artem Ananiev wrote:
> Hi, Lars,
>
> thank you for the link. As I understand, Qt/Win32 port requires some
> libs from GnuWin32 - why not Cygwin? Are there any principal problems
> with Cygwin?

We require some libs from GnuWin32 for the build tools (bison et.al). QtWebKit 
itself has no external dependency (apart from Qt).

I'm not sure if things would build in cygwin. It's something we haven't 
tested.

Cheers,
Lars

>
> Thanks,
>
> Artem
>
> Lars Knoll wrote:
> > Hi Artem,
> >
> > there are some instructions on howto build QtWebKit on Windows on the
> > WebKit wiki:
> >
> > http://trac.webkit.org/projects/webkit/wiki/BuildingQtOnWindows
> >
> > Hope this helps,
> > Lars
> >
> > On Wednesday 15 August 2007, Artem Ananiev wrote:
> >> Hi, all,
> >>
> >> looking at the recent WebKit changes, I noticed some activity about
> >> Qt/Win32 platform implementation. Some time ago I tried to build it
> >> myself using cygwin environment, but with no success, mostly because of
> >> cygwin paths and missing the corresponding QMAKESPECS in the free
> >> version of Qt 4.3.0
> >>
> >> The question is what environment is now supposed for Qt/Win32 build? MS
> >> VC++ 2005 (like the current Win32 build) or QMake/Win32 (similar to
> >> Qt/Linux)?
> >>
> >> Thanks,
> >>
> >> Artem
> >> ___
> >> 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


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

Re: [webkit-dev] Qt/Win32 build environment

[Lars Knoll]

Hi Artem,

there are some instructions on howto build QtWebKit on Windows on the WebKit 
wiki:

http://trac.webkit.org/projects/webkit/wiki/BuildingQtOnWindows

Hope this helps,
Lars


On Wednesday 15 August 2007, Artem Ananiev wrote:
> Hi, all,
>
> looking at the recent WebKit changes, I noticed some activity about
> Qt/Win32 platform implementation. Some time ago I tried to build it
> myself using cygwin environment, but with no success, mostly because of
> cygwin paths and missing the corresponding QMAKESPECS in the free
> version of Qt 4.3.0
>
> The question is what environment is now supposed for Qt/Win32 build? MS
> VC++ 2005 (like the current Win32 build) or QMake/Win32 (similar to
> Qt/Linux)?
>
> Thanks,
>
> Artem
> ___
> 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] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Sunday 29 July 2007 08:47:50 Maciej Stachowiak wrote:
> On Jul 28, 2007, at 3:52 AM, Lars Knoll wrote:
> > On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
> >> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> >>
> >> Other organizations have requested the ability to use other XML
> >> parsers as well, such as expat. Seems like in the long run we want a
> >> different approach than just ifdefs in the XMLTokenizer.cpp file. It
> >> seems like the best would be some abstraction layer on top of the
> >> parser library, but if that is difficult then your option #2 sounds
> >> like a docent long-run approach. I would have expected just about
> >> every XML parsing library to have a SAX-like API, which shouldn't be
> >> too hard to abstract, but perhaps QXml works differently.
> >
> > I guess that assumption doesn't hold. QXmlStream is a streaming
> > parser with an
> > API that is very different from SAX. It IMO a whole lot simpler to
> > use than a
> > SAX like API and is inspired from similar APIs in the Java world. If
> > you're
> > interested, have a look at
> > http://doc.trolltech.com/4.3/qxmlstreamreader.html
>
> I'm told libxml has a StreamReader-style API now as well, so if that's
> the better alternative, we could design the XML code around that style
> of API (though probably not right at the moment).

No, for the moment, I'd rather just go with the approach I've posted in bug 
14791. Once there are requests for more parser backends, we could rethink 
this, but for now I think we have more urgent things to do.

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

Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Saturday 28 July 2007 00:26:19 Maciej Stachowiak wrote:
> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> > On Friday 27 July 2007 16:50:01 Darin Adler wrote:
> >> I'm not happy with the code organization here. XMLTokenizer now has
> >> tons of ifdefs and two separate implementations. It's fine to have a
> >> QXmlStream implementation, but the two implementations should be in
> >> separate files, side by side, as we do in the platform layer.
> >
> > I agree that the #ifdef's are not optimal, and we can move parts of
> > the code
> > out. But currently a lot of code is still shared between the
> > QXmlStream and
> > the libxml based implementations, so we have two choices:
> >
> > 1. just add an XMLTokenizerQt.cpp and duplicate lots of code.
> > 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp
> > and keep a
> > common XMLTokenizer.cpp for code that is used in both.
> > 3. Have some ifdef's in the one file.
> >
> > The first option is no good, as we'd have to duplicate lot's of
> > shared code
> > leading to maintenance issues in the long term.
> >
> > The second option is better, but also here we'd have quite a bit more
> > duplicated code than required as long as we don't do some bigger
> > refactoring
> > to abstract out the common parts. This is something we wanted to
> > avoid at the
> > moment. So we went for option 3.
>
> Other organizations have requested the ability to use other XML
> parsers as well, such as expat. Seems like in the long run we want a
> different approach than just ifdefs in the XMLTokenizer.cpp file. It
> seems like the best would be some abstraction layer on top of the
> parser library, but if that is difficult then your option #2 sounds
> like a docent long-run approach. I would have expected just about
> every XML parsing library to have a SAX-like API, which shouldn't be
> too hard to abstract, but perhaps QXml works differently.

I guess that assumption doesn't hold. QXmlStream is a streaming parser with an 
API that is very different from SAX. It IMO a whole lot simpler to use than a 
SAX like API and is inspired from similar APIs in the Java world. If you're 
interested, have a look at http://doc.trolltech.com/4.3/qxmlstreamreader.html

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

Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Friday 27 July 2007 21:15:27 Lars Knoll wrote:
> On Friday 27 July 2007 21:05:00 Darin Adler wrote:
> > On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote:
> > > I'm fine with moving to this approach (even though it'll still lead
> > > to some code duplication if we do it the easy way without
> > > refactoring).
> >
> > I don't think we should insist on doing it without refactoring. It
> > seems good to add private member functions as necessary so we can
> > share as much of the code as possible.
>
> Good, I was just under the impression that you wanted to avoid these kind
> of changes at the moment. I'll prepare a patch then.

Patch is in http://bugs.webkit.org/show_bug.cgi?id=14791 . Please review.

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

Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Friday 27 July 2007 21:05:00 Darin Adler wrote:
> On Jul 27, 2007, at 11:53 AM, Lars Knoll wrote:
> > I'm fine with moving to this approach (even though it'll still lead
> > to some code duplication if we do it the easy way without
> > refactoring).
>
> I don't think we should insist on doing it without refactoring. It
> seems good to add private member functions as necessary so we can
> share as much of the code as possible.

Good, I was just under the impression that you wanted to avoid these kind of 
changes at the moment. I'll prepare a patch then.

> The reason I'm particularly sensitive on this issue is that fixing the
> structure of ifdef'd code like this is something we've spent a lot of
> time on the last two years. We still have quite a bit left to fix from
> decisions I regret when adapting the code to Mac OS X, and I'd like to
> avoid introducing new cases of it now.

I agree. We mostly try to avoid these things for our platform specific code in 
Qt as well.

> > Should we move the XMLTokenizer class to WebCore/platform then?
>
> No.
>
> If we were making an independent XML abstraction that didn't depend on
> the rest of WebKit then it would belong there. But since we've decided
> to not go that way, this is just platform-specific code in another
> subdirectory, which we do as needed. See the loader directory, for
> example.

Ok.

> I'm not sure I like the filename XMLTokenizerLibXml.cpp, but I can't
> think of anything better.

I'd be happer to find a better name, but I couldn't think of one.

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

Re: [webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Friday 27 July 2007 20:50:53 Darin Adler wrote:
> On Jul 27, 2007, at 11:36 AM, Lars Knoll wrote:
> > 2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp
> > and keep a common XMLTokenizer.cpp for code that is used in both.
>
> I like that option best. It's the pattern used in platform for cases
> like this.

I'm fine with moving to this approach (even though it'll still lead to some 
code duplication if we do it the easy way without refactoring). 

Should we move the XMLTokenizer class to WebCore/platform then?

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

Re: [webkit-dev] type of JSChar

[Lars Knoll]

> > I do understand this for your Windows port. In Qt we try to have the
> > same types across all platforms. This is also true for our QChar
> > abstraction that is built on top of an unsigned short. So for us
> > typedef'ing this to wchar_t is as wrong as unsigned short would be
> > for your windows port.
>
> I'm sorry we don't see eye to eye on this. In the future there's good
> reason for this to be API. It was designed to be cross-platfom API
> without any reliance on any particular platform. I'd like to see this
> left as a possibility for Windows.

Could you explain what you mean by 'good reason'? 

> > For the Qt port, the 'platform' typedef is an unsigned short. So one
> > could say that the #ifdef for __BULDING_QT does about the same thing
> > as the #ifdef (WIN32) for your Windows port.
>
> OK. But would we expect people to define __BULDING_QT when using this
> header?

We are not planning to export this header as part of our public API. If 
someone want's to use this API together with JavascriptCore he is free to do 
so, but this is not at all related to a Qt port of WebKit.

> We've gone out of our way to not use the internal definitions like
> Platform.h in these headers, designed to be API and in a subdirectory
> named "API", and it's strange to have __BUILDING_QT here.

I'd also prefer not having it in there. Still for Qt as a platform, the 
correct typedef is unsigned short.

> >> Also, since JSStringRef.h is an API header, it's not good to have
> >> it depend on an project-internal define, so that's another reason
> >> to remove the recent change to JSStringRef.h.
> >
> > Well, it's not an API header for us. Still it's used internally in
> > WebKit, so we need to do something with the typedef. Different ports
> > do sometimes have slightly different goals.
>
> Longer term I'd like to see this as cross-platform API. Even though
> you don't see the need for this in your Qt port today, I think you
> might in the future, for example if it was used as part of a plug-in
> API and we wanted the plug-ins to work in both Qt WebKit on Windows
> and the WebKit on Windows that's released with Safari.

To have this usable by plugins it would have to be a cross browser API as well 
as a cross platform one. Are there any efforts on the way in this direction?

> Could you think about this a little more and see if you're swayed by
> my arguments? Also, please discuss this with Maciej if you have a
> chance.


On Friday 27 July 2007 20:32:32 Darin Adler wrote:
> One last comment that might help.
>
> The idea here is that this is a low level API. Lower level than, say,
> the WebKit API. It's not built on top of the platform APIs like AppKit
> on Mac OS X. The idea is that it's potentially independent of WebKit.
> That's a good argument for having it match the low level platform and
> not be built on top of, say, AppKit or Qt. That extends even to things
> like this type.

If someone want's to use JavascriptCore with this low level API he is free to 
do so.

> I guess the whole wchar_t thing is a snafu, though, because we
> normally would not want a type that is different on different
> platforms. Maybe we should dump the idea of using wchar_t on Windows
> for this.

Yes. If the API is supposed to be cross platform it would make most sense if 
the types are also compatible. wchar_t is unfortunately a pretty unusable 
type for cross platform API's as it is 16bit on Windows and 32bit on Linux.

> We were really following ICU's lead here -- ICU being another low
> level library not built on top of a framework like Qt or AppKit.

I do see that. In Qt, although we have lot's of the same functionality as ICU 
builtin, we chose a different path and used unsigned short on all platforms 
(as it's 16bit on all platforms we support).

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

[webkit-dev] Re: [webkit-changes] [24723] trunk/WebCore

[Lars Knoll]

On Friday 27 July 2007 16:50:01 Darin Adler wrote:
> I'm not happy with the code organization here. XMLTokenizer now has
> tons of ifdefs and two separate implementations. It's fine to have a
> QXmlStream implementation, but the two implementations should be in
> separate files, side by side, as we do in the platform layer.

I agree that the #ifdef's are not optimal, and we can move parts of the code 
out. But currently a lot of code is still shared between the QXmlStream and 
the libxml based implementations, so we have two choices:

1. just add an XMLTokenizerQt.cpp and duplicate lots of code.
2. add a qt/XMLTokenizerQt.cpp and a libxml/XMLTokenizerLibXml.cpp and keep a 
common XMLTokenizer.cpp for code that is used in both. 
3. Have some ifdef's in the one file.

The first option is no good, as we'd have to duplicate lot's of shared code 
leading to maintenance issues in the long term. 

The second option is better, but also here we'd have quite a bit more 
duplicated code than required as long as we don't do some bigger refactoring 
to abstract out the common parts. This is something we wanted to avoid at the 
moment. So we went for option 3.

> Or the XML parser should be abstracted out so we have a single
> XMLTokenizer built on a single parser abstraction.

That will be IMO almost impossible to do in an efficient way as the two 
parsers work very differently.

> I think this is also the type of patch that should be reviewed by at
> least one person other than the folks concentrating on the Qt port.

We've had other people look at most patches. The QXmlStream changes are 
required, and I think the only issue to discuss here could be separating 
implementations. This is something I'd like to do in the longer term, but as 
you're trying to stabilize currently I didn't feel that this should have been 
done right now.

> With the huge number of check-ins today, I'm sure there are other
> interesting things like this that I missed.

I think we did a thorough job reviewing our patches and testing them on all 
platforms (Mac, Windows, gtk and Qt). We also kept most changes rather small 
and atomic to make reviewing easier.

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

Re: [webkit-dev] type of JSChar

[Lars Knoll]

On Friday 27 July 2007 18:56:40 Darin Adler wrote:
> On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:
> > On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
> >> On 7/27/07 1:51 PM, "Simon Hausmann" <[EMAIL PROTECTED]> wrote:
> >>> Does anybody know/remember why JSChar is defined to wchar_t on
> >>> Windows and if
> >>> it is still needed?
> >>
> >> I think this was/is needed to match ICU's definition of UChar
> >> ("Define UChar to be wchar_t if that is 16 bits wide; always
> >> assumed to be unsigned. If wchar_t is not 16 bits wide, then
> >> define UChar to be uint16_t. This makes the definition of UChar
> >> platform-dependent but allows direct string type compatibility
> >> with platforms with 16-bit wchar_t types.")
> >
> > That's correct. And for the same reasons we should follow the same
> > pattern for UChar, even when ICU is not involved.
> >
> > I think that UnicodeQt4.h is the file that should be changed, not
> > JSStringRef.h.
>
> I should be more specific about the reasons I have for preferring this.
>
> It's a good feature for both JSChar and UChar that on the Windows
> platform, the 16-bit unsigned integer type they use is wchar_t,
> rather than unsigned short. That's because there are all sorts of
> Windows Unicode APIs that take wchar_t, and it's great to have the
> type match.

I do understand this for your Windows port. In Qt we try to have the same 
types across all platforms. This is also true for our QChar abstraction that 
is built on top of an unsigned short. So for us typedef'ing this to wchar_t 
is as wrong as unsigned short would be for your windows port.

> The same issue exists on Mac OS X, but on that platform the types for
> characters, Unichar and unichar, are unsigned short.
>
> Anyway, for the JavaScript API, it's great to have the character
> typedef match the platform typedef, as long as the platform typedef
> is a 16-bit unsigned integer. I'd like us to preserve that feature
> even when building for Qt. That increases the chance that client code
> using the JavaScript API can be independent of the particular
> underlying JavaScriptCore implementation.

For the Qt port, the 'platform' typedef is an unsigned short. So one could say 
that the #ifdef for __BULDING_QT does about the same thing as the #ifdef 
(WIN32) for your Windows port.

> Also, since JSStringRef.h is an API header, it's not good to have it
> depend on an project-internal define, so that's another reason to
> remove the recent change to JSStringRef.h.

Well, it's not an API header for us. Still it's used internally in WebKit, so 
we need to do something with the typedef. Different ports do sometimes have 
slightly different goals.

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

Re: [webkit-dev] WebKit Project Goals

[Lars Knoll]

On Wednesday 25 July 2007, Maciej Stachowiak wrote:
> I sent this a while ago with not much comment. Any thoughts? Should I
> post this on webkit.org somewhere?

I like both the goals and non-goals. Please put it onto webkit.org.

Cheers,
Lars

>
>   - Maciej
>
> On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote:
> > Hi Everyone,
> >
> > I recently watched a video on the topic of preventing poisonous
> > people from hurting an open source project. One of the practices it
> > recommends for a large open source project is to have a "mission
> > statement", so it's clear to everyone what is and isn't in scope for
> > the project. I'm not too fond of the name "mission statement" (it
> > sounds a little corporate) but I do think it's important to write
> > down our goals as a project.
> >
> > Ultimately I'd like to put this on the WebKit site, but I wanted to
> > throw out some ideas for discussion. I'd like to hear if anyone
> > thinks I have missed any project goals, if any of these are worded
> > badly, or if it is worth calling out more non-goals.
> >
> >
> > WebKit Project Goals
> >
> > WebKit is an open source Web content engine for browsers and other
> > applications. We value real-world web compatibility, standards
> > compliance, stability, performance, security, portability, usability
> > and relative ease of understanding and modifying the code
> > (hackability).
> >
> > Web Content Engine - The project's primary focus is content deployed
> > on the World Wide Web, using standards-based technologies such as
> > HTML, CSS, JavaScript and the DOM. However, we also want to make it
> > possible to embed WebKit in other applications, and to use it as a
> > general-purpose display and interaction engine.
> >
> > Open Source - WebKit should remain freely usable for both open
> > source and proprietary applications. To that end, we use BSD-style
> > and LGPL licenses.
> >
> > Compatibility - For users browsing the web, compatibility with their
> > existing sites is essential. We strive to maintain and improve
> > compatibility with existing web content, sometimes even at the
> > expense of standards. We use regression testing to maintain our
> > compatibility gains.
> >
> > Standards Compliance - WebKit aims for compliance with relevant web
> > standards, and support for new standards
> > In addition to improving compliance, we participate in the web
> > standards community to bring new technologies into standards, and to
> > make sure new standards are pratical to implement in our engine. We
> > use regression testing to maintain our standards compliance gains.
> >
> > Stability - The main WebKit code base should always maintain a high
> > degree of stability. This means that crashes, hangs and regressions
> > should be dealt with promptly, rather than letting them pile up.
> >
> > Performance - Maintaining and improving speed and memory use is an
> > important goal. We never consider performance "good enough", but
> > strive to constantly improve. As web content becomes richer and more
> > complex, and as web browsers run on more limited devices,
> > performance gains continue to have value even if normal browsing
> > seems fast enough.
> >
> > Security - Protecting users from security violations is critical. We
> > fix security issues promptly to protect users and maintain their
> > trust.
> >
> > Portability - The WebKit project seeks to address a variety of
> > needs. We want to make it reasonable to port WebKit to a variety of
> > desktop, mobile, embedded and other platforms. We will provide the
> > infrastructure to do this with tight platform integration, reusing
> > native platform services where appropriate and providing friendly
> > embedding APIs.
> >
> > Usability - To the extent that WebKit features affect the user
> > experience, we want them to work in accordance with good human
> > interface design principles, and to mesh well with platform-native
> > HI conventions.
> >
> > Hackability - To make rapid progress possible, we try to keep the
> > code relatively easy to understand, even though web technologies are
> > often complex. We try to use straightforward algorithms and data
> > structures when possible, we try to write clear, maintainable code,
> > and we continue to improve names and code structure to aid
> > understanding. When tricky "rocket science" code is truly needed to
> > solve some problem, we try to keep it bottled up behind clean
> > interfaces.
> >
> >
> > Non-Goals
> >
> > WebKit is an engine, not a browser. We do not plan to develop or
> > host a full-featured web browser based on WebKit. Others are welcome
> > to do so, of course.
> >
> > WebKit is an engineering project not a science project. For new
> > features to be adopted into WebKit, we strongly prefer for the
> > technology or at least the use case for it to be proven.
> >
> > WebKit is not a bundle of maximally general and reusable code - we
> > build some general-purpose parts, but only to the degree needed

Re: [webkit-dev] WebKit licensing and LGPLv3

[Lars Knoll]

On Wednesday 25 July 2007, Allan Sandfeld Jensen wrote:
> On Wednesday 25 July 2007 01:51, Maciej Stachowiak wrote:
> > 1) We will continue to accept only code that's licensed under a BSD-
> > style (no advertising clause) license, or LGPL 2.1, or other
> > compatible license. We don't want to accept code that's LGPL 3 only,
> > as that would make the whole project LGPL 3.
>
> I think continuing to require "LGPL 2 or later" would be the most sane and
> most compatible.

Accepting LGPL 3 only code is not something we should do, as it would lead to 
more restrict licensing terms than we currently have.

> > 2) We'd like to change the copyright notices from their current mix of
> > "LGPL 2 or any later version" and "LGPL 2.1 or any later version" to
> > just LGPL 2.1, to make this clear. This one is maybe more debatable,
> > so I'd like to know if anyone objects. It would prevent incorporating
> > WebKit code into LGPL 3 projects, and would require sign-off from all
> > copyright holders to ever change to a different LGPL version in the
> > future (in case the FSF came out with a version 3.1 or 4 that solved
> > some of the problems with v3).
>
> I object. I would like to reserve the right to integrate WebKit with LGPL 3
> projects like future KDE libs.
>
> Though since we are talking LGPL the linking-issues are not that
> problematic, it would still make it easier if the project continued to
> include the "or later" clause.

I have to agree with Allan. Restricting it to 2.1 only might give open source 
projects (KDE being one of them) problems in the future. I don't see a need 
to change the license to become more restrictive than it has been in the 
past.

As a sidenote, since we're already talking about licensing: I don't quite see 
the benefits of having a mix of BSD and LGPL licenses. LGPL is more 
restrictive, so that one applies to the project as a whole anyways. Wouldn't 
it be easier to just have one license (LGPL 2.1 or later) for the complete 
code base?

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

Re: [webkit-dev] Open Design beyond Open Source

[Lars Knoll]

Hi George and Maciej,

let me just add in some comments from my side :)

On Saturday 17 February 2007 08:23, Maciej Stachowiak wrote:
> Hey George,
>
> Thanks for sharing your concerns.
>
> On Feb 16, 2007, at 10:29 PM, George Staikos wrote:
> > On 16-Feb-07, at 9:22 PM, Mike Emmel wrote:
> >> Here is the link of what you have to go through to commit now.
> >>
> >> http://webkit.org/coding/contributing.html
> >>
> >> People wanting to do a new port are not going to go through this long
> >> trial program just to commit in fact that have not.  The KDE team has
> >> pre-existing interest and both OSX and S60 are commercial.  The  two
> >> true open source ports gdk/windows plus the wx widget port have
> >> basically been failures so far.
> >
> >If you mean to say that the impression given off by the webkit
> > project is one of "we don't want you" or at least "we're not really
> > interested in having more people join our project", I have to
> > agree.  I still don't get the feeling of a welcoming project.   Is
> > it a form of extreme paranoia that some new developer might
> > introduce a bug?  Maybe I'm not sure I consider that a valid
> > reason though.
>
> We really do want the WebKit project to be open to new contributors.
> We spend a lot of effort working on this. If we didn't care about
> having new developers join, we wouldn't have the whole public
> repository and web site at all.

Fortunately this has happened. We've had a split situation (between apple and 
KDE) for years, and with the WebKit project, we can finally start to pull 
into the same direction. Not everything is perfect currently (as some of the 
mails show), but in general I see things moving into the right direction.

> It is true that the WebKit project has somewhat higher barriers to
> entry than other large open source projects, like KDE. But I believe
> the barriers are lower than some others, like Mozilla.

Well, an HTML rendering engine has basically by definition a higher level of 
entrance as a project as KDE. This is purely due to the fact that the 
problems are more complex. With a huge desktop as KDE, people can always find 
corners that suit them and are easy enough to deal with. To be able to 
contribute in a good way to WebKit (at least code wise) requires some more 
knowledge to start out with.

Also in KDE the number of contributors to khtml was always rather small, and 
Dirk, Harri, Antti and myself kept a rather close eye on the core parts (DOM, 
CSS, JS and rendering). Also there every commit was reviewed. This often 
happened after the fact, which gave us problems and long discussions from 
time to time. So a pre submit review is IMO a good thing.

> Here are the barriers I think we have:
>
> 1) We require code review for all changes.
>
> 2) We do not grant commit access automatically; we expect people to
> have a track record of being good contributors. Note that this is
> more about showing that you can work with others and are not a source
> of conflict or negativity. It is not about coding skills.
>
> 3) We do not give review privileges automatically. This is more about
> understanding project policies and having good judgment
>
> 4) We require all code changes that affect processing of web content
> to come with a regression test case (if it is possible to make one).
>
> I think getting a patch reviewed is easier than in Mozilla, where you
> need a review and a "superreview" and adherence to all review
> happening in bugzilla is much more strict (we often bypass that and
> do review via email or IRC for established developers). But perhaps
> it is harder than for KDE, where things are often committed without
> review.

I agree to both here. Having worked a bit with mozilla as well, I have to say 
that WebKit is definively doing a lot better.

> I think it is also easier to get commit privileges than in Mozilla. I
> checked some stats, and everyone who has contributed more than 5
> patches so far this year already has commit rights. That says to me
> that the people actively contributing have the access they need. Now,
> it may be that some people were discouraged from even contributing in
> the first place. But that shows a lack of commitment to me.
>
> >> So from and opens source perspective webkit is not a smashing success
> >> in drawing in the open source community only the KDE team has really
> >> contributed and they were the original developers. The S60 port also
> >> has a history of working with KHTML before webkit was made
> >> a open project.
> >
> >   I wouldn't say so.  I think the KDE contribution is effectively
> > nil.  The Qt port is distinct from KDE plans.  KDE as a community
> > has yet to find a way to work together with WebKit for reasons that
> > I think you're also experiencing and perhaps not clearly
> > articulating.  Yes I'm writing this from @kde.org and have
> > contributed a huge amount to KDE, KHTML, etc over the past 8-9
> > years.  Until I have the KDE community feelin

Re: [webkit-dev] layout tests

[Lars Knoll]

On Friday 19 January 2007 14:31, David D. Kilzer wrote:
> On Jan 19, 2007, at 4:23 AM, Lars Knoll wrote:
> > * run-webkit-tests generated results for new tests on the fly
> >
> > [...]
> >
> > I've fixed this issue with r18976. run-webkit-tests does now not
> > generate new
> > results by default anymore. You'll have to pass the --new-tests
> > flag to it to
> > force it to do so.
>
> What is the behavior on the buildbot if a test is committed without
> results after applying this patch?  It SHOULD fail!  Currently, the
> buildbot will generate new results (that automatically pass) with no
> one the wiser.

That's what the change does. It doesn't generate new results, and will mark 
the test as "new" (not "failed"). bdash said he can fix build.webkit.org to 
show these explicitly as new tests. Marking them as failures is a bit too 
much, as you'd get 'regressions' on the qt build as soon as you added a test 
containing only the -expected files for the Mac and vice versa.

> > * All test results are stored together with the LayoutTests.
>
> Thinking out loud, I like the idea of having separate results trees,
> but I think it would be difficult to keep them in sync by putting
> them in another repository, especially when committing.  It will be
> challenging enough to generate results for all the trees when a new
> test is created or an existing test is fixed.  

That's why I thought that we shouldn't mark tests without a result for the 
platform as failures, but as what they are: new tests. You'd see them on the 
buildbot, manually inspect the new test on your platform and submit the 
results if the test passes. 

> Some example directory 
> structures (at the same level as LayoutTests):
>
>LayoutTestsResultsMac
>LayoutTestsResultsQt

I don't think that's a good idea, as we'd clutter the top level directory with 
lots of these in the long term.
>
>LayoutTestsTextResults
>LayoutTestsImageResults/mac
>LayoutTestsImageResults/qt
>
>LayoutTestsResults/text
>LayoutTestsResults/image/mac
>LayoutTestsResults/image/qt

I'd prefer:

  LayoutTestResults/text
  LayoutTestsResults/mac
  LayoutTestsResults/qt

There are lots of results that are RenderTreeDumps. These are platform 
dependent, but not images.

> Will we need some kind of a generate-test-results-on-all-ports-bot?
> We can't expect every developer to have "one of each" kind of
> system.  Or must we expect a developer on each port to review new
> tests and create updated test results on a per-port basis?

My idea was the last proposal. It's easiest to handle and verify. That's why I 
made sure you see new tests and why the results for new threads won't get 
created automatically.

> Would test results with the Qt port on the Mac be able to use the
> test results with the Qt port on Linux (specifically, the image
> results)?  I could see subtle differences occurring between the same
> "graphics port" on different operating systems.

Currently not. We're currently limiting our testing to Linux. Ideally it would 
be best to get 100% platform independent test results, but that's more or 
less impossible. So it could very well happen that we'll at some point also 
have Qt-Mac results.
>
> Does Subversion have a way to do something like "check out this
> entire tree, except for this directory" and then honor that
> commitment when updating as well?  Or would a custom update script be
> needed, or a tool like svk?

Good question. Maybe someone with more svn knowledge than I have has an 
answer.

> It's too bad there isn't a way to store a set of base results, then
> only store "expected differences" to each port.  That would cut down
> on the amount of space required by each new port's test results, but
> it might be tricky to do with image results, and a text diff might be
> as big or bigger than just new results.

It would actually not be smaller. The only place where it works is for the 
text only tests. The rendered page has slightly different coordinates and 
line breaks due to different font metrics. Unfortunately these differences 
show up as huge diffs if you try to do a diff between the RenderTree and the 
one on the Mac. 

I did however add a hack (see the --strict) option in run-webkit-tests, that 
tries to strip out all these things (coordinates, line breaks etc) from the 
RenderTree dump and then compare to the result on the Mac. This is a good 
test to see whether we have any bigger issues. Unfortunately it has two 
drawbacks: It doesn't work 100% reliable and can only be used for manual 
verification, and I would really like to have the position

[webkit-dev] layout tests

[Lars Knoll]

Hi,

I have finally gotten the layout tests for the Qt build running a few days 
ago. This does however bring two basic problems:

* run-webkit-tests generated results for new tests on the fly

This give problems both for the user and the build bots. As a user, you don't 
see that there is a new test checked in for which you don't have a result. 
This is especially a problem for the Qt build currently, but will also hit 
the Mac build once we start checking in layout tests. A test that doesn't 
have a result on a platform will most probably also need some manual 
inspection to ensure it works correctly on that platform.

The build bots run into trouble, as they will generate/store the result for 
the new test locally. Once someone commits the result, you'll end up getting 
svn merging issues, as the files the build bot wants to check out already 
exist on disk.

I've fixed this issue with r18976. run-webkit-tests does now not generate new 
results by default anymore. You'll have to pass the --new-tests flag to it to 
force it to do so.

* All test results are stored together with the LayoutTests. 

This is ok for text only tests (as the results can be shared), only that 
run-webkit-tests currently doesn't know whether a test is text only. 

Once we submit the Qt test results (including pixel tests), you'll get 3 move 
files per test case. In the long term we might get results from even more 
platforms, completely cluttering the directories.

Checking out all the test results does already now take quite some time (and 
people working on the Qt port don't really need the Mac results and vice 
versa). Adding more results will at some point make this prohibitive (the 
LayoutTests directory is at around 600MB currently, the number can be 
multiplied with every platform that has tests running).

One way of solving this is to move all test results into a separate results 
directory (or even separate repository). In there once could have 
subdirectories shared (for the text only tests), mac and qt. We could also 
add some sort of script to use instead of 'svn update' that will not check 
out the results you don't need.


Opinions?

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