[webkit-dev] gap in github WebKit mirror?

[Simon Hausmann]

Hi,

I'm a bit puzzled as I look at my local clone of 
https://github.com/WebKit/webkit.git to see that the commits between r147257 
and r147260 appear to be missing. The web interface appears to indicate that 
this is also the case on github itself.

Does anyone know what could cause this?


Simon

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

Re: [webkit-dev] Sunsetting committership and reviewership

[Simon Hausmann]

On Sunday 7. April 2013 18.27.14 Benjamin Poulain wrote:
> On Sun, Apr 7, 2013 at 6:07 PM, Dirk Schulze  wrote:
> > On Apr 7, 2013, at 5:53 PM, Benjamin Poulain  wrote:
> > > On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher 
> > 
> > wrote:
> > > I think 6 months is fine for deactivating SVN accounts. And a full
> > 
> > revoke of reviewer status after 2 years of no activity sounds reasonable
> > to
> > me. We could make it easier to get reviewer status again after a 2 year
> > sunset if the person becomes active again and shows good judgment still.
> > 
> > > +1 to this.
> > > 
> > > I think 2 years to revoke reviewer rights is too long. All the drive-by
> > 
> > reviews that have caused problems were from reviewers that were inactive
> > for less than 2 years. Nevertheless, 2 years is better than the current
> > situation so it is a good start.
> > 
> > The question is still how you measure active reviewers/contributors? Is it
> > enough to comment on bugs? Real reviews? Must there be at least one r+ in
> > this time? Is an actual commit required?
> > 
> > What do we gain from reverting reviewer ship/ committer ship?
> 
> There is a problem of people not contributing for a while, not familiar
> with the current code base, who come and review things for their colleagues.
> There are bad ideas accepted by reviewers who are not very active on the
> project.

And instead of addressing these reviewers directly we are trying to introduce 
a process to automate this, avoid the confrontation, hope that reviewers 
accepting bad ideas today will instead expire in the future.

It appears to me that this approach is based on the assumption that trust 
fades away over time. Naturally this perception may differ from person to 
person.

I have friends from school that I meet maybe once every two years. Oddly I 
still do trust them as much as I did before we went different ways in our life. 
The trust was earned at some point and for me it only changes on a per-
incident basis.


Simon

P.S.: I'm all in favour of locking unused SVN accounts for security reasons, 
similar to how many of us corporate email users have to change our passwords 
every X months.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Heads-up: C++11 and WebKit2

[Simon Hausmann]

On Tuesday, March 05, 2013 03:53:48 PM Benjamin Poulain wrote:
> On Tue, Mar 5, 2013 at 3:48 PM, Kenneth Rohde Christiansen <
> 
> kenneth.christian...@gmail.com> wrote:
> > I am personally happy that we can make use of C++11 and I don't
> > suppose it is a problem for the Tizen/EFL port. On the other hand, I
> > fear that Qt might be targeting some platforms where this could be an
> > issue. According to http://qt-project.org/wiki/Qt_5.0 they are still
> > aiming at supporting Windows XP as a Tier 1 platform.
> 
> WebKit2 already requires XP SP2 or above. Can't MSVC 2010 target that?

Yes. MSVC 2010 can target Windows XP SP2 and above. The run-time libraries of 
MSVC 2012 Update 1 support XP SP2 as well.


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

Re: [webkit-dev] Is the wxWidgets port maintained?

[Simon Hausmann]

On Tuesday, February 12, 2013 03:07:33 AM Dirk Pranke wrote:
> On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain  
wrote:
> > I am sorry, I should have given more context.
> > 
> > There is visibly a growing discontent in the community about the cost
> > imposed from small ports. Just two weeks ago, there were 2 threads
> > discussing the cost of "peripheral ports".
> > I am convinced a part of this is technical. The project has not changed
> > its
> > policies while the number of ports was growing. While duplicated code and
> > interfaces was okay when there were only 3 ports, it has become a pain
> > when
> > we have 7+ ports to updates ...
> > In his email "WebKit Wishes", Eric said "It can’t be the job of the core
> > maintainers to care about all the peripheral ports which contribute very
> > little core code."
> 
> I think it was an entirely reasonable question to ask if the wx port
> was being maintained, but I'm surprised by how this thread has
> evolved.
> 
> There is a lot of discussion going on about the cost of so many ports,
> but not much about the benefits.

Indeed. For example the small ports have successfully attracted people in the 
past to join the project. Those people built skills and gained visibility in 
in trunk, certainly helping them to get hired later by other bigger companies 
to continue to work on WebKit.

> Speaking personally, even before I joined Google, I was drawn to
> WebKit partially because it was used on such a wide variety of
> projects and in so many different ways. I was fortunate to be able to
> get a job that allows me to contribute to it, and I have found the
> work that I've done to help maintain the "peripheral" ports, while not
> pain free, quite rewarding (although I would be quite happy if it was
> less costly, of course).
> 
> My point is that I think that lots of ports are part of what makes
> WebKit the goodness it is. Maybe I'm alone here, or at best part of a
> minority, but I wanted us to not lose sight of this idea.

It's indeed an expressed goal of the project to be portable and to provide 
infrastructure. Also quoting from the project goals: "In addition, we strive 
to create a courteous, welcoming environment that feels approachable to 
newcomers."


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

Re: [webkit-dev] Can Qt use some of the common DRT code?

[Simon Hausmann]

On Monday, February 11, 2013 10:33:03 AM Allan Sandfeld Jensen wrote:
> On Monday 11 February 2013, Benjamin Poulain wrote:
> > One of the differences is the way the Qt port works. Instead of using the
> > JSC binding APIs, it uses its own JS Qt bindings.
> > Would it be possible for Qt to move to the common code? It would make
> > future refactoring easier as there would be one less difference to care
> > about.
> 
> I guess that would be possible, and if you continue to add more testrunner
> methods using continuation passing style, we may need to, since I do not
> think we currently have an easy way to pass a method through the Qt
> bindings.

Yeah, I guess that is a technical argument in favour of switching over.

