Hi Alex,
On Oct 5, 2009, at 1:04 PM, Alex Milowski wrote:
I'd like to work on this MathML project in conjunction with those of
you
who might be interested in using it in the near future. I'd also
welcome
any help.
If you are interested, even as an observer, let me know.
I am very intere
On Mon, Oct 5, 2009 at 10:35 PM, Dmitry Titov wrote:
> On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig wrote:
>
> I would still very much like a good solution to runtime enabling/disabling
>> features in the bindings as I think this would be a useful addition to the
>> webkit arsenal and I am curious
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig wrote:
I would still very much like a good solution to runtime enabling/disabling
> features in the bindings as I think this would be a useful addition to the
> webkit arsenal and I am curious why it is thought that doing it right will
> be prohibitively
I think we should enable Web Sockets in the Chromium Test Shell so that we
can exercise all of the layout tests. (For those not familiar, the Chromium
Test Shell is like DumpRenderTree, but it lives in the Chromium repository.)
I'd imagine that we'd want to enable it in DRT for similar reasons. I
So, is it fine to make WebSockets enable by default?
For now, there are no SocketStreamHandle implementation. so even enabling
WebSockets in Settings, it is the almost same that the feature is not
available..
--
ukai
On Tue, Oct 6, 2009 at 2:04 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009,
It is requested to be turned on at the beginning of Web Sockets
implementation so that it will be tested as it is brought up.
https://bugs.webkit.org/show_bug.cgi?id=27206
Is is ok to turn off by default from this point of view?
On Tue, Oct 6, 2009 at 1:57 PM, Darin Fisher wrote:
> On Mon, Oct
On Oct 5, 2009, at 9:54 PM, Mark Rowe wrote:
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the
configuration when promoting builds. The bits that passed the test
get promoted.
I'm happy to absorb this cost in the V8 bindings. I don't
On Mon, Oct 5, 2009 at 9:56 PM, Jeremy Orlow wrote:
> On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe wrote:
>
>>
>> On 2009-10-05, at 21:48, Darin Fisher wrote:
>>
>> It is a matter of our process that we do not change the configuration
>>> when promoting builds. The bits that passed the test get p
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe wrote:
>
> On 2009-10-05, at 21:48, Darin Fisher wrote:
>
> It is a matter of our process that we do not change the configuration when
>> promoting builds. The bits that passed the test get promoted.
>>
>> I'm happy to absorb this cost in the V8 binding
On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe wrote:
>
> On 2009-10-05, at 21:48, Darin Fisher wrote:
>
> It is a matter of our process that we do not change the configuration when
>> promoting builds. The bits that passed the test get promoted.
>>
>> I'm happy to absorb this cost in the V8 binding
On 2009-10-05, at 21:48, Darin Fisher wrote:
It is a matter of our process that we do not change the
configuration when promoting builds. The bits that passed the test
get promoted.
I'm happy to absorb this cost in the V8 bindings. I don't think it
is important to solve this problem fo
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I
On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I
On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson wrote:
> Ooops, meant to reply to all.
>
>
> On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> That is not true, they are also available in nightly builds at
>>> http://night
On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak
wrote:
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
wrote:
I'm surprised to see these objections coming up now, weeks after
the original
On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak wrote:
>
> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>
> I'm surprised to see these objections coming up now, weeks after the
>> original discussion, and only after my patch has lande
window.applicationCache does something different when the runtime switch is
disabled which definitely breaks feature detection. It returns a non-null,
but non-functioning object. At some point I had changed it to return 'null'
when disabled, but later reverted that change and went back to the non-
Ooops, meant to reply to all.
On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson wrote:
>
>
> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>
>>
>>
>> That is not true, they are also available in nightly builds at
>> http://nightly.webkit.org/.
>>
>
> I'm not sure what you mean, exactly - the nigh
On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>
>
> On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson wrote:
>
>>
>> On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>>
>>> I'm surprised to see these objections coming up now, we
Same here, I'm also very interested in the project, but unfortunately also
won't have too many spare cycles to contribute. I'll try to keep up and add
one or the other comment of dubious helpfulness, though.
Cheers,
Roland
On Tue, Oct 6, 2009 at 5:35 AM, Kenneth Christiansen <
kenneth.christian.
On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson
wrote:
I'm surprised to see these objections coming up now, weeks after the
original discussion, and only after my patch has landed in the tree.
Sorry, I seemed to have missed that thread. I did
On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson wrote:
>
> On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>>
>> I'm surprised to see these objections coming up now, weeks after the
>>> original discussion, and only after my patch has
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>
> I'm surprised to see these objections coming up now, weeks after the
>> original discussion, and only after my patch has landed in the tree.
>>
>
> Sorry, I seemed to have missed that t
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
I'm surprised to see these objections coming up now, weeks after the
> original discussion, and only after my patch has landed in the tree.
>
Sorry, I seemed to have missed that thread. I did however file a bug as soon
as the first runtime switc
I don't think I wrote the Audio code, (I think I probably just moved it),
but I also don't believe it is intended as a general purpose runtime switch
(but rather fallback when there are no installed codecs). It is also not
something people are going to ship as far as I can tell, and is therefore a
BTW, I modeled my SharedWorker disabling after the code in
JSDOMWindowCustom::audio() that disables the audio constructor on platforms
that don't have MediaPlayer support.
I think the runtime behavior of window.audio and window.SharedWorker should
be identical in practice. Sam, it looks like you wr
So, two weeks ago I sent an email on this thread stating exactly what I was
planning to do, To whit:
>>>
I do think that we ought to be returning undefined instead of null in those
cases, though, just to catch people who are accidentally using isUndefined()
utility functions from common libraries.
Agreed. I was similarly dismayed. We are working on rectifying the
problem.
-Darin
On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig wrote:
> Hi Folks,
>
> I am not happy with the way these runtime settings have been implemented so
> far as they break runtime detection using the technique we evangel
Hi Folks,
I am not happy with the way these runtime settings have been implemented so
far as they break runtime detection using the technique we evangelize to
developers, specifically, using the ("property" in window) method. A
feature that is turned off at runtime should not be detectable at all
This is a question that is better suited for webkit-help. This list is for
the discussion of the development of webkit.
-Sam
On Mon, Oct 5, 2009 at 4:37 PM, Xiaomei Ji wrote:
> I am trying to display a tooltip under the mouse when mouse stays at a
> position long enough.
> I am using "absolute
I am trying to display a tooltip under the mouse when mouse stays at a
position long enough.
I am using "absolute" positioning, set the tooltip as the child of the
document.body, and set the style.left and style.top as event.clientX +
document.body.scrollLeft and event.clientY + documentbody.scroll
I cannot say that I will be using it soon, but I really like the
project and think that it can become very important for MathML and the
web in general.
As a Qt developer, it would also open the door for our users to
integrate math into their applications.
Cheers,
Kenneth
On Mon, Oct 5, 2009 at 5
On Oct 5, 2009, at 1:04 PM, Alex Milowski wrote:
I'd like to work on this MathML project in conjunction with those of
you
who might be interested in using it in the near future. I'd also
welcome
any help.
If you are interested, even as an observer, let me know.
I'm very interested in he
I'd like to work on this MathML project in conjunction with those of you
who might be interested in using it in the near future. I'd also welcome
any help.
If you are interested, even as an observer, let me know.
--
--Alex Milowski
"The excellence of grammar as a guide is proportional to the pa
On Oct 5, 2009, at 12:23 PM, Eric Seidel wrote:
It seems that the requestee field is a source of confusion for new
contributers. Especially so when the new contributor comes from
another project where the requestee field may be required (Google,
and mozilla I'm told).
I would like us to
OK. This is just a single checkbox to check in bugzilla:
https://bugs.webkit.org/editflagtypes.cgi?action=edit&id=1
I'll wait another 24 hours for folks to have a chance to respond and then
I'll uncheck the box.
-eric
On Mon, Oct 5, 2009 at 3:34 PM, Darin Adler wrote:
> On Oct 5, 2009, at 12:
On Mon, Oct 5, 2009 at 12:23 PM, Eric Seidel wrote:
> It seems that the requestee field is a source of confusion for new
> contributers. Especially so when the new contributor comes from another
> project where the requestee field may be required (Google, and mozilla I'm
> told).
> I would like u
On Oct 5, 2009, at 12:23 PM, Eric Seidel wrote:
I would like us to consider disabling the requestee field for the
review flag.
Yes, I think we should do it.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.o
I agree with just disabling/removing it.
On Oct 5, 2009, at 2:23 PM, Eric Seidel wrote:
It seems that the requestee field is a source of confusion for new
contributers. Especially so when the new contributor comes from
another project where the requestee field may be required (Google,
and
It seems that the requestee field is a source of confusion for new
contributers. Especially so when the new contributor comes from another
project where the requestee field may be required (Google, and mozilla I'm
told).
I would like us to consider disabling the requestee field for the review
flag
40 matches
Mail list logo