Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched

2013-03-01 Thread Thiago Marcos P. Santos 
On Mon, Feb 25, 2013 at 5:24 AM, Ryosuke Niwa rn...@webkit.org wrote:
 Hi all,

 We've replaced webkit-perf.appspot.com by perf.webkit.org.
 webkit-perf.appspot.com will be phased-out in the coming weeks.

 I'm going to check in the source code of perf.webkit.org into WebKit
 repository in coming months.

The new version of the perf site is just awesome. Thanks a lot.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Jesus Sanchez-Palencia 
Hi,

2013/2/28 Darin Adler da...@apple.com:
 To do this, we need to eliminate dependencies from the platform directory to 
 the rest of WebCore.

 At this time, we are far from that. Many dependencies on the DOM and other 
 such things have crept into the platform directory.

I would be happy to help fixing this, Darin. Are the bugs blocking
https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to start
list or is there something more urgent?

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

[webkit-dev] Identities and affiliation data

2013-03-01 Thread Jesus M. Gonzalez-Barahona 
Dear WebKit developers,

Maybe you already know that we at Bitergia are working on the analysis
of your community [1]. Our analysis is based in part on your WebKit team
wiki page [2] and in your committers.py file [3]. In the process for our
analysis, we have consolidated and (hopefully) improved that
information, in a couple of SQL tables, in which we match identities for
developers (different email addresses or svn logins, for example,) to
affiliations to companies and dates for those affiliations (if found).

So far, this is still work in progress, although we have tried to do our
best in matching main developers (by number of commits). We thought that
maybe these tables could be useful for you in some way. If you want, we
can provide it as a maybe more friendly csv file, in case you'll want to
have a look at it and maybe use it for the project. Of course, if any of
you is interested in helping us to fix any error in it, or just check
your own data, that would also be great.

[We're not sharing the tables here because they expose email addresses:
if you have some way of sharing private information with all developers,
or don't mind about email addresses being exposed, just let us know]

Thanks for your time!

Jesus

[1] 
http://blog.bitergia.com/2013/02/06/report-on-the-activity-of-companies-in-the-webkit-project/

[2] http://trac.webkit.org/wiki/WebKit%20Team

[3] 
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py

-- 
http://identi.ca/jgbarahhttp://twitter.com/jgbarah

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

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Žan Doberšek 
On Thu, Feb 28, 2013 at 10:02 PM, Maciej Stachowiak m...@apple.com wrote:


 I think Adam's old plan for the Platform directory was to migrate from
 WebCore/platform piece-by-piece, starting with related groups of classes
 that are already free of layering violations. That seems like a sensible
 approach to me as it allows the work to happen incrementally.


I like that approach. Hopefully people with knowledge of specific build
systems can help by setting up the project files so the non-violating
source code can start the migration.

One suggestion when approaching this task was to use the Platform namespace
for such code. This was already attempted in r104231[1] but that change
later got rolled out. Is anyone opposed to doing this?

[1] http://trac.webkit.org/changeset/104231

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

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Žan Doberšek 
On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote:

 Hi,

 2013/2/28 Darin Adler da...@apple.com:
  To do this, we need to eliminate dependencies from the platform
 directory to the rest of WebCore.
 
  At this time, we are far from that. Many dependencies on the DOM and
 other such things have crept into the platform directory.

 I would be happy to help fixing this, Darin. Are the bugs blocking
 https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to start
 list or is there something more urgent?


Violations reported by those bugs are most likely still valid. There are of
course probably other existing violations that haven't been reported yet.

-Z



 Cheers,
 jesus

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

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Arunprasad Rajkumar 
Hi,

Please ignore if it is really out of context.

It would be nice to define a Class by Class
roles/responsibilities/expectations from Platform layer before starting
implementation. May be it is a kind of Class/Function standardization
process :). I agree that currently we have standardized platform specific
interface classes like GraphicsContext, ResourceHandle, ImageFrame,.. but
the issue is each port has its own extensions to those classes to make the
process easier, PSB
class GraphicsContext {
...
#if PLATFORM(QT)
ShadowBlur* shadowBlur();
#endif
...
#if USE(CAIRO)
GraphicsContext(cairo_t*);
#endif
..
#if USE(CG)
void applyStrokePattern();
void applyFillPattern();
void drawPath(const Path);

void drawNativeImage(NativeImagePtr, const FloatSize selfSize,
ColorSpace styleColorSpace, const FloatRect destRect, const FloatRect
srcRect, CompositeOperator = CompositeSourceOver, BlendMode =
BlendModeNormal, ImageOrientation = DefaultImageOrientation);

// Allow font smoothing (LCD antialiasing). Not part of the
graphics state.
void setAllowsFontSmoothing(bool);

void setIsCALayerContext(bool);
bool isCALayerContext() const;

void setIsAcceleratedContext(bool);
#endif

};