> That said, Qt has the most convinient interface of all the DRT
> implementations with the bindings automatically derived from the C++
> declarations. I would hate to see that go, and since adding a method to Qt
> DRT is just adding the C++ method and nothing else, it is no worse than
> adding an empty
> implementation to all the ports that are using the common code.

While I agree with you and also appreciate the fact that this implementation 
improves our test coverage for the bindings code a lot, the current "weather" 
in the project on the other hand "suggests" that we better get out of the way 
:(

I'll start working on porting over to the C bindings (bug #109677).

Simon

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

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Simon Hausmann]

On Monday, February 04, 2013 10:57:46 AM Maciej Stachowiak wrote:
> On Feb 4, 2013, at 10:46 AM, Mark Mentovai  wrote:
> > GYP was written in Python to address point (b). Python was already part of
> > the baseline requirements on all platforms, so we already had Python
> > available everywhere we needed it. There are no dependencies on external
> > binaries, and no compiled code needs to be checked in anywhere or
> > maintained as part of a base image.
> > 
> > As for point (a), you can easily have a top-level Makefile not generated
> > by GYP that says “run GYP to produce the build files for whatever
> > environment you like and then pass control to that build system to do the
> > rest of the build. Developers who like it can use ninja for their own
> > builds, and your bots can use Xcode or make if that’s a requirement (or
> > if ninja doesn’t meet your requirements given point (b)).
> Checking in the generated Xcode projects is another alternative. The
> Makefile might be better for the reasons you suggest, though.
> 
> I'm reasonably confident at this point that Gyp can meet our hard
> requirements. Our remaining issues are finding time to do it and
> comprehensibility/readability of the syntax.

On the topic of the Gyp syntax:

I find it pretty readable, but I wonder if you guys are open to the idea of 
relaxing the parser a bit to also allow for the omission of quotes and commas 
for the dictionary keys. I feel a syntax like

{
includes: [
...
]

variables: [
]
}

is slightly less error prone to type and you could probably still support the 
"stricter" language, too.


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

Re: [webkit-dev] Changes to the WebKit2 development process

[Simon Hausmann]

On Tuesday, January 08, 2013 02:57:53 PM Sam Weinig wrote:
> Hello webkit-dev,
> 
> We are making some changes to the development process for WebKit2. These
> changes were announced to reviewers in advance, and I'd like to share them
> with you now.
> 
> WebKit2 has a core set of functionality that is valuable to all ports, and
> then aspects that are only of limited/specialized interest. It is becoming
> increasingly difficult to improve and advance the core functionality while
> maintaining the more peripheral aspects. In addition, changes to the core
> often require significant expertise to evaluate, for instance to ensure
> that the security and responsiveness goals of WebKit2 are met.
> 
> The changes are:
> 
> 1) WebKit2 now has owners. Only owners should review WebKit2 patches. While
> we do not want to apply this concept across the whole WebKit project at
> this time, for WebKit2 it is appropriate. The list of owners is documented
> in the Owners file at the WebKit2 top level directory, and in
> committers.py.

I think the fact that the regular WebKit review process stops at the boundary 
of WebKit2 should be documented in the WebKit Committers and Reviewer Policy.


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

Re: [webkit-dev] PSA: Migration plan to GStreamer 1.x

[Simon Hausmann]

On Tuesday, January 08, 2013 10:21:00 AM Philippe Normand wrote:
> Hi,
> 
> This mail is mainly for the GTK, Qt and EFL port maintainers, I decided
> to post here instead of cross-posting to three mailing lists :)
> 
> So there's been work to port the MediaPlayer and WebAudio GStreamer
> backends to the new GStreamer 1.x APIs. At the moment you can choose
> (well, for the GTK port at least) at build time if you want to use the
> 0.10 or 1.x APIs.
> 
> The issue is that GStreamer 0.10 is no longer actively maintained and
> the GStreamer developers/maintainers entirely focus on GStreamer 1.x.
> 
> Moreover we currently don't have the manpower to maintain the 2 code
> paths in the WebKit/GStreamer platform layer. The GTK port buildbots
> already switched to 1.0 last month and I encourage Qt and EFL to do the
> same ASAP, at least for their buildbots.
> 
> I'd like to propose we drop the GStreamer 0.10 support from WebKit once
> the next stable branch of GStreamer is released, it will be 1.2,
> scheduled somewhere around February.

Sounds good to me.


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

Re: [webkit-dev] compile failure when I try to introduce GLContextEGL to MediaPlayerPrivateGStreamer

[Simon Hausmann]

On Friday, November 09, 2012 02:16:33 AM Zhao, Halley wrote:
> when using "g++ -E", I found the issue after pre-processing: (thanks
> suggestion from Philippe) After include GLContextEGL.h, MediaPlayer::None
> changes to MediaPlayer::0L after pre-processing.

Ah, that's a classic. It's a macro the X11 headers define.
 
> Though I don't find the definition of None from new code introduced by
> GLContextEGL.h, I do think it is not good habit to use 'None' in such as
> big project; so I try to replace 'None' to PlatformMedia::PlayerTypeNone
> and MediaPlayer::PreloadLoadNone. It fixed my issue:

I don't think we should do that. None is a perfectly fine identifier to use in 
an enum the way it is. It's the X11 headers that are broken and the usual 
workaround is to do things like

#undef None

after including them. That should probably happen in GLContextEGL.h or even 
nearer to the inclusion.

Simon
 
> Here is the patch for your reference:
> 
> From d684bbbc34ea241f123544711bbad4ff58a06ebf Mon Sep 17 00:00:00 2001
> From: Zhao Halley 
> Date: Fri, 9 Nov 2012 09:50:27 +0800
> Subject: [PATCH] redefine MediaPlayer::None to MediaPlayer::PreloadNone or
> MediaPlayer::PlayerTypeNone
> 
> ---
> Source/WebCore/html/HTMLMediaElement.cpp   |4 ++--
> Source/WebCore/platform/graphics/MediaPlayer.cpp   |2 +-
> Source/WebCore/platform/graphics/MediaPlayer.h |4 ++--
> .../gstreamer/MediaPlayerPrivateGStreamer.cpp  |8 
> .../graphics/mac/MediaPlayerPrivateQTKit.mm|4 ++--
> .../platform/graphics/qt/MediaPlayerPrivateQt.cpp  |4 ++--
> .../MediaPlayerPrivateQuickTimeVisualContext.cpp   |4 ++--
> Source/WebKit/chromium/src/AssertMatchingEnums.cpp |2 +-
> .../chromium/src/WebMediaPlayerClientImpl.cpp  |4 ++--
> 9 files changed, 18 insertions(+), 18 deletions(-)
> mode change 100644 => 100755
> Source/WebCore/platform/graphics/MediaPlayer.cpp mode change 100644 =>
> 100755 Source/WebCore/platform/graphics/MediaPlayer.h mode change 100644 =>
> 100755
> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
> mode change 100644 => 100755
> Source/WebCore/platform/graphics/qt/MediaPlayerPrivateQt.cpp mode change
> 100644 => 100755
> Source/WebCore/platform/graphics/win/MediaPlayerPrivateQuickTimeVisualConte
> xt.cpp
> 
> diff --git a/Source/WebCore/html/HTMLMediaElement.cpp
> b/Source/WebCore/html/HTMLMediaElement.cpp index ebeee1b..d9f1691 100644
> --- a/Source/WebCore/html/HTMLMediaElement.cpp
> +++ b/Source/WebCore/html/HTMLMediaElement.cpp
> @@ -364,7 +364,7 @@ void HTMLMediaElement::parseAttribute(const Attribute&
> attribute) #endif
>  else if (attribute.name() == preloadAttr) {
>  if (equalIgnoringCase(attribute.value(), "none"))
> -m_preload = MediaPlayer::None;
> +m_preload = MediaPlayer::PreloadNone;
>  else if (equalIgnoringCase(attribute.value(), "metadata"))
>  m_preload = MediaPlayer::MetaData;
>  else {
> @@ -2263,7 +2263,7 @@ void HTMLMediaElement::setAutoplay(bool b)
> String HTMLMediaElement::preload() const
> {
>  switch (m_preload) {
> -case MediaPlayer::None:
> +case MediaPlayer::PreloadNone:
>  return "none";
>  break;
>  case MediaPlayer::MetaData:
> diff --git a/Source/WebCore/platform/graphics/MediaPlayer.cpp
> b/Source/WebCore/platform/graphics/MediaPlayer.cpp old mode 100644
> new mode 100755
> index 377e8dc..1977c8a
> --- a/Source/WebCore/platform/graphics/MediaPlayer.cpp
> +++ b/Source/WebCore/platform/graphics/MediaPlayer.cpp
> @@ -79,7 +79,7 @@
>  namespace WebCore {
> -const PlatformMedia NoPlatformMedia = { PlatformMedia::None, {0} };
> +const PlatformMedia NoPlatformMedia = { PlatformMedia::PlayerTypeNone, {0}
> }; // a null player to make MediaPlayer logic simpler
> diff --git a/Source/WebCore/platform/graphics/MediaPlayer.h
> b/Source/WebCore/platform/graphics/MediaPlayer.h old mode 100644
> new mode 100755
> index 993e9981..422032f
> --- a/Source/WebCore/platform/graphics/MediaPlayer.h
> +++ b/Source/WebCore/platform/graphics/MediaPlayer.h
> @@ -68,7 +68,7 @@ class MediaSource;
> // backend can live at runtime.
> struct PlatformMedia {
>  enum {
> -None,
> +PlayerTypeNone,
>  QTMovieType,
>  QTMovieGWorldType,
>  QTMovieVisualContextType,
> @@ -332,7 +332,7 @@ public:
>  enum MovieLoadType { Unknown, Download, StoredStream, LiveStream };
>  MovieLoadType movieLoadType() const;
> -enum Preload { None, MetaData, Auto };
> +enum Preload { PreloadNone, MetaData, Auto };
>  Preload preload() const;
>  void setPreload(Preload);
> diff --git
> a/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cp
> p
> b/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cp
> p old mode 100644
> new mode 100755
> index a4d4745..20a50a4
> ---
> a/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cp
> p 

Re: [webkit-dev] assumption about point packing in multit-touch tests

[Simon Hausmann]

On Wednesday, July 18, 2012 12:53:35 PM ext Benjamin Poulain wrote:
> On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso  wrote:
> > Though the W3C spec allows packing more than one touch point update in
> > a single touch event, it says nothing about how these updates should
> > be packed, so I think that the current tests are too restrictive and
> > should be relaxed to stop assuming anything about how the updates are
> > packed into events.
> 
> In practice, every port does the exact same thing for the delivery of
> touch events. It is also what the Web content expects nowadays.

I think it would be better if it were _allowed_ if the platform delivered 
multiple touch events for individual touch point updates. I mean in some way 
it is in fact up to the user to the extend that if my mind wants to move two 
fingers simultaenously it might just happen that one finger moves first and 
only 
a few milliseconds later the second finger starts moving.

Nevertheless I agree that the tests are good that way because they do require 
the platform to at least _support_ multiple updates in one event.

On a low level that requirement is satisfied by Cocoa touch events, WM_TOUCH on 
Windows and even the Linux kernel supports it, from the kernel protocol up to 
protocols like wayland with a specific touch_frame event to indicate the end of 
a contact point list update with multiple points. It seems it's only XInput 
that stands out, and Qt for example covers it up again by just remembering the 
state of the other touch points. But since there is no notion that indicates 
the end of an multi point touch update, we end up with multiple touch events.

> It looks like this spec needs an update, not the WebKit tests.

I don't think the spec should be changed so that XInput based platforms cannot 
satisfy the spec requirements. But I agree that the tests are good the way 
they are because they enforce the requirement to at least possibly support 
multiple updates in one event.

Another argument for keeping the current behaviour in the tests is that the 
JavaScript API (initTouchEvent) takes a touch _list_, and theoretically JS 
could send a (synthetic) touch even that way. It would be wrong to split that 
event up into multiple events with one per changed touch point. So I think 
it's only fair to require the platform to at least support the same semantics.


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

Re: [webkit-dev] github mirror

[Simon Hausmann]

On Tuesday, April 24, 2012 03:59:47 PM Tor Arne Vestbø wrote:
> On 24.04.12 15:55, ext Adam Roben wrote:
> > Probably the biggest issue is for people who've been using
> > git.webkit.org and now want to try out GitHub. Since the commits are
> > distinct between the two repositories, they have to do a full clone to
> > make the switch.
> 
> Any idea why git is not smarter when pulling down the objects?

I think it's to minimize the traffic in the git protocol. If you just compare 
git commits, you can calculate the delta relatively quickly with fewer 
roundtrips. If server and client start to negotiate on the git object level 
itself it's going to take months to figure out which objects the client has and 
which ones are missing :)

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

Re: [webkit-dev] github mirror

[Simon Hausmann]

On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
> Hi WebKit,
> 
> I've been using a fork of the following repo:
> https://github.com/WebKit/webkit
> 
> However, yesterday there was discussion on #webkit that the SHA-1 checksums
> on this repo are different from repo at git.webkit.org, which means folks
> working on both need to have both versions checked out.

I believe the reason for them being different is because in the github repo the 
commit author fields are resolved.


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

Re: [webkit-dev] Moving to Git?

[simon . hausmann]

Alexis, imagine not pushing directly but going through an intermediate system 
like in Qt - where history is nicely linear now :)


Simon

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of ext Alexis Menard [alexis.men...@openbossa.org]
Sent: Thursday, March 08, 2012 18:35
To: Konrad Piascik
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik  wrote:
> It is possible to keep linear history with git.  This just requires you to 
> fast forward and rebase before pushing.

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

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



--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
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] Removing support for the RVCT compiler

[Simon Hausmann]

On Sunday, December 11, 2011 02:55:40 AM ext Andreas Kling wrote:
> Hola WebKittens!
> 
> Are there any objections to removing support for the RVCT compiler (ARM
> RealView) in WebKit? As far as I know, the only user has been the Symbian
> port which is no longer present on WebKit trunk.

I believe some other folks (Brew? Blackberry?) have been compiling WebKit with 
RVCT. Generally speaking I think it's a pretty decent compiler provided a 
recent version is used. There are versions available for Linux for example, so 
it's not a Symbian specific compiler at all.

The Qt builds were largely based on RVCT 2.2, which had its fair share of 
issues (not as bad as WINSCW though). I believe the majority of compiler 
workarounds in WebKit related to RVCT are because of this ancient version.

I think any RVCT related compiler workarounds could probably be removed, 
because there's a very high chance that they're due to 2.2. But I think if 
COMPILER(RVCT) is kept, then I can imagine that it would require very little 
maintenance to keep supporting it.

(Interestingly enough grep in WebCore doesn't show anything RVCT related, only 
JavaScriptCore seems to have some serious workarounds for it)

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

Re: [webkit-dev] +R mode on #webkit IRC channel

[Simon Hausmann]

On Tuesday 19 January 2010 ext Xan Lopez, wrote:
> Hi,
> 
> I woke up this morning to find #webkit set up with mode +R
> (http://docs.dal.net/docs/modes.html#2.17), so basically you can't
> speak unless you have your nick registered on freenode. Is this a new
> policy or just some error or temporary measure that someone forgot to
> disable? If it's the latter it would be good to go back to normality.

Yesterday morning someone flooded the channel with CTCP version request (or 
something) that caused everyone to get rejected from the IRC servers due to 
flooding. It was a rather effective DoS where the only way to stay on IRC 
required leaving #webkit.

I personally don't mind nickserv registration as requirement.

Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Touch-supporting layout tests

[Simon Hausmann]

On Monday 11 January 2010 06:17:17 pm ext Dimitri Glazkov wrote:
> I think it's really cool that we have some touch events-related layout
> tests landing in the tree. But... is there a chance we could move them
> to a directory that would allow easy filtering-out for ports that
> don't support touch events? fast/events/touch/, for instance?

Good idea! Done in r53125.

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

[webkit-dev] DOM Touch Event Support

[Simon Hausmann]

Hi,

Kim and I have been looking into DOM/JavaScript touch event support (see 
https://bugs.webkit.org/show_bug.cgi?id=32114 ). After some research we 
concluded that the best option for the interface is the de-facto standard 
shipped by the iPhone, Android and Palm-Pre.

So we took the BSD licensed IDL files from Android's eclaire branch, simple 
PlatformTouchEvent and PlatformTouchPoint abstraction classes, a Qt 
implementation for these and some basic layout tests to test the values and 
behaviour of the JS events.

We've uploaded the patches for review and would love to get feedback on them.


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

Re: [webkit-dev] Guided bug reporting on bugs.webkit.org

[Simon Hausmann]

On Tuesday 06 October 2009 Vestbo Tor.Arne (Nokia-D-Qt/Oslo), wrote:
[...]
> I guess the usefulness of something like this deepens on how we view the
>WebKit bugzilla. Is it for developers only? For users of WebKit API
> (C,ObjC,GTK,Qt). For advanced users of browsers/products that use WebKit
> (where the user knows the bug is a WebKit bug)?

Let me rephrase Tor Arne's question: Is it a goal of the project that 
bugs.webkit.org can be used directly for the products resulting from the 
WebKit code base, or is bugs.webkit.org always meant to be a second-line 
tracker behind a product specific external system?



Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Qtish API for JavaScriptCore

[Simon Hausmann]

On Thursday 27 August 2009 10:09:38 am ext Kalle Vahlman wrote:
> 2009/8/26 Simon Hausmann :
> > Hi fellow WebKit contributors!
> >
> > Currently the Qt port of WebKit merely provides an API to deal with
> > rendering web content, and as such our interface to the underlying
> > JavaScriptCore engine is minimal.
> >
> > We, the team of Qt developers at Nokia and INdT, would like to add a C++
> > Qt API to JavaScriptCore as well, to allow application developers to for
> > example embed the JavaScriptCore engine into their applications.
> >
> > We want to give developers the ability to introspect the environment,
> > inject custom classes and call functions using a C++ API that uses Qt
> > types and has a Qt-ish feel to it.
>
> While binding Qt objects to JS is certainly a nice feature, I'd really
> like to see the JSC API supported as well. There are already many
> projects that enable ice-cool stuff through the JSC API (eg. Seed and
> our D-Bus Bridge) and the only missing piece in getting them to work
> as-is for QtWebKit is to get the JS Context.

If the JSContextRef is just an enabler to combine existing components then I 
think that would make sense. I would prefer to leave that as an 
undocumented/internal getter though (which we can still keep stable).

> It would be a shame if QtWebKit projects would be missing out all that
> coolness just because the JSC API isn't Qt-ish enough to expose. It's
> not like every project will start to carry two implementations.

Note that with the current way of compile time abstractions to for example 
threading and unicode handling it's not possible to mix a glib based JSC 
library with QtWebKit on top.


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

Re: [webkit-dev] Qtish API for JavaScriptCore

[Simon Hausmann]

Hi Oliver,

On Wednesday 26 August 2009 11:04:29 pm ext Oliver Hunt wrote:
> Hi Simon,
>  It would really be preferred if the Qt API were just built on top
> of the standard JSC C-API, and was kept external from the repository.

We would like to utilize a Qt JSC API in the Qt API of WebKit, too. It's a big 
part of the motivation. And we want to eliminate the entire WebCore/bridge/qt 
code, which is pretty ugly.

>From a dependency point of view it's a bit tricky if the Qt build of WebKit 
depends on an external library that in turn depends on JavaScriptCore from the 
same SVN repository.

That however appears to me to be independent from the issue of whether the Qt 
API uses the JSC C-API or not. (more about that below)

Would you still be okay with hosting a Qt API in the SVN if it's based on the 
C API?

> Currently the JavaScriptoCore API is completely platform and library
> independent except for the one somewhat unfortunate API referring to
> CoreFoundation but that's only exposed in the umbrella
> JavaScriptCore.h header, the JavaScript.h header is clean of any
> platform dependency.

That should be no problem indeed.

> The C API that exists already has guaranteed API and ABI
> compatibility, and this is already proving to be difficult (and in
> some cases a hindrance) to maintain as we strive to improve JSC
> performance. 

I fully believe you that this is already difficult, given the amount of 
incredible optimizations you're doing in the core. I'm curious though, where 
has the current C API bitten you?

> Adding an additional API would simply serve to make this
> task even more complex and difficult, and would have no benefit to the
> project while carrying substantial cost moving forward. 

I agree, if it harms the project in its goal of moving forward and becoming 
faster, etc. then it doesn't belong there.

> A further
> issue is that any API that binds directly to JSC internals
> realistically needs to be developed by the engineers working on the
> core engine as a developing such an API needs enormous care to not
> cause harmful long term problems.

I understand that. We've been bitten by that, too, as we've ported our 
existing API to JSC internals, to see how it can be done. The vast majority 
was straight forward as we've been careful in the original design to only 
expose what you can do in JavaScript itself. In a few places we've made 
mistakes but we've found solutions for them, too, that don't affect the 
internals in flexibility or performance. (*pokes some of the guys to elaborate 
a bit here*)

We fully agree that it doesn't make sense to use all the internals, there has 
to be a layer of abstraction to protect the engine. Currently the C API is not 
a rich enough layer for us, but I guess the best way to explain that is to file 
bug reports with patches to extend it? :)

What about functionality where the C API would slow down the C++ API but the 
internal JSC API is stable enough/good enough? I can think of the debugger for 
example.

Is there a middle ground to use as much of the C API as possible and fall back 
to internals otherwise (after discussion)?

> Over time we have added new functionality to the C-API as the need
> developed, so if there is specific functionality the Qt API would
> depend on we would be open to any suggestions.

Great :)

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

[webkit-dev] Qtish API for JavaScriptCore

[Simon Hausmann]

Hi fellow WebKit contributors!

Currently the Qt port of WebKit merely provides an API to deal with rendering 
web content, and as such our interface to the underlying JavaScriptCore engine 
is minimal.

We, the team of Qt developers at Nokia and INdT, would like to add a C++ Qt  
API to JavaScriptCore as well, to allow application developers to for example  
embed the JavaScriptCore engine into their applications.

We want to give developers the ability to introspect the environment, inject  
custom classes and call functions using a C++ API that uses Qt types and has a  
Qt-ish feel to it. Current releases of Qt come with such an API as part of the 
QtScript module, which however is based on an in-house developed interpreter.

So we decided to combine the well-tested API with a much better engine and  
spent the past few months making QtScript merely another API for  
JavaScriptCore, with only minimal changes.

We would like to contribute this API to the WebKit project, actively develop 
it there and therefore ask the community for opinions, thoughts or objections.

The API itself consists of 12 public classes. An introduction and
overview as well as the detailed class documentation can be found at

http://doc.qt.nokia.com/4.6-snapshot/scripting.html

 which is based on the unchanged API on top of the old engine.

If the community agrees, we would like to begin the process of
contribution in Bugzilla with patches for review that populate a
sub-folder in JavaScriptCore, for example JavaScriptCore/qt or
JavaScriptCore/API/qt.


On behalf of the Qt developers,
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] About Integrating JIT for ARM into QT Webkit(QTE4.5.2)?

[Simon Hausmann]

On Monday 20 July 2009 ext Wei Song, wrote:
> Hi all,
> Who know the situation of About Integrating JIT for ARM into QT 
Webkit(QTE4.5.2)?
> Had it done by Trolltech and it was based in SquirrelFish or 
SquirrelFish Extreme, or others?

Qt 4.5 does not ship with a version of JavaScriptCore that has a JIT for ARM 
processors.


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] #if PLATFORM(CF) || (PLATFORM(QT) && PLATFORM(DARWIN))

[Simon Hausmann]

On Friday 30 January 2009 17:59:10 Darin Adler wrote:
> I noticed that code relating to Core Foundation has the ifdef above:
>
>  #if PLATFORM(CF) || (PLATFORM(QT) && PLATFORM(DARWIN))
>
> This seems wrong. Why doesn't the CF platform switch get set when
> compiling with Qt and Darwin? It should. Does it cause problems? Can
> we just fix those?

You're right, today it should probably be possible to set CF when compiling 
WebKit against Qt on Mac OS X. Please file a bug against me to compile-test and 
fix it.


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

Re: [webkit-dev] renaming ASSERT macro

[Simon Hausmann]

On Wednesday 02 July 2008 09:40:19 Jörg Bornemann wrote:
> Hi Darin,
>
> Thanks for your detailed comments!
>
> > Adding  to Assertions.h will not cause it to be included in
> > public headers. Assertions.h is not designed to be used in public
> > headers; it's for internal use inside the WebKit project.
>
> I've just executed the following:
> find . -name '*.h' -exec grep -Hn 'Assertions.h' '{}' \;
>
> You're sure, that none of the 40+ files, the above call yields, is a
> public header or used inside a public header?
>But well, if Assertions.h is meant to be part of the private API,
> that particular argument of mine is void. A public header including
> Assertions.h, even an indirect include, should then be considered as bug?

I don't think Assertions.h is used in any public header file. It's for sure 
not the case in the Qt port, and since it includes Platform.h I doubt it 
would work in any public header.


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Qt Webkit compile error with QChar

[Simon Hausmann]

On Wednesday 02 April 2008 13:16:15 rachid pstomer wrote:
> Hi, I'm trying to build QT-4.4.0 Webkit under visual studio 2005. The build
> failed and i had these errors:
>
>
> cl -c -FIWebKit_pch.h -YuWebKit_pch.h -Fptmp\obj\debug_shared\QtWebKitd_
> pch.pch -nologo -Zm200 -Zi -MDd -GR -GX -DQT_SHARED -DQT_THREAD_SUPPORT
> -DUNICOD E -DQT_LARGEFILE_SUPPORT -DBUILDING_QT__=1 -DUSE_SYSTEM_MALLOC
> -DNDEBUG -DQT_MAK EDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
> -DQT_44_API_QSQLQUERY_FINISH -DQT3_SUPPORT -DQT_MOC_COMPAT
> -D_USE_MATH_DEFINES -DBUILD_WEBKIT -DENABLE_ICOND ATABASE=0
> -DENABLE_XPATH=1 -DENABLE_SVG=1 -DWTF_CHANGES=1 -DBUILDING_QT__ -DWTF_
> USE_JAVASCRIPTCORE_BINDINGS=1 -DQT_DLL -DQT_GUI_LIB -DQT_NETWORK_LIB
> -DQT_CORE_L IB -I"..\..\..\..\include\QtCore"
> -I"..\..\..\..\include\QtCore" -I"..\..\..\..\ include\QtNetwork"
> -I"..\..\..\..\include\QtNetwork" -I"..\..\..\..\include\QtGu i"
> -I"..\..\..\..\include\QtGui" -I"..\..\..\..\include" -I"..\WebKit\qt\Api"
> -I "..\JavaScriptCore" -I"..\JavaScriptCore\kjs"
> -I"..\JavaScriptCore\bindings" -I" ..\JavaScriptCore\bindings\c"
> -I"..\JavaScriptCore\wtf" -I"..\JavaScriptCore\For wardingHeaders" -I"."
> -I"ForwardingHeaders" -I"platform" -I"platform\network" -I
> "platform\graphics" -I"loader" -I"page" -I"css" -I"dom" -I"bridge"
> -I"editing" - I"rendering" -I"history" -I"xml" -I"html"
> -I"..\..\..\..\include\QtWebKit" -I"tm p" -I"generated" -I"tmp"
> -I"..\JavaScriptCore" -I"..\JavaScriptCore\kjs" -I"..\J
> avaScriptCore\bindings" -I"..\JavaScriptCore\bindings\c"
> -I"..\JavaScriptCore\wt f" -I"..\JavaScriptCore\bindings\qt"
> -I"..\JavaScriptCore\os-win32" -I"..\JavaSc riptCore\pcre"
> -I"c:\Qt\4.4.0\src\3rdparty\webkit\WebKitBuild\Debug\JavaScriptCo
> re\kjs\tmp" -I"platform\qt" -I"platform\network\qt"
> -I"platform\graphics\qt" -I" platform\graphics\svg\qt" -I"loader\qt"
> -I"page\qt" -I"..\WebKit\qt\WebCoreSuppo rt" -I"..\WebKit\qt\Api" -I"."
> -I"ForwardingHeaders" -I"..\..\webkit" -I"..\Java ScriptCore\kjs"
> -I"..\JavaScriptCore\bindings" -I"platform" -I"platform\network"
> -I"platform\graphics" -I"platform\graphics\svg"
> -I"platform\graphics\svg\filter s" -I"loader" -I"loader\icon" -I"css"
> -I"dom" -I"page" -I"bridge" -I"editing" -I "rendering" -I"history" -I"xml"
> -I"html" -I"bindings\js" -I"ksvg2" -I"ksvg2\css" -I"ksvg2\svg"
> -I"ksvg2\misc" -I"ksvg2\events" -I"platform\image-decoders" -I"c:
> \Qt\4.4.0\include\ActiveQt" -I"tmp\moc\debug_shared" -I"."
> -I"..\..\..\..\mkspec s\win32-msvc" -Fotmp\obj\debug_shared\function.obj
> ..\JavaScriptCore\kjs\functio n.cpp
> cl : Command line warning D9035 : option 'GX' has been deprecated and will
> be re moved in a future release
> cl : Command line warning D9036 : use 'EHsc' instead of 'GX'
> function.cpp
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(231) : warning
> C4355: 'this' : used in base member initializer list
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(288) : warning
> C4355: 'this' : used in base member initializer list
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(347) : warning
> C4355: 'this' : used in base member initializer list
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(809) : warning
> C4355: 'this' : used in base member initializer list
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(1004) : warning
> C4355
>
> : 'this' : used in base member initializer list
>
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\kjs\nodes.h(1116) : warning
> C4355
>
> : 'this' : used in base member initializer list
>
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\wtf\unicode\qt4/UnicodeQt4.h
>(307)
>
>  : error C2668: 'QChar::toCaseFolded' : ambiguous call to overloaded
>  : function
>
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(325):
> could b e 'ushort QChar::toCaseFolded(ushort)'
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(324): or
> 'uin t QChar::toCaseFolded(uint)'
> while trying to match the argument list '(UChar)'
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\wtf\unicode\qt4/UnicodeQt4.h
>(379)
>
>  : error C2668: 'QChar::toCaseFolded' : ambiguous call to overloaded
>  : function
>
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(325):
> could b e 'ushort QChar::toCaseFolded(ushort)'
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(324): or
> 'uin t QChar::toCaseFolded(uint)'
> while trying to match the argument list '(const UChar)'
> c:\qt\4.4.0\src\3rdparty\webkit\javascriptcore\wtf\unicode\qt4/UnicodeQt4.h
>(380)
>
>  : error C2668: 'QChar::toCaseFolded' : ambiguous call to overloaded
>  : function
>
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(325):
> could b e 'ushort QChar::toCaseFolded(ushort)'
> c:\qt\4.4.0\include\qtcore\../../src/corelib/tools/qchar.h(324): or
> 'uin t QChar::toCaseFolded(uint)'
> while trying to match the argument list '(con

[webkit-dev] Re: QWebNetworkManager triggering a memleak in Qt

[Simon Hausmann]

On Thursday 03 January 2008 23:28:49 Adam Treat wrote:
> Hi,
>
> I've checked and this appears to be the case in both Qt 4.3.2 and Qt 4.4
> snapshot...
>
> ==7746== 4 bytes in 1 blocks are definitely lost in loss record 5 of 507
> ==7746==at 0x4022765: malloc (vg_replace_malloc.c:149)
> ==7746==by 0x5CB16C4: qMalloc(unsigned) (qglobal.cpp:1964)
> ==7746==by 0x5D7E43C: queuedConnectionTypes(QList const&)
> (qobject.cpp:67)
> ==7746==by 0x5D82E5A: QObject::connect(QObject const*, char const*,
> QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2567)
> ==7746==by 0x80513D2: QObject::connect(QObject const*, char const*,
> char const*, Qt::ConnectionType) const (qobject.h:291)
> ==7746==by 0x4B38C6C: QWebNetworkManager::QWebNetworkManager()
> (qwebnetworkinterface.cpp:432)
> ==7746==by 0x4B38D5F:
> QWebNetworkInterface::QWebNetworkInterface(QObject*)
> (qwebnetworkinterface.cpp:906)
> ==7746==by 0x4B38DE6: QWebNetworkInterface::defaultInterface()
> (qwebnetworkinterface.cpp:890)
> ==7746==by 0x4B38E36: QWebNetworkManager::self()
> (qwebnetworkinterface.cpp:438)
> ==7746==by 0x4AFAFD7: WebCore::ResourceHandle::start(WebCore::Frame*)
> (ResourceHandleQt.cpp:134)
> ==7746==by 0x49E9280:
> WebCore::ResourceHandle::create(WebCore::ResourceRequest const&,
> WebCore::ResourceHandleClient*, WebCore::Frame*, bool, bool, bool)
> (ResourceHandle.cpp:53)
> ==7746==by 0x4970831:
> WebCore::MainResourceLoader::loadNow(WebCore::ResourceRequest&)
> (MainResourceLoader.cpp:377)
>
> QObject is allocating memory for this queued connection that is apparently
> never freed.

I don't believe that is a bug in Qt, I believe this leak is due to the fact 
that the QWebNetworkManager instance (s_manager) is never deleted, and as a 
result the connection is never broken up, so valgrind correctly claims a 
leak :)


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Re: ProjectVision

[Simon Hausmann]

On Friday 23 November 2007 18:31:41 Alp Toker wrote:
> http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diff&versi
>on=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.

Apart from that name of the page what do you think about the content itself?

> 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.

Are you referring to the change to the .pro file that broke "make clean"?

Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving away from qmake

[Simon Hausmann]

On Monday 12 November 2007 14:00:31 Charles Woloszynski wrote:
> I am working on a port of WebKit on Qt to a PowerPC platform.  Please
> make sure that we don't break the Qt port in this switch.  I am
> comfortable with autotools, so that is not a big deal for me.  I am
> concerned, however, that this will cause a fork with the work being
> done by the Trolltech folks (since I think that they are primarily
> qmake-promoters).
>
> Can we get some feedback from Trolltech on their ability to accept a
> switch to autotools for Webkit/Qt so we can switch to one new engine
> for all these ports?

Trolltech is likely to continue to use the qmake based build system for now. 
That is because we are working on integrating WebKit into the build of Qt 
itself (which is built using qmake) and we need to be able to build WebKit 
without cygwin or bash installed on Windows.

Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] QtWebKit build failed

[Simon Hausmann]

On Thursday 08 November 2007 10:31:28 william lee wrote:
> ../../../WebKit/qt/Api/qwebsettings.cpp:179: error: 'class
> QList' has no member named 'removeOne'
>
> removeOne has been added into QList in Trunk code, prepare for Qt4.4.
> The currrent released Qt4.3 don't have this member function.
>
> All of us are supposed to update Qt with Trunk?  We bought a
> commercial license, and that may conflict with other libs.

We'll try to keep trunk compiling with Qt 4.3, the removeOne change was an 
accident (the build bots use Qt 4.4 snapshots). Holger has a patch ready that 
I think will land shortly. Until then you can safely replace the call to 
removeOne with a call to removeAll.


Simon


signature.asc
Description: This is a digitally signed message part.
___
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?

[Simon Hausmann]

On Tuesday 09 October 2007 06:29:36 Oliver Hunt wrote:
[...]
> 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.

Sounds great, I can't wait for WebKit to switch to Git :)


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Branch Plan

[Simon Hausmann]

On Thursday 11 October 2007 00:47:56 Maciej Stachowiak wrote:
[...]
> If anyone has comments or objections, let me know. We will likely pull
> the trigger on this tomorrow afternoon (US Pacific time).

Sounds nice :). I think with the Qt port we're likely to track the 
safari-3-branch to work on a stable code basis.

On that note: It would be cool to also have the safari-3-branch mirrored in 
Adam's git repository ( git://git.webkit.org/WebKit.git ) :)


Simon


signature.asc
Description: This is a digitally signed message part.
___
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

[Simon Hausmann]

On Friday 14 September 2007 02:56:02 Adam Treat wrote:
> 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...

We do plan to provide a buildbot that builds QtWebKit on Windows.

Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] build QTwebkit errors on windows

[Simon Hausmann]

On Monday 27 August 2007 06:59:47 Adam Roben wrote:
> On Aug 26, 2007, at 9:12 PM, [EMAIL PROTECTED] wrote:
> > hi,all
> > Is there anybody knows this error :
> >
> > ./tmp\HTMLFormElement.o:HTMLFormElement.cpp:(.text+0x41d7):
> > undefined reference
> > to [EMAIL PROTECTED]'
> > collect2: ld returned 1 exit status
> > mingw32-make[2]: *** [..\lib\QtWebKit.dll] Error 1
> > mingw32-make[2]: Leaving directory `C:/cygwin/home/en/WebKit/
> > WebKitBuild/Release
> > /WebCore'
> > mingw32-make[1]: *** [release] Error 2
> > mingw32-make[1]: Leaving directory `C:/cygwin/home/en/WebKit/
> > WebKitBuild/Release
> > /WebCore'
> > mingw32-make: *** [sub-WebCore-make_default-ordered] Error 2
> > Your vendor has not defined POSIX macro WEXITSTATUS, used at build-
> > webkit line 1
> > 41
> >
> > Build Instructions for the QtWebKit build on Windows
> > http://trac.webkit.org/projects/webkit/wiki/BuildingQtOnWindows
>
> Sounds like the build is legitimately broken. It would be great if
> you could file a bug at !
>
> I think we have two options here:
>
> 1) Make the Windows Qt build link against shlwapi.lib (the library
> that defines PathFindFileName)
> 2) Change the call to PathFindFileName to only be #if PLATFORM(WIN)
> (currently it's PLATFORM(WIN_OS), which includes Qt), and make a
> PLATFORM(QT) version.
>
> I don't know which is the better choice for the Qt build. Perhaps
> Lars or Simon have a better idea?

I like the latter idea :)


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Different ways to build WebKit on Windows

[Simon Hausmann]

On Tuesday 31 July 2007 14:52:23 Artem Ananiev wrote:
> Hi, all,
>
> currently WebKit is built on Windows platform using Visual Studio
> solution file:
>
>$(WebKitDir)/WebKit/win/WebKit.vcproj/WebKit.sln
>
> However, sometimes it's not easy to deal with .sln or .vcproj files, so
> the question is: is it possible to to build WebKit on Windows platform
> using, for example, Makefiles? If the solution above is generated with
> qmake, it should be possible to generate the corresponding Makefiles
> using the same qmake. Unfortunately, I'm not an expert in qmake and
> don't know if it is possible.

The .sln file is unrelated to the Qt build and its use of qmake. The Qt build 
on Windows right now only supports Makefiles (using nmake or mingw-make). 
QMake itself can also generate Visual Studio project files but we haven't 
tested these yet with WebKit. We will try to get them working at some point 
though, it might just need a few small fixes when calling the perl scripts.


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] type of JSChar

[Simon Hausmann]

On Friday 27 July 2007 11:51:40 Simon Hausmann wrote:
[...]
> JavaScriptCore/API/JSStringRef.h:
>
> ...
> #if !defined(WIN32) && !defined(_WIN32)
> typedef unsigned short JSChar;
> #else
> typedef wchar_t JSChar;
> #endif
> ...

