Re: [webkit-dev] Sunsetting committership and reviewership
On Sunday 7. April 2013 18.27.14 Benjamin Poulain wrote: On Sun, Apr 7, 2013 at 6:07 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com 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
[webkit-dev] gap in github WebKit mirror?
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] Heads-up: C++11 and WebKit2
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?
On Tuesday, February 12, 2013 03:07:33 AM Dirk Pranke wrote: On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org 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] Common build system (was Re: WebKit Wishes)
On Monday, February 04, 2013 10:57:46 AM Maciej Stachowiak wrote:
On Feb 4, 2013, at 10:46 AM, Mark Mentovai m...@chromium.org 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
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
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
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 halley.z...@intel.com
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 +++
b/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cp
p @@ -305,7
Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wednesday, July 18, 2012 12:53:35 PM ext Benjamin Poulain wrote: On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@tomeuvizoso.net 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
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
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?
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 kpias...@rim.com wrote: It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. But can you enforce in the server? To avoid people to push it by mistake? Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Carlos Garcia Campos [mailto:carlo...@webkit.org] Sent: Thursday, March 08, 2012 12:27 PM To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Moving to Git? El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió: On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com wrote: In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition. I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly. Re-evaluating the situation is good, but I'm still opposed. I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste). I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P) Then for everything else I use git and its power locally. I would be more than happy with the switch :-) -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- 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
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
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
[webkit-dev] DOM Touch Event Support
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
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
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
Re: [webkit-dev] Qtish API for JavaScriptCore
On Thursday 27 August 2009 10:09:38 am ext Kalle Vahlman wrote: 2009/8/26 Simon Hausmann hausm...@kde.org: 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] About Integrating JIT for ARM into QT Webkit(QTE4.5.2)?
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))
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
On Wednesday 02 July 2008 09:40:19 Jörg Bornemann wrote:
Hi Darin,
Thanks for your detailed comments!
Adding windows.h 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
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. -IForwardingHeaders -Iplatform -Iplatform\network -I platform\graphics -Iloader -Ipage -Icss -Idom -Ibridge -Iediting - Irendering -Ihistory -Ixml -Ihtml -I..\..\..\..\include\QtWebKit -Itm p -Igenerated -Itmp -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 -Ic:\Qt\4.4.0\src\3rdparty\webkit\WebKitBuild\Debug\JavaScriptCo re\kjs\tmp -Iplatform\qt -Iplatform\network\qt -Iplatform\graphics\qt -I platform\graphics\svg\qt -Iloader\qt -Ipage\qt -I..\WebKit\qt\WebCoreSuppo rt -I..\WebKit\qt\Api -I. -IForwardingHeaders -I..\..\webkit -I..\Java ScriptCore\kjs -I..\JavaScriptCore\bindings -Iplatform -Iplatform\network -Iplatform\graphics -Iplatform\graphics\svg -Iplatform\graphics\svg\filter s -Iloader -Iloader\icon -Icss -Idom -Ipage -Ibridge -Iediting -I rendering -Ihistory -Ixml -Ihtml -Ibindings\js -Iksvg2 -Iksvg2\css -Iksvg2\svg -Iksvg2\misc -Iksvg2\events -Iplatform\image-decoders -Ic: \Qt\4.4.0\include\ActiveQt -Itmp\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 '(const UChar)' NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\c l.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\n make.exe' : return code '0x2' Stop. NMAKE :
[webkit-dev] Re: QWebNetworkManager triggering a memleak in Qt
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(QListQByteArray const) (qobject.cpp:67) ==7746==by 0x5D82E5A: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2567) ==7746==by 0x80513D2: QObject::connect(QObject const*, char const*, char const*, Qt::ConnectionType) const (qobject.h:291) ==7746==by 0x4B38C6C: QWebNetworkManager::QWebNetworkManager() (qwebnetworkinterface.cpp:432) ==7746==by 0x4B38D5F: QWebNetworkInterface::QWebNetworkInterface(QObject*) (qwebnetworkinterface.cpp:906) ==7746==by 0x4B38DE6: QWebNetworkInterface::defaultInterface() (qwebnetworkinterface.cpp:890) ==7746==by 0x4B38E36: QWebNetworkManager::self() (qwebnetworkinterface.cpp:438) ==7746==by 0x4AFAFD7: WebCore::ResourceHandle::start(WebCore::Frame*) (ResourceHandleQt.cpp:134) ==7746==by 0x49E9280: WebCore::ResourceHandle::create(WebCore::ResourceRequest const, WebCore::ResourceHandleClient*, WebCore::Frame*, bool, bool, bool) (ResourceHandle.cpp:53) ==7746==by 0x4970831: WebCore::MainResourceLoader::loadNow(WebCore::ResourceRequest) (MainResourceLoader.cpp:377) QObject is allocating memory for this queued connection that is apparently never freed. 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
On Friday 23 November 2007 18:31:41 Alp Toker wrote: http://trac.webkit.org/projects/webkit/wiki/ProjectVision?action=diffversi 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
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] Should we consider switching to git over svn?
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] build QTwebkit errors on windows
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 http://bugs.webkit.org/! 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
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
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
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