How we are going to address these?. After this work whether we have all
these defines?

Kind Regards,
Arun

On 1 March 2013 21:50, Žan Doberšek zandober...@gmail.com wrote:

 On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia 
 je...@webkit.orgwrote:

 Hi,

 2013/2/28 Darin Adler da...@apple.com:
  To do this, we need to eliminate dependencies from the platform
 directory to the rest of WebCore.
 
  At this time, we are far from that. Many dependencies on the DOM and
 other such things have crept into the platform directory.

 I would be happy to help fixing this, Darin. Are the bugs blocking
 https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to start
 list or is there something more urgent?


 Violations reported by those bugs are most likely still valid. There are
 of course probably other existing violations that haven't been reported yet.

 -Z



 Cheers,
 jesus



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




-- 
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] -khtml- and -apple- CSS prefixes

2013-03-01 Thread David Hyatt 
I agree with you that this would be pretty terrible. We definitely don't want 
developers doing that.

dave

On Feb 28, 2013, at 8:02 PM, Adam Barth aba...@webkit.org wrote:

 I noticed this comment on the Hacker News thread about Paul Irish's
 recent blog post:
 
 ---8---
 CSS parsing is the same, though. Slurping up your CSS and turning it
 into CSSOM’s pretty standard. Yeah, though Chrome accepts just the
 -webkit- prefix whereas Apple and other ports accept legacy prefixes
 like -khtml- and -apple-.
 
 Using this information, can you target Chrome with the webkit- prefix
 and Safari with the apple- prefix? Specifying the apple- prefix after
 webkit- will ensure that Safari uses that one, right?
 ---8---
 
 http://news.ycombinator.com/item?id=5302150
 
 If developers start using this technique, it might be harder to remove
 these prefixes in the future.  Chromium's experience removing these
 prefixes has been quite positive.  We ran into one compatibility
 problem on apple.com, which Apple was gracious enough to fix.
 
 I'd recommend that the rest of the ports disable
 ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml-
 and -apple- CSS prefixes before it's too late.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Balazs Kelemen 

On 03/01/2013 06:03 PM, Arunprasad Rajkumar wrote:

Hi,

Please ignore if it is really out of context.

It would be nice to define a Class by Class 
roles/responsibilities/expectations from Platform layer before 
starting implementation. May be it is a kind of Class/Function 
standardization process :). I agree that currently we have 
standardized platform specific interface classes like GraphicsContext, 
ResourceHandle, ImageFrame,.. but the issue is each port has its own 
extensions to those classes to make the process easier, PSB


If I got it correctly than exactly these are the classes that should 
leave in Platform (among others). The fact that their feature set is not 
equivalent is orthogonal to this. It's a fact that each platform has 
it's own extra capabilities and we should be able to utilize them. 
Guarding them with preprocessor directives and relying on the convention 
that only platform code will actually use them is one way to do this, 
probably not the best.



class GraphicsContext {
...
#if PLATFORM(QT)
ShadowBlur* shadowBlur();
#endif
...
#if USE(CAIRO)
GraphicsContext(cairo_t*);
#endif
..
#if USE(CG)
void applyStrokePattern();
void applyFillPattern();
void drawPath(const Path);

void drawNativeImage(NativeImagePtr, const FloatSize 
selfSize, ColorSpace styleColorSpace, const FloatRect destRect, const 
FloatRect srcRect, CompositeOperator = CompositeSourceOver, BlendMode 
= BlendModeNormal, ImageOrientation = DefaultImageOrientation);


// Allow font smoothing (LCD antialiasing). Not part of the 
graphics state.

void setAllowsFontSmoothing(bool);
void setIsCALayerContext(bool);
bool isCALayerContext() const;

void setIsAcceleratedContext(bool);
#endif

};

How we are going to address these?. After this work whether we have 
all these defines?


Kind Regards,
Arun

On 1 March 2013 21:50, Z(an Dobers(ek zandober...@gmail.com 
mailto:zandober...@gmail.com wrote:


On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia
je...@webkit.org mailto:je...@webkit.org wrote:

Hi,

2013/2/28 Darin Adler da...@apple.com mailto:da...@apple.com:
 To do this, we need to eliminate dependencies from the
platform directory to the rest of WebCore.

 At this time, we are far from that. Many dependencies on the
DOM and other such things have crept into the platform directory.

I would be happy to help fixing this, Darin. Are the bugs blocking
https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to
start
list or is there something more urgent?


Violations reported by those bugs are most likely still valid.
There are of course probably other existing violations that
haven't been reported yet.

-Z


Cheers,
jesus



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




--
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad


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


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

Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform

2013-03-01 Thread Arunprasad Rajkumar 
Hi Balazs,

Then the role of the new platform layer sounds similar like existing one :)
Only it will be moved from Source/WebCore/platform from Source/Platform.
Instead of having extra capabilities under a preprocessor define, why can't
we define a class which has a superset of all platform capabilities, but it
is upto the Platform layer to implement it or leave it umimplemented.

Kind Regards,
Arun

On 1 March 2013 22:45, Balazs Kelemen kbal...@webkit.org wrote:

  On 03/01/2013 06:03 PM, Arunprasad Rajkumar wrote:

 Hi,

  Please ignore if it is really out of context.

  It would be nice to define a Class by Class
 roles/responsibilities/expectations from Platform layer before starting
 implementation. May be it is a kind of Class/Function standardization
 process :). I agree that currently we have standardized platform specific
 interface classes like GraphicsContext, ResourceHandle, ImageFrame,.. but
 the issue is each port has its own extensions to those classes to make the
 process easier, PSB


 If I got it correctly than exactly these are the classes that should leave
 in Platform (among others). The fact that their feature set is not
 equivalent is orthogonal to this. It's a fact that each platform has it's
 own extra capabilities and we should be able to utilize them. Guarding them
 with preprocessor directives and relying on the convention that only
 platform code will actually use them is one way to do this, probably not
 the best.


  class GraphicsContext {
 ...
  #if PLATFORM(QT)
 ShadowBlur* shadowBlur();
 #endif
 ...
 #if USE(CAIRO)
 GraphicsContext(cairo_t*);
 #endif
  ..
  #if USE(CG)
 void applyStrokePattern();
 void applyFillPattern();
 void drawPath(const Path);

  void drawNativeImage(NativeImagePtr, const FloatSize selfSize,
 ColorSpace styleColorSpace, const FloatRect destRect, const FloatRect
 srcRect, CompositeOperator = CompositeSourceOver, BlendMode =
 BlendModeNormal, ImageOrientation = DefaultImageOrientation);

  // Allow font smoothing (LCD antialiasing). Not part of the
 graphics state.
 void setAllowsFontSmoothing(bool);

 void setIsCALayerContext(bool);
 bool isCALayerContext() const;

  void setIsAcceleratedContext(bool);
 #endif

  };

  How we are going to address these?. After this work whether we have all
 these defines?

  Kind Regards,
 Arun

 On 1 March 2013 21:50, Žan Doberšek zandober...@gmail.com wrote:

  On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia 
 je...@webkit.org wrote:

 Hi,

 2013/2/28 Darin Adler da...@apple.com:
  To do this, we need to eliminate dependencies from the platform
 directory to the rest of WebCore.
 
  At this time, we are far from that. Many dependencies on the DOM and
 other such things have crept into the platform directory.

  I would be happy to help fixing this, Darin. Are the bugs blocking
 https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to start
 list or is there something more urgent?


  Violations reported by those bugs are most likely still valid. There
 are of course probably other existing violations that haven't been reported
 yet.

  -Z



 Cheers,
 jesus



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




  --
 *Arunprasad Rajkumar*
 http://in.linkedin.com/in/ararunprasad


 ___
 webkit-dev mailing 
 listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev



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




-- 
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] 32-bit WebKit Nighly build APPLICATION ?

2013-03-01 Thread Mark Gilbert 
Hi Folks.

Does anyone know if the WebKit Nightly build app is / can be built as a 32-bit 
capable binary app ?

I note that forcing WebKit to start up in 32-bit mode throws an error - 
relating to a path in the /Applications/Safari directory.  Even tho Safari 
itself is quite happy to launch in 32-bit mode, and I have compiled the WebKit 
frameworks with build-webkit --32-bit and replaced the frameworks inside the 
WebKit nightly app.

I need to be able to create an app using the WebKit nightly app, but with 
modified WebKit frameworks inside, all running in 32-bit.   I have not had any 
luck doing this lately, although It did work OK previously in the Snow Leopard 
era.

The fact that I can select 32-bit on WebKit suggests the app binary itself is 
universal 64/32 so I am not sure what part of the system is actually throwing 
the error - it looks like a file it's looking for inside /Applications/Safari 
which it can't find when in 32 bit mode.

The error is  Unable to launch Safari,   Launching Safari at 
/Applications/Safari.app failed with the error 'No Such file or directory' (2)

I get the same thing with the downloaded WebKit and also one where I have 
replaced the frameworks with 32-bit only versions.

Anyone have *any* idea what is going on?

-- To reproduce the problem, just download the nightly build of the WebKit app, 
set it to start in 32-bit and run it.

Thanks.


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

Re: [webkit-dev] 32-bit WebKit Nighly build APPLICATION ?

2013-03-01 Thread Mark Rowe 

On 2013-03-01, at 11:48, Mark Gilbert web...@gallery.co.uk wrote:

 Hi Folks.
 
 Does anyone know if the WebKit Nightly build app is / can be built as a 
 32-bit capable binary app ?
 
 I note that forcing WebKit to start up in 32-bit mode throws an error - 
 relating to a path in the /Applications/Safari directory.  Even tho Safari 
 itself is quite happy to launch in 32-bit mode, and I have compiled the 
 WebKit frameworks with build-webkit --32-bit and replaced the frameworks 
 inside the WebKit nightly app.

Safari on recent OS versions is a 64-bit-only application. I suspect that’s why 
what you’re trying to do isn’t working.

- Mark

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

Re: [webkit-dev] -khtml- and -apple- CSS prefixes

2013-03-01 Thread Maciej Stachowiak 

I think we'll want to take these out for Apple ports as soon as we can check 
prevalence in older Apple-specific content (e.g. Dashboard widgets).

 - Maciej

On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote:

 I noticed this comment on the Hacker News thread about Paul Irish's
 recent blog post:
 
 ---8---
 CSS parsing is the same, though. Slurping up your CSS and turning it
 into CSSOM’s pretty standard. Yeah, though Chrome accepts just the
 -webkit- prefix whereas Apple and other ports accept legacy prefixes
 like -khtml- and -apple-.
 
 Using this information, can you target Chrome with the webkit- prefix
 and Safari with the apple- prefix? Specifying the apple- prefix after
 webkit- will ensure that Safari uses that one, right?
 ---8---
 
 http://news.ycombinator.com/item?id=5302150
 
 If developers start using this technique, it might be harder to remove
 these prefixes in the future.  Chromium's experience removing these
 prefixes has been quite positive.  We ran into one compatibility
 problem on apple.com, which Apple was gracious enough to fix.
 
 I'd recommend that the rest of the ports disable
 ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml-
 and -apple- CSS prefixes before it's too late.
 
 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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