Re: [webkit-dev] DeviceOrientation/Motion on Document rather than Page

> I'd rather the mock controller setup be ugly than the typical use of the > controller. Having the > controller and client on Page was quite annoying. I'd much prefer it lived on > Document. I'm fine with moving the controller and client from the Page to the Document. The important thing, as I u

[webkit-dev] build.webkit.org

Hi webkit-dev, I landed the last piece of the HTML5 parser tonight. Unfortunately, build.webkit.org is super slow for some reason, so it's hard for me to see what's going on with the bots. I think I've got most things cleaned up, but there might still be some residual redness in Qt and/or Snow L

[webkit-dev] Qt bots and EWS are building WebKit2 by default now

Dear WebKit Community, in the past weeks we have worked on refactoring and stabilizing the build of the Qt port of WebKit2 and since the Windows and Snow Leopard bots and EWS build WebKit2 by default for some time now, we also decided to expand our QA coverage to include the WebKit2 build. T

Re: [webkit-dev] Layout Tests Crashing on Snow Leopard

On Aug 23, 2010, at 6:42 PM, Eric Seidel wrote: > The failing code was added by Adam Roben 4 days ago: > http://trac.webkit.org/changeset/65703. > > It's possible (probable) it's simply been failing since it was added. > > https://bugs.webkit.org/show_bug.cgi?id=44460 Sorry for the mess, and th

Re: [webkit-dev] WebKitTools/Script/generate-coverage-data

Ha. That's not long to wait. I'd be happy to use them on OS X if they worked again. At some point we had a coverage bot. Perhaps if they were restored to working condition we could work with wms to set one up again. I'm expect we can find a linux machine somewhere to run it on. -eric On Mon,

[webkit-dev] Naked new considered harmful

One thing Darin and I discussed at WWDC (yes, this email has been a long time coming) is better programming patterns to prevent memory leaks. As I'm sure you know, whenever you allocate a RefCounted object, you need to call adoptRef to prevent a memory leak by adopting the object's initial referen

Re: [webkit-dev] Naked new considered harmful

Thanks, Adam. This project will be worthwhile. I think we may want to write a document about this that goes alongside because I’m sure there will be frequently-asked questions. On Aug 24, 2010, at 10:46 AM, Adam Barth wrote: > In the cases where we have a

[webkit-dev] Null value for QualifiedName

Greetings all, While working on the bug 44288, it came to my attention that the default constructor of QualifiedName is behind a flag QNAME_DEFAULT_CONSTRUCTOR, and I can't find a qualified name that stands for invalid / null value. Is there any desi

[webkit-dev] Web Audio API