Quick wrap-up: We changed UChar in the Qt build on Windows to be also defined 
to wchar_t now. We removed the BUILDNG_QT #ifdef in API/JSStringRef.h.


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] type of JSChar

[Simon Hausmann]

Hi,

during our work on making the Qt port of WebKit compile on Windows with MSVC 
and MingW g++ we ran into the following code in 
JavaScriptCore/API/JSStringRef.h:

...
#if !defined(WIN32) && !defined(_WIN32)
typedef unsigned short JSChar;
#else
typedef wchar_t JSChar;
#endif
...

JSChar being defined as wchar_t caused compiles problems for us inside WebCore 
itself when converting from JSChar to UChar. For now we added a || 
defined(__BUILDING_QT) to the condition, but we're wondering why JSChar is 
defined as wchar_t on Windows in the first place. We ran into this problem 
only when compiling with g++, MSVC seems to silently convert wchar_t to 
unsigned short.

Unfortunately the svn history does not provide anything regard this #ifdef 
since it was added to the svn repository.

Does anybody know/remember why JSChar is defined to wchar_t on Windows and if 
it is still needed?


Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Qt: run-webkit-tests Segmentation Fault

[Simon Hausmann]

On Saturday 26 May 2007 00:37:09 Reem Yazigi wrote:
> Hello,
> Is anyone else having a problem with running the layout tests on Qt (build:
> 21288)? I'm getting "Segmentation Fault" every time I try to run
> "run-webkit-tests"!! The script is trying to access more than 5,000 test
> cases (it was accessing about 4,100 test cases in the older builds!). I
> think one of the new test cases "run-webkit-tets" is trying to run is
> causing this "Segmentation Fault" error!! Please let me know your thoughts.

The crashes you see have been fixed in revision 21751/21752.

Simon


signature.asc
Description: This is a digitally signed message part.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev