Re: [webkit-dev] -khtml- and -apple- CSS prefixes
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 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] 32-bit WebKit Nighly build APPLICATION ?
On 2013-03-01, at 11:48, Mark Gilbert 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
[webkit-dev] 32-bit WebKit Nighly build APPLICATION ?
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] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
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 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 wrote:
>
>> On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia <
>> je...@webkit.org> wrote:
>>
>>> Hi,
>>>
>>> 2013/2/28 Darin Adler :
>>> > 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
Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
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 > wrote:
On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia
mailto:je...@webkit.org>> wrote:
Hi,
2013/2/28 Darin Adler 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
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] -khtml- and -apple- CSS prefixes
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 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
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 wrote:
> On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia
> wrote:
>
>> Hi,
>>
>> 2013/2/28 Darin Adler :
>> > 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] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia wrote: > Hi, > > 2013/2/28 Darin Adler : > > 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
On Thu, Feb 28, 2013 at 10:02 PM, Maciej Stachowiak 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
[webkit-dev] Identities and affiliation data
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
Hi, 2013/2/28 Darin Adler : > 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
Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched
On Mon, Feb 25, 2013 at 5:24 AM, Ryosuke Niwa 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