Over the past months I've been refining the web audio API implementation that I've been developing in the 'audio' branch of WebKit (per Maciej's recommendation). The API has been through a good amount of review by WebKit developers at Apple, Google, and in the W3C Audio Incubator group. For thos

[webkit-dev] Place For new Core Module

Typically WebKit has 3 doors for external world (i.e whoever wants to use WebKit), platform specific interfaces and WebKit layer, and JavaScript bindings. I have special case in my hand; currently I maintain a custom branch of WebKit, I already have implemented a module which sits closely with Web

Re: [webkit-dev] Place For new Core Module

On Tue, Aug 24, 2010 at 12:21 PM, Chinmaya Sn wrote: > I have special case in my hand; currently I maintain a custom branch > of WebKit, I already have > implemented a module which sits closely with WebCore and it works just > fine. One of my > goals is to deliver these changes back to community

Re: [webkit-dev] Null value for QualifiedName

While I don’t strongly oppose adding a null value, there are some benefits to not having one. Not having to handle that special case can keep code simpler. And if you don’t have a null value or empty value then you don’t have to answer the question of whether these two are the same thing or not.

Re: [webkit-dev] Place For new Core Module

The current module I have implemented works closely with RenderingEngine/GraphicsContext and HTML5 video player, which tries to deliver some special interactive Apps (In Cable World) as an overlay over HTML5 Video, the apps themselves are delivered as one of the private streams in the Video, so som

Re: [webkit-dev] Place For new Core Module

> The current module I have implemented works closely with > RenderingEngine/GraphicsContext and HTML5 video player, which > tries to deliver some special interactive Apps (In Cable World) as an > overlay over HTML5 Video, > the apps themselves are delivered as one of the private streams in the > V

Re: [webkit-dev] Place For new Core Module

I'll be the first to ask this question: what do you need to do that you can do with existing WebKit APIs, and existing web technology? With video, you could use http streaming to deliver custom content, and make sure of accelerated compositing to ensure that you can efficiently layer HTML content

Re: [webkit-dev] Null value for QualifiedName

I think this callsite reads better w/o the QualifiedName*, but Darin is right, that could just be htmlTag or whatever with a comment explaining. This site could also crete its own: static QualifiedName nullName(nullAtom, nullAtom, nullAtom) if it really wanted. -eric On Tue, Aug 24, 2010 at 12:2

Re: [webkit-dev] Place For new Core Module

Let me put it this way, I am working on a new standard, which leverages some of HTML5 standards but tries to extend them (not enhance) to answer some of the Cable industry challenges. I started by analysing WebKit layer, it has very strong assumption of layering browser-engine, and mostly has API

Re: [webkit-dev] Place For new Core Module

It's unclear to me how these contributions would further the project goals: http://webkit.org/projects/goals.html The closest goal seems to be the following: [[ Web Content Engine The project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HT

Re: [webkit-dev] Place For new Core Module

On Aug 24, 2010, at 2:26 PM, Chinmaya Sn wrote: > Let me put it this way, I am working on a new standard, which > leverages some of HTML5 standards but tries to extend them > (not enhance) to answer some of the Cable industry challenges. Can you point us to this standard? Is it a W3C spec? > I s

Re: [webkit-dev] Place For new Core Module

>> I am driving this as as future proof solution. >> Currently I'll be performing these changes only in my own branch. Is your branch available somewhere? Are your patched made public already? -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat _

Re: [webkit-dev] Place For new Core Module

Given your description, I'm not sure this functionality is appropriate for WebKit. We are generally reluctant to take feature patches for features that are experimental or of niche interest - we prefer to focus on technologies that are part of the standards-based Web technology stack, that are

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote: > Over the past months I've been refining the web audio API implementation that > I've been developing in the 'audio' branch of WebKit (per Maciej's > recommendation). The API has been through a good amount of review by WebKit > developers at

Re: [webkit-dev] Place For new Core Module

Thanks All. I think I am getting the general idea of what can get into to WebKit and how things fit. Right now both the standard and implementation are WIP, spec is intended to be a Web standard. At this point, neither the standard nor the implementation are public. My primary goal was to keep my

Re: [webkit-dev] Web Audio API

Hi Chris, That also sounds like a reasonable naming scheme. The only counter-argument I would have is that we have several directories in WebCore which don't have the 'web' prefix such as: WebCore/notifications WebCore/storage WebCore/workers (and not webnotifications, webstorage, webworkers)

Re: [webkit-dev] Place For new Core Module

Secret ports have an absolutely horrible track record of ever catching up with public WebKit. Only one has ever been successful to my knowledge (Chromium) and I'm not even sure we could call it full success yet. (They've spent 2 years attempting to fully catch up, and yet you can't build a useabl

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote: > Over the past months I've been refining the web audio API implementation that > I've been developing in the 'audio' branch of WebKit (per Maciej's > recommendation). The API has been through a good amount of review by WebKit > developers at A

Re: [webkit-dev] Web Audio API

Hi Simon, #if WEBAUDIO is fine. Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio? Chris On Tue, Aug 24, 2010 at 4:04 PM, Simon Fraser wrote: > On Aug 24, 2010, at 12:05 PM, Chris Rogers wrote: > > Over the past months I've been refining the web audio API implementation

Re: [webkit-dev] Web Audio API

My only concern with using the Web* prefix in WebCore is that the Web* prefix is commonly used in WebKit APIs as a namespace for API types. It seems like it could lead to some confusion. -Darin On Tue, Aug 24, 2010 at 4:15 PM, Chris Rogers wrote: > Hi Simon, > > #if WEBAUDIO is fine. > > Do y

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 3:53 PM, Chris Rogers wrote: > Hi Chris, > > That also sounds like a reasonable naming scheme. The only counter-argument > I would have is that we have several directories in WebCore which don't have > the 'web' prefix such as: > > WebCore/notifications > WebCore/storage

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 4:15 PM, Chris Rogers wrote: > Hi Simon, > > #if WEBAUDIO is fine. > > Do you also prefer WebCore/webaudio like Chris Marrin, or WebCore/audio? I am ambivalent. Everything in WebCore is ultimately web-related, so 'web' prefixes on the directories seem redundant. One direct

Re: [webkit-dev] Web Audio API

This is fantastically wonderful. Let me know what I can do to help. I'm happy to do reviews for what I can. -eric On Tue, Aug 24, 2010 at 12:05 PM, Chris Rogers wrote: > Over the past months I've been refining the web audio API implementation > that I've been developing in the 'audio' branch o

Re: [webkit-dev] Web Audio API

Hi Simon, thanks for helping here. By the way, anybody who is interested can look at the files in: https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/ There are actually a number of audio files which could be considered re-usable, although I know of nothing at this time other t

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote: > Hi Simon, thanks for helping here. > > By the way, anybody who is interested can look at the files in: > https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/ > > There are actually a number of audio files which could be conside

Re: [webkit-dev] Web Audio API

Chris - On Aug 24, 2010, at 4:47 PM, Chris Rogers wrote: > Hi Simon, thanks for helping here. > > By the way, anybody who is interested can look at the files in: > https://svn.webkit.org/repository/webkit/branches/audio/WebCore/audio/ > > There are actually a number of audio files which could b

Re: [webkit-dev] Web Audio API

Good, it looks like we're getting close. So we've agreed to how the files should be split up, but Darin Fisher still was concerned about the 'web' prefix. Darin, was it the directory name WebCore/webaudio that you didn't like or: #if ENABLE(WEB_AUDIO) Alternatives might be: WebCore/audio or

Re: [webkit-dev] Web Audio API

This sounds like a reasonable plan. I have no strong feelings about any of the naming options, but I like the overall idea of getting this code into trunk now, using a feature define, and separating the Web-facing parts from the "platform" implementation parts. - Maciej On Aug 24, 2010, at 1

Re: [webkit-dev] Making GRefPtr more general

On Aug 23, 2010, at 10:17 AM, Martin Robinson wrote: > On Mon, Aug 23, 2010 at 10:06 AM, Eric Seidel wrote: >> Would this then combine with the Mac/Win port's RetainPtr in some way? > > I think it makes a lot of sense to gradually combine our duplicate smart > pointer logic into one base or tem

Re: [webkit-dev] Web Audio API

My objection (and it's only a slight one) was about using "Web" as a prefix for class names defined in WebCore. WebSockets is the main example of the Web prefix used in WebCore, and that's probably because "sockets" by itself would be too confusing. However, I have found the use of the Web prefix

Re: [webkit-dev] Web Audio API

On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote: > My objection (and it's only a slight one) was about using "Web" as a prefix > for class names defined in WebCore. > > WebSockets is the main example of the Web prefix used in WebCore, and that's > probably because "sockets" by itself would be

Re: [webkit-dev] Web Audio API

On Tue, Aug 24, 2010 at 8:55 PM, Eric Carlson wrote: > > On Aug 24, 2010, at 8:39 PM, Darin Fisher wrote: > > My objection (and it's only a slight one) was about using "Web" as a prefix > for class names defined in WebCore. > > WebSockets is the main example of the Web prefix used in WebCore, and

Re: [webkit-dev] Web Audio API

Ok, then it looks like we'll go with this for the directory names: WebCore/webaudio WebCore/platform/audio And this for the feature define: #if ENABLE(WEB_AUDIO) Thanks everybody, Chris On Tue, Aug 24, 2010 at 9:02 PM, Darin Fisher wrote: > On Tue, Aug 24, 2010 at 8:55 PM, Eric Carlson wrote: