[webkit-dev] Re: Moving away from qmake
Mike Emmel wrote: Here is my autoconf build files They are for my current projects but I think they could readily be cleaned up to b used with the standard build. I found that having a single Makefile did not incur any performance problems. Mike, just had a look over this and it's looking like a good start. Thanks! Was wondering, do you have any fixes to the Cairo graphics or CURL http backends in your tree, or anything that might be useful to WebKit upstream? If you provide your HTTP fixes, for example, I'll have more time to fix the remaining Cairo SVG bugs, which you can then pull back into your private branch, so everyone wins. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: Moving away from qmake
Yes I rewrote the Curl code to use the new callback api's so you can
use select in the main thread.
Also the Pleyo people have done some work I've not fully integrated so
their work is worth looking at.
I ran into some issues and dropped back for the time being to a full
load on each call. Its a nice debugging feature anyway.
Also the latest curl uses asynchronous DNS resolution a huge win.
The biggest problem with Curl right now is that completion messages
still have to be polled for I was going to talk with the curl guys and
patch so you can register a callback.
Attached is my current curl the new stuff is turned off and I'm just loading.
Also this has some nice code in it esp for gtk that binds curl to the
gtk event loop.
http://www.gnomefiles.org/app.php/gCurl
If you read the code and think about the problem that the completion
messages get put on a queue inside curl
and you have to poll for them then you will see why I really want to
fix this in curl.
Also I seemed to be crashing inside curl sometimes with this turned on.
On Nov 12, 2007 12:11 AM, Alp Toker [EMAIL PROTECTED] wrote:
Mike Emmel wrote:
Here is my autoconf build files
They are for my current projects but I think they could readily be
cleaned up to b used with the standard build.
I found that having a single Makefile did not incur any performance
problems.
Mike, just had a look over this and it's looking like a good start. Thanks!
Was wondering, do you have any fixes to the Cairo graphics or CURL http
backends in your tree, or anything that might be useful to WebKit upstream?
If you provide your HTTP fixes, for example, I'll have more time to fix
the remaining Cairo SVG bugs, which you can then pull back into your
private branch, so everyone wins.
/*
* Copyright (C) 2004, 2006 Apple Computer, Inc. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE COMPUTER, INC. OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef ResourceHandle_h
#define ResourceHandle_h
#include AuthenticationChallenge.h
#include HTTPHeaderMap.h
#include wtf/OwnPtr.h
#if PLATFORM(WIN)
typedef unsigned long DWORD;
typedef unsigned long DWORD_PTR;
typedef void* LPVOID;
typedef LPVOID HINTERNET;
typedef unsigned WPARAM;
typedef long LPARAM;
typedef struct HWND__* HWND;
typedef _W64 long LONG_PTR;
typedef LONG_PTR LRESULT;
#endif
#if PLATFORM(MAC)
#include wtf/RetainPtr.h
#ifdef __OBJC__
@class NSData;
@class NSError;
@class NSURLConnection;
@class WebCoreResourceHandleAsDelegate;
#else
class NSData;
class NSError;
class NSURLConnection;
class WebCoreResourceHandleAsDelegate;
typedef struct objc_object *id;
#endif
#endif
#if USE(CFNETWORK)
typedef struct _CFURLConnection* CFURLConnectionRef;
typedef int CFHTTPCookieStorageAcceptPolicy;
typedef struct OpaqueCFHTTPCookieStorage* CFHTTPCookieStorageRef;
#endif
#if USE(CURL)
typedef struct CURLMsg CURLMsg;
#endif
namespace WebCore {
class AuthenticationChallenge;
class Credential;
class FormData;
class Frame;
class KURL;
class ResourceError;
class ResourceHandleClient;
class ResourceHandleInternal;
class ResourceRequest;
class ResourceResponse;
class SharedBuffer;
class SubresourceLoader;
class SubresourceLoaderClient;
template typename T class Timer;
class ResourceHandle : public SharedResourceHandle {
private:
ResourceHandle(const ResourceRequest, ResourceHandleClient*, bool defersLoading, bool mightDownloadFromHandle);
public:
// FIXME: should not need the Frame
static PassRefPtrResourceHandle create(const ResourceRequest, ResourceHandleClient*, Frame*, bool defersLoading, bool mightDownloadFromHandle = false);
static void loadResourceSynchronously(const ResourceRequest, ResourceError, ResourceResponse, Vectorchar data);
static bool willLoadFromCache(ResourceRequest);
Re: [webkit-dev] Moving away from qmake
On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Origyn BAL abstraction for WebKit: branch request
Dear webkit stakeholders Back in july, Pleyo announced a new port of Webkit, not onto a specific platform but over an Abstraction Layer that we called OwBAL and which lets us address specific needs which do not perfectly fit with the platform approach. Actually, our goals are to be able to adapt WebKit not to a platform, but a set of libraries which can be all-but-one identical, or completely different, or whatever. Platform approach makes sense when porting to a comprehensive environment, but it does not address our needs. So that platform made big parts of the code redundant for us. Today, our abstraction code is almost mature and we'd like to move it back to webkit.org. I believe that since our changes are quite intrusive in many parts of webcore, jscore and platform, a branch could be a good start where we could put the code so that we can start advocating some (if not all) of our changes to eventually end up being part of webkit trunk. Can anyone tell me how to process? Best regards, Jean-Charles -- Jean-Charles Verdié A question for you: www.pleyo.com Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)
Mike Hommey wrote: On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. I can go into the issues here a bit further, though it doesn't directly relate to the choice of build system. When it comes to platform-specific code in JavaScriptCore, the most obvious issue is the set of platform/language bindings. Luckily the fix for this is pretty obvious, and I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=15931 Eliminate Instance::createBindingForLanguageInstance() The other instance of platform specific code that I can see is Qt's use of Unicode functionality, while other ports tend to use ICU. I've actually been planning to port the Unicode abstraction to use GLib, since ICU is a very heavy dependency for non-desktop systems. (There is potential to shave up to 10M off the distribution size of the GTK+ port for mobile devices here.) This is however a thankless job that nobody else seems to be interested in doing and I've put it off till now: http://bugs.webkit.org/show_bug.cgi?id=15914 [GTK] Implement Unicode functionality using GLib So this would actually be a step away from re-usability as a shared library but a step towards a lower mobile memory footprint. There are a few other bits of Qt-specific code such as that in DateMath, but these do not seem significant, and if the other two issues were fixed I imagine the Qt developers would be happy to compromise on those. As long as ports work to avoid ICU for Unicode functionality, I don't think we're going to get around to genuinely sharing JavaScriptCore, and to be honest, I don't see this being a real problem. How many people will run Konqueror and Epiphany at the same time (for reasons other than testing)? Will those people who do regularly use both Konqueror and Epiphany miss the 1-2M that could have been shared given that the complete applications are taking at least 10M each? So while I think there is the possibility of having a standalone JavaScriptCore edition embedding into applications, I do not think there is any immediate hope of having a single JavaScriptCore library shared between ports. Lots of effort for minimal gain. The real benefit in having a standalone build profile for JavaScriptCore in my use case was that it made it far more practical to hack on the new CLR/JavaScript binding. This would have been really unpleasant if I had to build and link the whole of WebKit each time I made a change. I think that lowering the barrier for new JS bindings alone is a good cause for having a modular JavaScriptCore build target, but maybe I'm the only one developing new JS bindings right now? As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike You and I have learnt how to deal with qmake, but I've recently discovered that casual contributors and potential adopters in GNOME are taking one look at the qmake build system and turning around. It also seems to be antagonising people who use source-based distributions like Gentoo and who would otherwise never have a reason to take an hour out of their lives building the whole of Qt. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. I'm one person with a highly niche port, but for what its worth I'd support a move to autotools. I'm doing a port to AROS, which currently means cross-building WebKit on Linux. I opted to use qmake because it was the easiest one to get set up in a hurry (I have a little GTK+ experience so I could see how to cobble together what I needed from the gtk-port stuff). Getting the cross-compile happening is a bit of a hack though, and qmake docs are rather thin. If qmake is as hard to get hold of as you say (I don't actually know, my distribution had it packaged), then I really don't want to put that on my developers. Besides, eventually we will want to be able to develop WebKit natively on AROS. Its highly non-POSIX, but we already have ports of most of the tools need to do configure stuff. Since QT is not something we'll ever need, a port isn't likely to appear. Also cross-building is something I already know how to do with autotools, which will mean less effort for me getting it set up. 2c. Cheers, Rob. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
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? Thanks, Charlie On Nov 12, 2007, at 7:14 AM, Robert Norris wrote: If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. I'm one person with a highly niche port, but for what its worth I'd support a move to autotools. I'm doing a port to AROS, which currently means cross-building WebKit on Linux. I opted to use qmake because it was the easiest one to get set up in a hurry (I have a little GTK+ experience so I could see how to cobble together what I needed from the gtk-port stuff). Getting the cross-compile happening is a bit of a hack though, and qmake docs are rather thin. If qmake is as hard to get hold of as you say (I don't actually know, my distribution had it packaged), then I really don't want to put that on my developers. Besides, eventually we will want to be able to develop WebKit natively on AROS. Its highly non-POSIX, but we already have ports of most of the tools need to do configure stuff. Since QT is not something we'll ever need, a port isn't likely to appear. Also cross-building is something I already know how to do with autotools, which will mean less effort for me getting it set up. 2c. Cheers, Rob. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Charles Woloszynski Innovative Concepts, Inc. Sr. Director, Advanced Networking Systems [EMAIL PROTECTED] (703) 893-2007 x506 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hello, Here is my experience with cmake, so I hope it may help you to decide which build system is the best for you. Its first advantage is that it is cross platform. So you can imagine in a long term approach to have a unified build system between GTK/Qt/Wx/Win and mac. Another advantage is that it is from my point of view quite simple to understand and to use for basic stuff like adding a library dependency to the build. Moreover there are many ready to use macro to ease this work. As an example, if you want to add a dependency with JPEG library, use FindJPEG module and it will store useful info in variables like JPEG_LIBRARIES. About documentation, well simply have a look at http://www.cmake.org/HTML/Documentation.html page, it should convince you. Another feature I like are curses interfaces for your project configuration (you can switch options, compiler flags and even compiler). And of course you do not have to rebuild the whole project each time you modify things. And if things are done correctly you do not even have to rebuild the whole project when you add a new feature. Imagine that you have built WebKit/GTK without SVG support and you want to add it. It can simply recompile svg missing .o and of course redo linking. Of course that's not true if you switch from a debug build option to a release build. Of course from time to time you may have to rebuild the whole project because you have modify things in cmake config files. Another insteresting features is that cmake allow you to create a build directory where will be stored all your object files. So your source tree remains clean. About drawbacks, the main is about cross-compilation. I know that cmake guys work on this issue but currently I still have to do ugly things when I cross compile webkit because of dftables. As a matter of fact dftables is also cross-compiled and when you try to run an ARM dftables exec on a x86 arch, it cannot work. But I hope I will be able to fix this soon. The more people are involved in Cmake process, the more we get chances to overcome these little issues. The other drawback you can have is that you will have to compile/install cmake when you are in a scratchbox environment. And if you want to give a try to cmake alternative, let me know, I can provide you files to compile WebCore/JavascriptCore with cmake. And I can also try to help you to meet your goal. Regards, De : Alp Toker [EMAIL PROTECTED] Date : 12 novembre 2007 04:34:48 HNEC À : [EMAIL PROTECTED] Objet : [webkit-dev] Moving away from qmake The existing qmake-based build system is shared by the GTK+ and Qt ports. Until recently, this arrangement has not been too problematic for the GTK+ porters, with the idea being that qmake makes life easier for developers at the expense of a little inconvenience for users (in the sense of application developers rather than end users). However, it has recently become clear that qmake is actually making life more difficult for developers. It turns out that the existing qmake build system fails to do basic dependency tracking, leaving both developers and users with crashy builds, with the only way to get a stable build being to do a full clean and rebuild after every update. In the last week I've had to explain why people's builds are crashing to maybe half a dozen people on WebKit and GNOME-related channels. Mark and I have attempted to fix the dependency tracking a number of times, but we've both found qmake to be poorly documented, and our attempts to fix it ended up breaking the build even more in certain configurations. My informal attempts to get assistance from the Trolltech guys doing the Qt port have gone unanswered. I have no doubt that we would be able to fix these issues in a matter of minutes using a better understood or documented build system. Moreover, it has turned out that the qmake build dependency is more than just a little inconvenience for users. It makes the GTK+ port inaccessible to a lot of developers. Using anything but the latest Linux distributions, including cross-compilation frameworks like Scratchbox, you have to build the whole of Qt just to get qmake, which takes over an hour and almost a gigabyte of disk space for me. That's at least 5 times as long as it takes to build the whole of JavaScriptCore, WebCore and WebKit. Even in distributions that ship a recent binary of qmake, it is often bundled into the same binary package as the rest of Qt, making it a seriously large dependency. Now that the GTK+ port is getting attention from beyond a core team of developers, I think such a heavy build dependency is no longer acceptable. If either the Wx or Qt porters are willing to share a new build system with the GTK+ port, they should speak up now. We're willing to consider any build system that does not incur a huge dependency (ruling out qmake) and that is actively maintained and does not have verbose XML makefiles (ruling out Bakefile and
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] Moving away from qmake
On 13/11/2007, at 00:00, 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? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Ok, thanks for the feedback. I have had some issues with the cross- compilation of WebKit (dftables being built for the cross-platform, not the native platform). Any chance I can get someone doing the WebKit Qt port to address this? I don't know qmake well enough to make the changes. The defect was there two weeks ago, and I don't think I've seen any changes in that area since... Charlie On Nov 12, 2007, at 8:19 AM, Simon Hausmann wrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Charles Woloszynski Innovative Concepts, Inc. Sr. Director, Advanced Networking Systems [EMAIL PROTECTED] (703) 893-2007 x506 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Planned Subversion and Trac Downtime for webkit.org
Hi all, Just a reminder that the Subversion and Trac downtime is happening in approximately 1 hour 40 minutes, at 8am Pacific time (4pm UTC). When service is restored committers will no longer be able to access the repository via svn+ssh//. Thanks, Mark On 09/11/2007, at 05:57, Mark Rowe wrote: Hi all, On Monday 12 November svn.webkit.org and trac.webkit.org will be offline for up to one hour starting at 8am Pacific time (4pm UTC). The purpose of this outage is to migrate the Subversion-related services to newer hardware. A DNS change will take place while the hardware migration is happening and we hope that this will have propagated completely before the services come back online. One major configuration change will be taking place as a part of the hardware move, though it will only affect developers with commit access to Subversion: Subversion access via svn+ssh:// will not be available after the hardware migration. Committers should all have received instructions via email on how to switch their Subversion access to http://. I would urge all committers to make this switch as soon as possible to ensure that their accounts are working correctly. If you are a committer and are having trouble with this switch or have not received instructions on how to switch, please let me know as soon as is possible. Thanks for your patience, Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re: Focus traversal question
Alp Toker wrote: Artem Ananiev wrote: Hi, Alp, sorry for a slight delay with the answer. I'm not working with GTK port, but rather investigating the possibility of new Java port, on windows, linux and solaris platforms. Artem, For what it's worth, we (informally) evaluated the option of a native CLR port as part of the Mono project. It turns out that while it might be feasible to port some of WebCore to a managed runtime in the space of a few months, the true value of WebKit is that it's an evolving code base with a brilliant and responsive team of devoted core developers, something that is lost when you deviate too far from the existing architecture. So you end up with a browser that no longer gets essential site compatibility fixes or support for new Web standards unless you recruit a whole new development team. Hi Alp, I think you misunderstood Artem, java port doesn't means rewrite WebKit in Java. Java provides just one more widget toolkit, so java port is the same as qt/gtk port. Regards, Oleg. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Keeping track of supported specs on wiki
Maciej Stachowiak wrote: On Nov 9, 2007, at 5:55 PM, Rob Burns wrote: Hello all, I have to say I like Philippe's version of the page better. I think it is more appropriate for an open source project like webkit. I would agree with Maciej that the word stable might be more appropriate than full. However, I think its better to show all of the standards whether targeted by Apple or not. It might make sense to have an asterisk on the no response to indicate that Apple has no plans to target a particular standard. The set of specs that currently have no support isn't necessarily identical to the set we are not targetting, or the set we would categorically rule out default support for. I think there are pretty few in the last category, and a huge number in the first if you take a broad view of what standards count. I would rather list the standards we *do* currently care about (including things like IETF RFCs, ECMA standards, ISO standards, etc) than try to list a complete or partial list of ones we don't care about. However, I assume other contributors are free to bring standard supports to WebKit. I know of two such projects myself where contributors are working to bring standards support to WebKit not currently targeted by Apple. Perhaps the status column should be one of: • No • No* (not targeted by Apple) • Partial • Stable Again, I'm not sure No adds much value relative things not on this list probably are not currently targetted. I certainly do not want to make a commitment on behalf of either Apple or the whole WebKit project that we won't support particular specs. I don't quite understand how saying No, we are not working on this currently and don't plan to is not valuable, it's an extra piece of information; it allows people to see what direction development is currently moving in. The wiki is not just a tool for Webkit developers, it's a site for everyone. That means potential adopters but also people who are looking to contribute. If someone is interested in support for some spec, he will go on the wiki/website, look at the table, find his spec and see if it's supported, being worked on (by apple or others) or if there are no plans to support it. Then he can decide to either implement that spec or find another solution. If there is no information about his spec, he will be uncertain if it's supported and then go around asking. BR, Philippe Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Planned Subversion and Trac Downtime for webkit.org
Hi all, Subversion and Trac should now be back up and running. Please drop me an email if anything is not working correctly! Thanks, Mark On 13/11/2007, at 01:19, Mark Rowe wrote: Hi all, Just a reminder that the Subversion and Trac downtime is happening in approximately 1 hour 40 minutes, at 8am Pacific time (4pm UTC). When service is restored committers will no longer be able to access the repository via svn+ssh//. Thanks, Mark On 09/11/2007, at 05:57, Mark Rowe wrote: Hi all, On Monday 12 November svn.webkit.org and trac.webkit.org will be offline for up to one hour starting at 8am Pacific time (4pm UTC). The purpose of this outage is to migrate the Subversion-related services to newer hardware. A DNS change will take place while the hardware migration is happening and we hope that this will have propagated completely before the services come back online. One major configuration change will be taking place as a part of the hardware move, though it will only affect developers with commit access to Subversion: Subversion access via svn+ssh:// will not be available after the hardware migration. Committers should all have received instructions via email on how to switch their Subversion access to http://. I would urge all committers to make this switch as soon as possible to ensure that their accounts are working correctly. If you are a committer and are having trouble with this switch or have not received instructions on how to switch, please let me know as soon as is possible. Thanks for your patience, Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)
I refactored all the Unicode handling to run behind a abstract interface. So no direct ICU calls. Its a lot of little patches all over the place and a thankless job. Its a lot of work so email me if your interested. I was also looking at repacling icu with glib/pango. Its not clear you get everything you need from glib so I believe you have to bring in pango which does more than you want. Pango itself needs to be split into text metrics and glyph drawing. On Nov 12, 2007 3:28 AM, Alp Toker [EMAIL PROTECTED] wrote: Mike Hommey wrote: On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. I can go into the issues here a bit further, though it doesn't directly relate to the choice of build system. When it comes to platform-specific code in JavaScriptCore, the most obvious issue is the set of platform/language bindings. Luckily the fix for this is pretty obvious, and I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=15931 Eliminate Instance::createBindingForLanguageInstance() The other instance of platform specific code that I can see is Qt's use of Unicode functionality, while other ports tend to use ICU. I've actually been planning to port the Unicode abstraction to use GLib, since ICU is a very heavy dependency for non-desktop systems. (There is potential to shave up to 10M off the distribution size of the GTK+ port for mobile devices here.) This is however a thankless job that nobody else seems to be interested in doing and I've put it off till now: http://bugs.webkit.org/show_bug.cgi?id=15914 [GTK] Implement Unicode functionality using GLib So this would actually be a step away from re-usability as a shared library but a step towards a lower mobile memory footprint. There are a few other bits of Qt-specific code such as that in DateMath, but these do not seem significant, and if the other two issues were fixed I imagine the Qt developers would be happy to compromise on those. As long as ports work to avoid ICU for Unicode functionality, I don't think we're going to get around to genuinely sharing JavaScriptCore, and to be honest, I don't see this being a real problem. How many people will run Konqueror and Epiphany at the same time (for reasons other than testing)? Will those people who do regularly use both Konqueror and Epiphany miss the 1-2M that could have been shared given that the complete applications are taking at least 10M each? So while I think there is the possibility of having a standalone JavaScriptCore edition embedding into applications, I do not think there is any immediate hope of having a single JavaScriptCore library shared between ports. Lots of effort for minimal gain. The real benefit in having a standalone build profile for JavaScriptCore in my use case was that it made it far more practical to hack on the new CLR/JavaScript binding. This would have been really unpleasant if I had to build and link the whole of WebKit each time I made a change. I think that lowering the barrier for new JS bindings alone is a good cause for having a modular JavaScriptCore build target, but maybe I'm the only one developing new JS bindings right now? As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike You and I have learnt how to deal with qmake, but I've recently discovered that casual contributors and potential adopters in GNOME are taking one look at the qmake build system and turning around. It also seems to be antagonising people who use source-based distributions like Gentoo and who would otherwise never have a reason to take an hour out of their lives building the whole of Qt. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote: On 13/11/2007, at 00:00, 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? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. As someone who adds and removes files frequently, I do find the build system proliferation to be a nontrivial cost. However, I think the worst build systems from this point of view are ones that aren't easily human-editable, which I think is mainly the Xcode and Visual Studio project files. If we add more build systems, it would be really helpful to put up a page that tells you what steps you should take if you add or remove files. Maybe we could even write a script to add a file to or remove a file from all build systems. Regards, Maciej ___ 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 Nov 12, 2007, at 11:33 AM, Maciej Stachowiak wrote: On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote: On 13/11/2007, at 00:00, 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? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. As someone who adds and removes files frequently, I do find the build system proliferation to be a nontrivial cost. However, I think the worst build systems from this point of view are ones that aren't easily human-editable, which I think is mainly the Xcode and Visual Studio project files. If we add more build systems, it would be really helpful to put up a page that tells you what steps you should take if you add or remove files. Maybe we could even write a script to add a file to or remove a file from all build systems. I agree. That I can generate those automatically, along with standard makefiles, from a single text source is the reason I stick with qmake on my project. You sometimes have to jump through hoops with qmake, in order to capture complex dependencies or source file generation, but it does it well on all platforms I use, including Windows, and it lets me use the XCode gui on Mac, Visual Studio on Windows, emacs and Make on linux from the same build infrastructure. I've tried cmake, waf, cons, scons and several others that claim to be cross-platform build tools, and not found them capable enough, especially when it comes to targeting Windows development. Cheers, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text- based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Regards, Kevin Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Jean-Charles -- Jean-Charles Verdié A question for you: www.pleyo.com Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ 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 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote: Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text- based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Why is that useful? - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Le 12 nov. 07 à 21:12, Mark Rowe a écrit : On 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote: Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text-based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Why is that useful? I might be wrong but I think it's useful to be able to generate, from the same sources and using a CMake facility, an Xcode project (to work under XCode on Mac), a VS project, a CMakeFile for linux-based solutions, - Mark -- Jean-Charles Verdié A question for you: www.pleyo.com Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Apple needs to use native Xcode and VS projects to work with existing build systems. So generating an Xcode or VS project is not useful. On Nov 12, 2007, at 12:20 PM, Jean-Charles VERDIE (Pleyo) wrote: I might be wrong but I think it's useful to be able to generate, from the same sources and using a CMake facility, an Xcode project (to work under XCode on Mac), a VS project, a CMakeFile for linux- based solutions, — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
We could add a script that would add/remove/rename files in all the project files for the various build systems. On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hi David, On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. Right, in fact, I actually wrote a fair chunk of the XCode backend for Bakefile, so I do remember the basics of the format, although my memory is a bit hazy. :-) But the issue I saw with that approach is that adding a file doesn't just mean inserting a file entry, XCode uses UUIDs to refer to files and creates hierarchies of UUIDs to manage folder hierarchies and the like. So to add a file to a certain project folder, you'd have to retrieve the UUID of the parent folder the file is to be inserted into, along with any parent folders for that folder to know which PBXGroup in the project file you should insert the new file's UUID into, and I don't know how we can get that info without parsing the file and folder listing out of the XCode project file. It seems there would be similar issues with adding/ removing a folder from the project file. In short, I'm not sure we could get away with making those changes reliably without parsing at least some chunks of the project file, if not most of it. (WebCore.xcodeproj/project.pbxproj, for example, largely consists of file references and folder organization.) However, I have to admit I haven't seriously thought about the matter before today, so it's possible I'm missing or overlooking something important. Any ideas of how we could do this more simply? Thanks, Kevin Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proof of Concept: NPAPI plugins in Qt/Windows
Question, does this require MSVC compiliers, or will the MinGW compilers work fine? I'm having the issues with certain the _countof struct not being defined. c On 11/10/07, Justin Haygood [EMAIL PROTECTED] wrote: I've updated the patch :) http://blog.reaktix.com/2007/11/10/plugins-in-qtwebkit-for-windows/ From the blog post: 2 major issues remaining: 1. Windowed plugins don't scroll with the content 2. Windowless plugins draw with the wrong coordinates ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re: Moving away from qmake (aka. modularising JavaScriptCore)
Mike Emmel wrote: I refactored all the Unicode handling to run behind a abstract interface. So no direct ICU calls. Its a lot of little patches all over the place and a thankless job. Its a lot of work so email me if your interested. I was also looking at repacling icu with glib/pango. Its not clear you get everything you need from glib so I believe you have to bring in pango which does more than you want. Pango itself needs to be split into text metrics and glyph drawing. It's also worth mentioning the new HarfBuzz library: http://www.freedesktop.org/wiki/Software/HarfBuzz It's pretty simple to follow the API if you check out the git repository. It's done in the style of FreeType which is kind of cute. HarfBuzz can certainly be used to do some of the text handling in WebCore. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
