Re: [webkit-dev] Pulling together on WebKit Mobile
My vote would be to use #if PLATFORM(XX) to wrap relevant source files, and to create new Configurations to choose which libraries to link to. I think this is the simplest while still providing the functionality we need: -we must have the ability to link to different libraries for different builds, so that we can not link with, for example, CoreGraphics or Cairo -we do not want to have to maintain multiple project files -the #pragma comment code below looks like it gets too spaghetti-ish too quickly Cheers, Dan On Jan 16, 2008, at 2:19 PM, [EMAIL PROTECTED] wrote: You can solve this by creating additional configurations in the same VS projects/solution. Configurations are set up to let you choose different link libraries for different targets. The different targets can also set different #defines to select CG vs Cairo, etc. Personally I don't like this so much since it is a pain to maintain multiple configurations, but it does solve the problem for selecting different libraries to link. Cheers, Dan This was a non-issue for Cairo, since it was completely contained in our source tree (and not externally linked against). That was less than ideal though, and you still had the linking problem in the other direction (with CG always being linked against). dave You can link against different libraries using the Visual Studio #pragma comment feature, e.g.: #pragma comment(lib, wininet.lib) This works, but if you want to link against debug and other variants, you quickly end up with a mess like: #ifdef _DEBUG #ifdef _UNICODE_ #pragma comment (lib, coollibDU.lib) #else #pragma comment (lib, coollibD.lib) #endif #else #ifdef _UNICODE_ #pragma comment (lib, coollibU.lib) #else #pragma comment (lib, coollib.lib) #endif #endif I think for us to have a viable native windows port, we need to be able to link against a pre-built Cairo libraries. I am just not looking forward to having to create multiple targets in the project files, as this will involve figuring out how to pass this along from the build-webkit script, etc., etc. But can we decide on a course of action soon? I'd like to generate a patch that gets the win32 (native) target to build soon, but I don't want to spend too much time on a dead-end. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non-CG target. 3. ? -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? --Oliver -Brent ___ 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] Pulling together on WebKit Mobile
At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? The problem though is that in addition to excluding various CG files, we probably need to compile some new Cairo-win32-based implementations. I'll see if I can figure out how to get VS to exclude files (but I think this may boil down to creating new projects inside the solution for CG-vs-native). -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
I like the idea of just wrapping those files with #if PLATFORM(CG). It's slightly messy, but it works and it simplifies managing a complex VS project file. Cheers, Dan Original Message Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile Date:Wed, January 16, 2008 1:54 pm -- On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? --Oliver -Brent ___ 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 -- Forwarded message --From: Oliver Hunt [EMAIL PROTECTED]Date: Jan 16, 2008 1:37 PM Subject: Re: [webkit-dev] Pulling together on WebKit MobileTo: Brent Fulgham [EMAIL PROTECTED]Cc: webkit-dev@lists.webkit.org On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dans advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a native windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studios environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as notImplemented(). At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. Im not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ?Possibly worth putting #if PLATFORM(CG) around SG paltform files, buti also cant think of a nice way to work around this -- does anyoneknow if you can make VS recognise some files as being for one target only?--Oliver -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev___ webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://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] Pulling together on WebKit Mobile
This is how we did it when we (briefly) had CG and Cairo compiling simultaneously. The problem with it though is that we had a copy of Cairo in our source tree and ended up having to hack the Cairo source to put #if PLATFORM(CAIRO) around those files. If Cairo is going to be brought in externally, that could be an issue. dave ([EMAIL PROTECTED]) On Jan 16, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote: I like the idea of just wrapping those files with #if PLATFORM(CG). It's slightly messy, but it works and it simplifies managing a complex VS project file. Cheers, Dan Original Message Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile Date:Wed, January 16, 2008 1:54 pm -- On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? --Oliver -Brent ___ 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 untitled-2.html___ 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] Pulling together on WebKit Mobile
On Jan 16, 2008, at 5:04 PM, David Hyatt wrote: This is how we did it when we (briefly) had CG and Cairo compiling simultaneously. The problem with it though is that we had a copy of Cairo in our source tree and ended up having to hack the Cairo source to put #if PLATFORM(CAIRO) around those files. If Cairo is going to be brought in externally, that could be an issue. And in general, #ifdefing the contents of source files doesn't solve the problem of choosing which libs to link against. -Adam On Jan 16, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote: I like the idea of just wrapping those files with #if PLATFORM(CG). It's slightly messy, but it works and it simplifies managing a complex VS project file. Cheers, Dan Original Message Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile Date:Wed, January 16, 2008 1:54 pm -- On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? --Oliver -Brent ___ 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 untitled-2.html___ 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] Pulling together on WebKit Mobile
You can solve this by creating additional configurations in the same VS projects/solution. Configurations are set up to let you choose different link libraries for different targets. The different targets can also set different #defines to select CG vs Cairo, etc. Personally I don't like this so much since it is a pain to maintain multiple configurations, but it does solve the problem for selecting different libraries to link. Cheers, Dan This was a non-issue for Cairo, since it was completely contained in our source tree (and not externally linked against). That was less than ideal though, and you still had the linking problem in the other direction (with CG always being linked against). dave On Jan 16, 2008, at 4:10 PM, Adam Roben wrote: On Jan 16, 2008, at 5:04 PM, David Hyatt wrote: This is how we did it when we (briefly) had CG and Cairo compiling simultaneously. The problem with it though is that we had a copy of Cairo in our source tree and ended up having to hack the Cairo source to put #if PLATFORM(CAIRO) around those files. If Cairo is going to be brought in externally, that could be an issue. And in general, #ifdefing the contents of source files doesn't solve the problem of choosing which libs to link against. -Adam On Jan 16, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote: I like the idea of just wrapping those files with #if PLATFORM(CG). It's slightly messy, but it works and it simplifies managing a complex VS project file. Cheers, Dan Original Message Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile Date:Wed, January 16, 2008 1:54 pm -- On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: I took Dan's advice, and modified my config.h as follows: #if PLATFORM(WIN) #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 #define WTF_USE_NPOBJECT 1 #undef WTF_PLATFORM_CG #define WTF_PLATFORM_CAIRO 1 #undef WTF_USE_CFNETWORK #define WTF_USE_WININET 1 #undef WTF_PLATFORM_CF #define WTF_USE_PTHREADS 0 #endif asideWe should probably come up with a new name for a 'native' windows build, such as used by Adobe/AIR, Windows mobile, and a true native Windows build./aside I also modified Visual Studio's environment to find the Cairo headers and link libraries. I then started build-webkit and went and did other things for about an hour. The build produces quite a few errors, many of which are just CG-isms that I conditionalized away. In a few cases, I resurrected the old Cairo backend code, in others I just marked them as 'notImplemented()'. At this point, the remaining errors are due to the Visual Studio project compiling the CG modules. I'm not sure how best to approach this: 1. Create a brand new project for non-CG Windows 2. Create new build targets in the existing solution for the non- CG target. 3. ? Possibly worth putting #if PLATFORM(CG) around SG paltform files, but i also can't think of a nice way to work around this -- does anyone know if you can make VS recognise some files as being for one target only? --Oliver -Brent ___ 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 untitled-2.html___ 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] Pulling together on WebKit Mobile
On Jan 16, 2008, at 2:19 PM, [EMAIL PROTECTED] wrote: You can solve this by creating additional configurations in the same VS projects/solution. Configurations are set up to let you choose different link libraries for different targets. The different targets can also set different #defines to select CG vs Cairo, etc. Personally I don't like this so much since it is a pain to maintain multiple configurations, but it does solve the problem for selecting different libraries to link. Cheers, Dan This was a non-issue for Cairo, since it was completely contained in our source tree (and not externally linked against). That was less than ideal though, and you still had the linking problem in the other direction (with CG always being linked against). dave You can link against different libraries using the Visual Studio #pragma comment feature, e.g.: #pragma comment(lib, wininet.lib) This works, but if you want to link against debug and other variants, you quickly end up with a mess like: #ifdef _DEBUG #ifdef _UNICODE_ #pragma comment (lib, coollibDU.lib) #else #pragma comment (lib, coollibD.lib) #endif #else #ifdef _UNICODE_ #pragma comment (lib, coollibU.lib) #else #pragma comment (lib, coollib.lib) #endif #endif I think for us to have a viable native windows port, we need to be able to link against a pre-built Cairo libraries. I am just not looking forward to having to create multiple targets in the project files, as this will involve figuring out how to pass this along from the build-webkit script, etc., etc. But can we decide on a course of action soon? I'd like to generate a patch that gets the win32 (native) target to build soon, but I don't want to spend too much time on a dead-end. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Communication (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 14, 2008, at 8:02 PM, Adam Roben wrote: Oliver Hunt wrote: On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. It's been mentioned (by some of the Trolltech folks, I believe) that using IRC so exclusively for communication not only makes it very easy for information to be lost into the aether but is also difficult for those not operating on California (or US) time. Perhaps we should be making an effort to have more of our discussions take place on webkit-dev, at the very least in the cases where they originate on webkit-dev as well? We could also consider logging the IRC channel. This is something I've been hesitant to do before, but it makes asynchronous participation easier, and that's important as we span more time zones and get more people involved in the project part-time. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Communication (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Le mardi 15 janvier 2008 à 01:19 -0800, Maciej Stachowiak a écrit : On Jan 14, 2008, at 8:02 PM, Adam Roben wrote: Oliver Hunt wrote: On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. It's been mentioned (by some of the Trolltech folks, I believe) that using IRC so exclusively for communication not only makes it very easy for information to be lost into the aether but is also difficult for those not operating on California (or US) time. Perhaps we should be making an effort to have more of our discussions take place on webkit-dev, at the very least in the cases where they originate on webkit-dev as well? We could also consider logging the IRC channel. This is something I've been hesitant to do before, but it makes asynchronous participation easier, and that's important as we span more time zones and get more people involved in the project part-time. Cheers, Maciej There is also IRC proxies which logs the channel while you are not logged in and sends you the log next time you show up. Personally, I use Bip http://bip.t1r.net/ to make sure I don't miss a thing on #webkit-gtk! But this solution works fine only if you do show up once per day, if not the logs gets a little big (for #webkit anyway). Pierre-Luc Beaudoin aka pierlux ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. Agreed. My point is that if you try to compile now using WININET, CAIRO, etc. instead of CG, CF, CN, you get _lots_ of errors. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? Cheers, Dan On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote: My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. Agreed. My point is that if you try to compile now using WININET, CAIRO, etc. instead of CG, CF, CN, you get _lots_ of errors. What sort of errors? link errors? PLATFORM(QT) can compile on windows, so if PLATFORM(WININET) PLATFORM(CAIRO) fails it implies there is either some code making incorrect assumptions about the PLATFORM, missing file guards, or more likely, unimplemented PLATFORM functionality. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. --Oliver Cheers, Dan On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote: My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On Jan 14, 2008, at 3:48 PM, [EMAIL PROTECTED] wrote: Dear WebKit Team, Going back to the original topic (Pulling together on WebKit Mobile) Wake3 has a working version of WebKit for Windows Mobile. We definitely want to contribute back to the community. We posted earlier about this, but didn't get much of a reply. For more information on Wake3, see the video demo on our website at www.wake3.com. We also gave a live demo at a recent Silicon Valley Mobile Monday event (see our presentation at http://www.mobilemonday.us/?p=188) . We are planning a public Beta in the next few months and we plan to release source then. My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? Last, we will be at the Mobile World Congress (formerly 3GSM Congress) next month in Barcelona. Send email if you want to meet up and see a demo. We might need to have two different versions of the WIN platform. I'd be ok with changing the name of the one based on Apple libraries if appropriate. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Communication (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Oliver Hunt wrote: On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. It's been mentioned (by some of the Trolltech folks, I believe) that using IRC so exclusively for communication not only makes it very easy for information to be lost into the aether but is also difficult for those not operating on California (or US) time. Perhaps we should be making an effort to have more of our discussions take place on webkit-dev, at the very least in the cases where they originate on webkit-dev as well? -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On Jan 14, 2008, at 3:48 PM, [EMAIL PROTECTED] wrote: My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? I for one would love to see this, and am willing to help with that effort. Alp Toker and I have been trying to get the Cairo stuff working properly under Windows, so if you have existing patches (or even a source tree we could run diff's against), I'm ready to roll up my sleeves. It should be possible to begin generating patches against trunk now to get some of these things working cleanly... I look forward to seeing what changes you've made and to helping merge your modifications as quickly as possible. Thanks! -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
This isn't too surprising -- code that isn't used quickly goes stale. But it should be quite possible to fix! Thus, my suggestion to do this work :). Cheers, Dan [EMAIL PROTECTED] wrote: What sort of errors? link errors? As a quick test, I #undef'ed WTF_PLATFORM_CG, WTF_USE_CFNETWORK, and WTF_PLATFORM_CF; and instead #define'd WTF_PLATFORM_CAIRO and WTF_USE_WININET. Building WebCore alone resulted in 389 compile errors. The basic structure of using these #defines seems good. But apparently, when CF, CG, and CFNetwork were added, the previous constructs were badly broken. This isn't too surprising -- code that isn't used quickly goes stale. But it should be quite possible to fix! -Adam On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. Agreed. My point is that if you try to compile now using WININET, CAIRO, etc. instead of CG, CF, CN, you get _lots_ of errors. What sort of errors? link errors? PLATFORM(QT) can compile on windows, so if PLATFORM(WININET) PLATFORM(CAIRO) fails it implies there is either some code making incorrect assumptions about the PLATFORM, missing file guards, or more likely, unimplemented PLATFORM functionality. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. --Oliver Cheers, Dan On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote: My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
What sort of errors? link errors? As a quick test, I #undef'ed WTF_PLATFORM_CG, WTF_USE_CFNETWORK, and WTF_PLATFORM_CF; and instead #define'd WTF_PLATFORM_CAIRO and WTF_USE_WININET. Building WebCore alone resulted in 389 compile errors. The basic structure of using these #defines seems good. But apparently, when CF, CG, and CFNetwork were added, the previous constructs were badly broken. Cheers, Dan On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote: The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. Agreed. My point is that if you try to compile now using WININET, CAIRO, etc. instead of CG, CF, CN, you get _lots_ of errors. What sort of errors? link errors? PLATFORM(QT) can compile on windows, so if PLATFORM(WININET) PLATFORM(CAIRO) fails it implies there is either some code making incorrect assumptions about the PLATFORM, missing file guards, or more likely, unimplemented PLATFORM functionality. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... Sure, but it seems tough to get a time when everyone interested is on. Should we set a time to discuss this? I think you'd be safe anywhere between 2pm and 10pm PST, although that's only an educated guess based on my recollection of when GTK, QT, and Apple folk are around. --Oliver Cheers, Dan On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote: My main concern is to make sure Windows Mobile code is part of the main trunk, and not a side branch. My recommended first step to make the trunk more Windows Mobile friendly is to update the Windows version to build without requiring proprietary Apple libraries. How does the community feel about this? The windows code the depends on apple libraries are either in CG/CF specific files, or PLATFORM(CG)/PLATFORM(CF). The expectation would be that you'd be adding PLATFORM(WINCE) or PLATFORM(GDI) or some such. The best and easiest way to discuss this would be on IRC in the #webkit channel of freenode... --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Hi, Le 12 janv. 08 à 08:51, Mark Rowe a écrit : Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Sorry to interfere in your discussion :) Mike- I'm not sure we need git at Pleyo, and I am reluctant to the idea that having git would miraculously solve the problem of proposing our changes to the community. I have, weeks ago, asked again and again for some kind of access to the official repository, whether a branch or whatever so that we can start showing of that our changes do not break everything and are not that far away, so that the community can assess what is worth being merged and what is not. On the other hand, Mark, I don't think it's fair to say that in the current state of both webkit trunk and our version, we could simply deposit patchs on bugzilla and that it would be the solution, we have too many changes which are often related to each others, so I assume that it would not work, which is why I made the request mentioned above. I have no answer yet wrt to this proposal so I assume it has not yet been rejected ;) Best regards, Jean-Charles -- Jean-Charles Verdié Join OWB team on freenode IRC, channel #owb 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: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
Then make it SVN I don't care. If git is that big of a hurdle then create a collaboration are using SVN. I did not mean to get into a git vs svn match. Git just seemed to me to be a better choice for the type of branching and merging and needed for a collaboration area. SVN, cvs rcs, sccs anything is better than nothing. Right now we have nothing. On Jan 11, 2008 11:51 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 18:13, Mike Emmel wrote: Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've worked with a number of people that have been interested in experimenting with Git for use with WebKit. The feedback I have received from the majority of them is that git is much less friendly to use than Subversion, and that the documentation is hard to follow for new users. It does have its benefits once you understand how to use it, but it has a hell of a learning curve before you get to that point. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. If you're going to write off all possible solutions except the one you have set your mind on then I feel this discussion is not going to get very far. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. We clearly have different definitions of support. git.webkit.org provides a git-svn mirror. However, working with that mirror is left up to the end user. We provide no documentation for it or expectations that all our tools will function correctly. You also appear to be under the impression that because a given tool is used by another project it must be suitable for adoption by WebKit. The projects you mention have different development models, processes and supported platforms that may make the tool more suitable for them. Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Your webkit ports list has none of this work listed. http://trac.webkit.org/projects/webkit/wiki It's a wiki. I would encourage you to add info about these projects. Your QT port does not have the git working repository linked in a obvious manner if at all. http://trac.webkit.org/projects/webkit/wiki/QtWebKit Sure it does: click Information for Contributors. I see no reason to have this stuff scattered across the internet. Why can't webkit.org offer to host these ports ? I have already outlined the reasons why *I* feel it is premature for the WebKit project to do this at this time. If you feel strongly about this, I would suggest you trade talk for action
Re: [webkit-dev] Pulling together on WebKit Mobile
On 11/01/2008, at 10:54 AM, Mike Emmel wrote: I think this approach will allow us to keep the main repository and tree clean and foster the churn that makes open source development fun and exciting. Contributing to webkit is not a fun and exciting process at the moment. There's already a git mirror of webkit trunk, and there's nothing stopping you from having a public facing version of your own git repository, but having a lax commit policy will just make life complicated in the long term -- say you work for many months off trunk, sure git will allow you to track trunk effectively, but when it comes to final commit time it will make reviewing the patch much harder as the entire patch will have to be reviewed at once... As far as I was aware most large OSS projects had similar review requirements, so i'm not entirely sure how the WebKit project differs --Oliver On Jan 11, 2008 10:38 AM, Alp Toker [EMAIL PROTECTED] wrote: Hey guys, There's a lot of mobile WebKit expertise in different organisations and from various individuals, but we haven't really done much to put it all in one place so far. Would you be interested in sharing your findings, internal documentation and patches? Some things I'd like to see: * Build fixes for various lightweight toolchains integrated into TOT * Documentation of optional defines used in the WebCore loader and elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE * Build instructions made public (Scratchbox, cross-compilation etc.) * Compiler flags * Bug workarounds for different architectures and toolchains I'd love to see what Naiem's team is finding and fixing in the GTK+ port, what tweaks the iPhone and Android engineers are using, and the lightweight libc fixes from Peter, and Collabora's findings on the Nokia internet tablets all in one place. When patches get merged, the WebKit team will help you maintain them so contributing code can help reduce the burden of maintaining ports and build fixes out-of-tree. I have some material I've built up privately in the last year on ARM including benchmarks and patches that I'd like to start sharing too. I do think we can get more done if we work together here. I've set up a wiki page -- please edit this with your findings and suggestions: http://trac.webkit.org/projects/webkit/wiki/Mobile You can register an account on the wiki here: http://trac.macosforge.org/projects/webkit/register ___ 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
Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
[This is drifting far from Alp's original email. I hope the points he raised are not overlooked due to discussion on this very tangential topic.] On 12/01/2008, at 06:55, Mike Emmel wrote: And its a good way to allow developers to build up a work history to ask for main commit rights. We already have a well-defined policy for how this is handled, http://webkit.org/coding/commit-review-policy.html . I don't see what hosting git repositories has to do with Subversion commit access. I have a patch for example to allow the gtk webkit to run on OSX. But its a workaround for a bug in the cairo OSX port. I'd like to be able to get the patch public and work with the cairo OSX port maintainer to explain why I did what I did and what he could do to cairo to fix OSX cairo. Without a public work area this sort of problem is difficult to work on. Assuming cairo is fixed then we would need to figure out version info for the OSX port of GTK etc etc. I've found email works really well for discussing patches in the past. Indeed, that's what we use for a lot of patch discussion inside Apple. Would an official, public git repository make this easier? Possibly. A git repository for collaboration is a nicety, but hardly a necessity. As Oliver mentioned, it is not at all difficult to publish your own public git repository. Being able to run the OSX port and the gtk port at the same time on OSX is a nice feature. Other open source ports such as QT might want a similar workspace for similar problems. Staikos Computing Services provides something similar to what you describe for those collaborating on the Qt port, http://trac.webkit.org/projects/webkit/wiki/QtWebKitContrib . While I would prefer it were hosted somewhere more official (eg, git.webkit.org alongside the git mirror of SVN), I have heard very few requests for this from outside the Qt developer community. It is something I am interested in doing in the future, but it takes planning and time that I can better spend elsewhere at present. As of now the patch sits in my git tree unsubmitted. Do you consider using git to be a requirement for you to contribute at all to WebKit? - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 12:14 PM, Mark Rowe [EMAIL PROTECTED] wrote: [This is drifting far from Alp's original email. I hope the points he raised are not overlooked due to discussion on this very tangential topic.] On 12/01/2008, at 06:55, Mike Emmel wrote: And its a good way to allow developers to build up a work history to ask for main commit rights. We already have a well-defined policy for how this is handled, http://webkit.org/coding/commit-review-policy.html . I don't see what hosting git repositories has to do with Subversion commit access. I have a patch for example to allow the gtk webkit to run on OSX. But its a workaround for a bug in the cairo OSX port. I'd like to be able to get the patch public and work with the cairo OSX port maintainer to explain why I did what I did and what he could do to cairo to fix OSX cairo. Without a public work area this sort of problem is difficult to work on. Assuming cairo is fixed then we would need to figure out version info for the OSX port of GTK etc etc. I've found email works really well for discussing patches in the past. Indeed, that's what we use for a lot of patch discussion inside Apple. Would an official, public git repository make this easier? Possibly. A git repository for collaboration is a nicety, but hardly a necessity. As Oliver mentioned, it is not at all difficult to publish your own public git repository. I never claimed it was a necessity I just think it would be a very nice to have. And I think it would foster getting more code ready for submission faster and easier. As far as the current process for submission goes nothing wrong with it. Being able to run the OSX port and the gtk port at the same time on OSX is a nice feature. Other open source ports such as QT might want a similar workspace for similar problems. Staikos Computing Services provides something similar to what you describe for those collaborating on the Qt port, http://trac.webkit.org/projects/webkit/wiki/QtWebKitContrib . While I would prefer it were hosted somewhere more official (eg, git.webkit.org alongside the git mirror of SVN), I have heard very few requests for this from outside the Qt developer community. It is something I am interested in doing in the future, but it takes planning and time that I can better spend elsewhere at present. As of now the patch sits in my git tree unsubmitted. Do you consider using git to be a requirement for you to contribute at all to WebKit? I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. As far as small side projects like WebKit on OSX-GTK yes I consider it a requirement since Its something that makes sense to share with a broader community. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. Back to the OSX-GTK example it should be branched from the working gtk/webkit repository that the gtk developers are using for work in progress but ? And even better to see the latest QT work from the same git repo. Did the QT guys implement something that could be used as a guide for the GTK port but not land it in the main tree ? For me having this sort of work area would be very useful. Hopefully others feel the same way. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
On Jan 11, 2008 11:29 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
On 11/01/2008, at 10:54 AM, Mike Emmel wrote:
I think this approach will allow us to keep the main repository and
tree clean and foster the churn that makes open source development fun
and exciting.
Contributing to webkit is not a fun and exciting process at the
moment.
There's already a git mirror of webkit trunk, and there's nothing
stopping you from having a public facing version of your own git
repository, but having a lax commit policy will just make life
complicated in the long term -- say you work for many months off
trunk, sure git will allow you to track trunk effectively, but when
it comes to final commit time it will make reviewing the patch much
harder as the entire patch will have to be reviewed at once...
As far as I was aware most large OSS projects had similar review
requirements, so i'm not entirely sure how the WebKit project differs
--Oliver
I have no problems with the commit requirements for the main tree.
This is more about a collaboration area.
It make more sense for WebKit.org to host a collaboration area.
And its a good way to allow developers to build up a work history to
ask for main commit rights.
Its a public work area and why would it effect eventual mainline
submissions if the code is crufty its rejected.
I have a patch for example to allow the gtk webkit to run on OSX. But
its a workaround for a bug in the cairo OSX port.
I'd like to be able to get the patch public and work with the cairo
OSX port maintainer to explain why I did what I did
and what he could do to cairo to fix OSX cairo.
Without a public work area this sort of problem is difficult to work on.
Assuming cairo is fixed then we would need to figure out version info
for the OSX port of GTK etc etc.
Being able to run the OSX port and the gtk port at the same time on
OSX is a nice feature.
Other open source ports such as QT might want a similar workspace for
similar problems.
As of now the patch sits in my git tree unsubmitted.
On Jan 11, 2008 10:38 AM, Alp Toker [EMAIL PROTECTED] wrote:
Hey guys,
There's a lot of mobile WebKit expertise in different
organisations and
from various individuals, but we haven't really done much to put
it all
in one place so far.
Would you be interested in sharing your findings, internal
documentation
and patches?
Some things I'd like to see:
* Build fixes for various lightweight toolchains integrated into
TOT
* Documentation of optional defines used in the WebCore loader and
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE
* Build instructions made public (Scratchbox, cross-compilation
etc.)
* Compiler flags
* Bug workarounds for different architectures and toolchains
I'd love to see what Naiem's team is finding and fixing in the GTK+
port, what tweaks the iPhone and Android engineers are using, and the
lightweight libc fixes from Peter, and Collabora's findings on the
Nokia
internet tablets all in one place.
When patches get merged, the WebKit team will help you maintain
them so
contributing code can help reduce the burden of maintaining ports and
build fixes out-of-tree.
I have some material I've built up privately in the last year on ARM
including benchmarks and patches that I'd like to start sharing too.
I do think we can get more done if we work together here. I've set
up a
wiki page -- please edit this with your findings and suggestions:
http://trac.webkit.org/projects/webkit/wiki/Mobile
You can register an account on the wiki here:
http://trac.macosforge.org/projects/webkit/register
___
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
diff --git a/WebKit/gtk/Api/webkitgtkpage.cpp b/WebKit/gtk/Api/webkitgtkpage.cpp
index dabc685..ba271da 100644
--- a/WebKit/gtk/Api/webkitgtkpage.cpp
+++ b/WebKit/gtk/Api/webkitgtkpage.cpp
@@ -47,7 +47,10 @@
#include PlatformKeyboardEvent.h
#include PlatformWheelEvent.h
#include SubstituteData.h
-
+#ifndef NDEBUG
+#include RenderTreeAsText.h
+#include gdk/gdkkeysyms.h
+#endif
using namespace WebKit;
using namespace WebCore;
@@ -75,22 +78,46 @@ static gboolean webkit_page_expose_event(GtkWidget* widget, GdkEventExpose* even
{
Frame* frame = core(getFrameFromPage(WEBKIT_PAGE(widget)));
GdkRectangle clip;
+cairo_t* cr;
gdk_region_get_clipbox(event-region, clip);
-cairo_t* cr = gdk_cairo_create(event-window);
+
+//quartz backend is broken
+#if CAIRO_HAS_QUARTZ_SURFACE
+WebKitPagePrivate* private_data = WEBKIT_PAGE_GET_PRIVATE(WEBKIT_PAGE(widget));
+cr = cairo_create(private_data-buffer);
+#else
+cr =
[webkit-dev] Pulling together on WebKit Mobile
Hey guys, There's a lot of mobile WebKit expertise in different organisations and from various individuals, but we haven't really done much to put it all in one place so far. Would you be interested in sharing your findings, internal documentation and patches? Some things I'd like to see: * Build fixes for various lightweight toolchains integrated into TOT * Documentation of optional defines used in the WebCore loader and elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE * Build instructions made public (Scratchbox, cross-compilation etc.) * Compiler flags * Bug workarounds for different architectures and toolchains I'd love to see what Naiem's team is finding and fixing in the GTK+ port, what tweaks the iPhone and Android engineers are using, and the lightweight libc fixes from Peter, and Collabora's findings on the Nokia internet tablets all in one place. When patches get merged, the WebKit team will help you maintain them so contributing code can help reduce the burden of maintaining ports and build fixes out-of-tree. I have some material I've built up privately in the last year on ARM including benchmarks and patches that I'd like to start sharing too. I do think we can get more done if we work together here. I've set up a wiki page -- please edit this with your findings and suggestions: http://trac.webkit.org/projects/webkit/wiki/Mobile You can register an account on the wiki here: http://trac.macosforge.org/projects/webkit/register ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pulling together on WebKit Mobile
I think one of the biggest stumbling blocks is the lack of a shared workspace for development. The patch approach is good for bugs but falls apart when multiple people from different organizations are working on new code. However I like the review process in place before code is included in the main tree. Git with its builtin ability to chain repositories easily makes a sensible choice for solving this problem. So I would like to propose that we have a public git repository set up that has fairly lax commit rules. This repo can track the main repository and we should bugs to reference git branches in the development repository. This will allow us to publicly stage development for inclusion into the main repo and make it easy to upgrade bug reports as the head changes. And most importantly it would move a lot of intermediate development out of private repositories and into a sharable public arena. Next it gives people a work history that can be reviewed when considering allowing main repo privileges. I think this approach will allow us to keep the main repository and tree clean and foster the churn that makes open source development fun and exciting. Contributing to webkit is not a fun and exciting process at the moment. On Jan 11, 2008 10:38 AM, Alp Toker [EMAIL PROTECTED] wrote: Hey guys, There's a lot of mobile WebKit expertise in different organisations and from various individuals, but we haven't really done much to put it all in one place so far. Would you be interested in sharing your findings, internal documentation and patches? Some things I'd like to see: * Build fixes for various lightweight toolchains integrated into TOT * Documentation of optional defines used in the WebCore loader and elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE * Build instructions made public (Scratchbox, cross-compilation etc.) * Compiler flags * Bug workarounds for different architectures and toolchains I'd love to see what Naiem's team is finding and fixing in the GTK+ port, what tweaks the iPhone and Android engineers are using, and the lightweight libc fixes from Peter, and Collabora's findings on the Nokia internet tablets all in one place. When patches get merged, the WebKit team will help you maintain them so contributing code can help reduce the burden of maintaining ports and build fixes out-of-tree. I have some material I've built up privately in the last year on ARM including benchmarks and patches that I'd like to start sharing too. I do think we can get more done if we work together here. I've set up a wiki page -- please edit this with your findings and suggestions: http://trac.webkit.org/projects/webkit/wiki/Mobile You can register an account on the wiki here: http://trac.macosforge.org/projects/webkit/register ___ 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: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On 12/01/2008, at 07:55, Mike Emmel wrote: I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. The process you describe is vague and untested in the context of WebKit. The process we have now works reasonably well (well enough) for a large number of developers. There are some situations, none of which are particularly common, in which it is less efficient than it could be: two or more developers working together to implement a single feature is the one that springs to mind. Addressing these situations is clearly desirable, but I don't believe it's as simple as saying that git will magically fix things. It brings with it a new set of problems that most WebKit developers are not familiar with, and is much slower than SVN when interacting with an SVN repository, and currently has poor Windows support. Adopting git in a semi-official manner like you mention would require improving tool support and documentation such that any WebKit developer could deal with the new workflow if needed. In itself, this is not a small task. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. For me having this sort of work area would be very useful. I don't disagree that it would be useful. Part of the point of Git is that it is distributed in nature. This allows individuals to use git if they desire, and to experiment and come up with a workflow that fits with the existing WebKit tools and processes. Once tools have improved and a common idea of the right workflow to use has evolved, we should consider looking into adopting Git more officially. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On Jan 11, 2008 1:26 PM, Mark Rowe [EMAIL PROTECTED] wrote: On 12/01/2008, at 07:55, Mike Emmel wrote: I'd like for it to be very easy to contribute a git tree with commit rights that was acceptable to the WebKit community would make it very easy to create branches for bug fixes and and as a work area. And it makes it easy to allow outstanding patches to track the head. I found the current process of submitting a patch having the head change breaking the patch resubmitting etc etc to be clumsy. If the patch was on a git tree that matched the head the branch then then applied. I feel the workflow for patch submission could be made a lot easier with this approach. Especially for complex issues. The process you describe is vague and untested in the context of WebKit. The process we have now works reasonably well (well enough) for a large number of developers. There are some situations, none of which are particularly common, in which it is less efficient than it could be: two or more developers working together to implement a single feature is the one that springs to mind. Addressing these situations is clearly desirable, but I don't believe it's as simple as saying that git will magically fix things. It brings with it a new set of problems that most WebKit developers are not familiar with, and is much slower than SVN when interacting with an SVN repository, and currently has poor Windows support. Adopting git in a semi-official manner like you mention would require improving tool support and documentation such that any WebKit developer could deal with the new workflow if needed. In itself, this is not a small task. Why ? If they want to use it they can if they prefer svn then they should work to get commit rights. I prefer that a small number of developers have commit rights to the main svn like it is now. This is far less than the number of developers that can contribute to webkit and forcing them to work with patches is simply cumbersome. Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. Also having the GNUSstep port and it looks like a number of other WebKit related projects lost over on a generic server is not a good thing. A collaboration under webkit.org would bring these projects back under webkit.org where they belong. For me having this sort of work area would be very useful. I don't disagree that it would be useful. Part of the point of Git is that it is distributed in nature. This allows individuals to use git if they desire, and to experiment and come up with a workflow that fits with the existing WebKit tools and processes. Once tools have improved and a common idea of the right workflow to use has evolved, we should consider looking into adopting Git more officially. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. Back to immediate needs. For the Gtk-OSX work it has one very useful feature it would be the only port that could be trivially switched between freetype rendering and ATSUI for fonts. Having a version of webkit that could be flipped between two standard font engines is very useful when looking at font related layout
Re: Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)
On 12/01/2008, at 18:13, Mike Emmel wrote: Webkit is a fairly sophisticated piece of code using git for daily development is trivial. I'd expect any developer who was collaborating on webkit would also be capable of learning git. Something as simple as this is sufficient. http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Or maybe even this ? http://trac.webkit.org/projects/webkit/wiki/UsingGitWithWebKit I've worked with a number of people that have been interested in experimenting with Git for use with WebKit. The feedback I have received from the majority of them is that git is much less friendly to use than Subversion, and that the documentation is hard to follow for new users. It does have its benefits once you understand how to use it, but it has a hell of a learning curve before you get to that point. I've got other small projects I'd like to share with others before they are ready to submit to the mainline. And more important if others are interested I'd like to see what they are working on without having to discover git repos scattered randomly about the internet. A minimal-effort solution could be to use http://repo.or.cz/ ,and create a wiki page to catalogue the locations of git repositories that other developers are using. A quick glance shows that Holger has a repository on repo.or.cz, and there appears to be a GNUstep port hosted there too. As best I can tell, this light-weight approach would fulfil your immediate need. I take it you did not look at that repository that carefully. http://repo.or.cz/w/webbrowser.git I tried this over a year ago and found that your incorrect in your assumptions about the suitability. If you're going to write off all possible solutions except the one you have set your mind on then I feel this discussion is not going to get very far. Why wait your now officially supporting git via svn tracking. A clone server that allows developer to create common working areas is a small step. I'd say you have already done most of the work. I'd suspect that members of the open source community would be willing to help with git issues if they arise. Also the tool is used for a lot of large open source projects most if not all of opendesktop.org is under git. And I'd say that X11 development alone is at least as complex as webkit not to mention linux kernel development. Given that you already support a git server and that large open source projects are successfully using git I think the argument your making is weak at best. We clearly have different definitions of support. git.webkit.org provides a git-svn mirror. However, working with that mirror is left up to the end user. We provide no documentation for it or expectations that all our tools will function correctly. You also appear to be under the impression that because a given tool is used by another project it must be suitable for adoption by WebKit. The projects you mention have different development models, processes and supported platforms that may make the tool more suitable for them. Another immediate need is if you did this I'd like to ask Pleyo to move there development over to this new open git server. Pleyo has done some fairly innovative work but they have diverged from the main tree and it would take time and effort to take some of there ideas and adopt them to the mainline code base. I'm not speaking for Pleyo but its a shame that their work has no easy way to make it back into the mainline development tree. As far as I am aware they have made little effort to contribute changes back. Pleyo has been more than willing to merge changes from trunk WebKit, or even unfinished patches in Bugzilla, so claiming they need git to make submitting changes possible feels very much like blaming the tools for a social problem. Your webkit ports list has none of this work listed. http://trac.webkit.org/projects/webkit/wiki It's a wiki. I would encourage you to add info about these projects. Your QT port does not have the git working repository linked in a obvious manner if at all. http://trac.webkit.org/projects/webkit/wiki/QtWebKit Sure it does: click Information for Contributors. I see no reason to have this stuff scattered across the internet. Why can't webkit.org offer to host these ports ? I have already outlined the reasons why *I* feel it is premature for the WebKit project to do this at this time. If you feel strongly about this, I would suggest you trade talk for action and improve the git compatibility of our tools, document processes for working with git against WebKit, and investigate precisely how your ideal result would work (what infrastructure would be needed, what workflow should be used, what changes to tools this would require). Simply dismissing the issues that I raised does nothing to address them. - Mark smime.p7s Description: S/MIME cryptographic signature
