Re: [webkit-dev] Pulling together on WebKit Mobile

2008-01-17 Thread zucker

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

2008-01-16 Thread Brent Fulgham
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

2008-01-16 Thread Oliver Hunt


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

2008-01-16 Thread Brent Fulgham

  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

2008-01-16 Thread zucker
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

2008-01-16 Thread David Hyatt
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

2008-01-16 Thread Adam Roben

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

2008-01-16 Thread zucker
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

2008-01-16 Thread Brent Fulgham


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)

2008-01-15 Thread Maciej Stachowiak


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)

2008-01-15 Thread Pierre-Luc Beaudoin
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

2008-01-14 Thread zucker
 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

2008-01-14 Thread Oliver Hunt

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

2008-01-14 Thread Maciej Stachowiak


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)

2008-01-14 Thread Adam Roben

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

2008-01-14 Thread Brent Fulgham


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

2008-01-14 Thread zucker
 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

2008-01-14 Thread Adam Roben

[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

2008-01-14 Thread zucker
 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)

2008-01-13 Thread Jean-Charles VERDIE (Pleyo)

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)

2008-01-12 Thread Mike Emmel
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

2008-01-11 Thread Oliver Hunt


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)

2008-01-11 Thread Mark Rowe
[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)

2008-01-11 Thread Mike Emmel
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

2008-01-11 Thread Oliver Hunt

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.


Why can't http://bugs.webkit.org be used for this?  It's what we've  
been using for

what, 3 years now? 4?

bugs.w.o has a single major advantage over git: it allows actual  
communication -- making code available != communication -- b.w.o  
allows you to place updated patches, respond to feedback, and get  
feedback in one location that provides both an archive and locality.   
Afaict the git equivalent is to discuss your patch out of band in a  
mailing list, most likely including the original patch in the mail --  
so patch discussion still happens outside of git, and later when  
someone comes back to see why decisions were made in a specific patch  
they have to search for scattered posts in a mailing list to try and  
find those emails discussing that patch.


I'm also unsure how you expect this to help contributors gain  
credibility -- the mechanisms by which this happens, and how commit  
rights, etc are developed are well disclosed on webkit.org.  I don't  
see how git would help this -- an ability to write code is only part  
of the requirements, a developer needs to demonstrate good  
communication skills, and an ability to respond to feedback, etc.   
Working outside of b.w.o removes a number of avenues of real  
discussion and record so to me would seem more likely to hinder the  
credibility of a developer rather than help it.




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.


I fail to see why this patch could not just be placed in b.w.o as  
with any other feature or bugfix patch


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

2008-01-11 Thread Mike Emmel
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

2008-01-11 Thread Alp Toker

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

2008-01-11 Thread Mike Emmel
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)

2008-01-11 Thread Mark Rowe


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)

2008-01-11 Thread Mike Emmel
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)

2008-01-11 Thread Mark Rowe


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