Re: [webkit-dev] Qt Mac buildbot got crazy

[Alexis Menard]

On Mon, Apr 30, 2012 at 7:49 AM, Alexis Menard
 wrote:
> On Sat, Apr 28, 2012 at 3:41 AM, Osztrogonac Csaba  
> wrote:
>> Hi All,
>>
>> it seems Qt Mac bot got crazy and signals false build fails regularly:
>> ../../../../Source/WebCore/bridge/qt/qt_runtime.cpp: In function 'bool
>> JSC::Bindings::isJSUint8ClampedArray(JSC::JSValue)':
>> ../../../../Source/WebCore/bridge/qt/qt_runtime.cpp:142: error:
>> 'JSUint8ClampedArray' is not a class or namespace
>>
>> Please ignore this message.

In fact it was a proper failure/proper compilation error. The old gcc
version (as Xcode 3.x) was confused with conflicting name for a class
and an enum value. A build fix was landed.

We landed that some days ago, everything is back in shape.

>>
>> Alexis, could you stop your bot not to confuse folks with false alarms until
>> proper fix?
>
> I'm off up until wednesday but I'll try to catch someone.
>
>>
>> br,
>> Ossy
>
>
>
> --
> Alexis Menard (darktears)
> Software Engineer
> openBossa @ INdT - Instituto Nokia de Tecnologia



-- 
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

[Adam Barth]

On Wed, May 9, 2012 at 1:12 PM, Anssi Kostiainen
 wrote:
> On 9.5.2012, at 11.44, ext TAMURA, Kent wrote:
>
>> I wonder if the standardization is active.  Even the editor's draft has not 
>> been updated for one year.
>
> Good that you ask -- the spec has been waiting for implementors' feedback :)
>
> If you're able to send us feedback based on your implementation experience, 
> I'm happy to pick up the spec, bake in your feedback, and push it forward on 
> the standards track (the current spec editors have moved on to do other 
> things).
>
> The feedback should be sent to the public-device-a...@w3.org mailing list, 
> see:
>
>  http://lists.w3.org/Archives/Public/public-device-apis/
>
> The latest editor's draft is at:
>
>  http://dev.w3.org/2009/dap/camera/
>
> Any feedback is welcome. E.g. given that no one seems to be interested in 
> implementing the MediaFile* interfaces, we should probably consider dropping 
> them from the spec. Currently we have two open issues in the spec issue 
> tracker (http://www.w3.org/2009/dap/track/products/25), and some other issues 
> highlighted in the spec itself.

Thanks.  I just have two pieces of feedback:

1) As far as I know, we don't have any plans to implement the WebIDL interfaces.

2) From the spec, it sounds like the capture attribute is "limited to
only known values" (see
),
but it would be good to say that explicitly and link to HTML5 to
provide the definition.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

[Anssi Kostiainen]

Hi Tamura, Adam,

On 9.5.2012, at 11.44, ext TAMURA, Kent wrote:

> I wonder if the standardization is active.  Even the editor's draft has not 
> been updated for one year.

Good that you ask -- the spec has been waiting for implementors' feedback :)

If you're able to send us feedback based on your implementation experience, I'm 
happy to pick up the spec, bake in your feedback, and push it forward on the 
standards track (the current spec editors have moved on to do other things).

The feedback should be sent to the public-device-a...@w3.org mailing list, see:

  http://lists.w3.org/Archives/Public/public-device-apis/

The latest editor's draft is at:

  http://dev.w3.org/2009/dap/camera/

Any feedback is welcome. E.g. given that no one seems to be interested in 
implementing the MediaFile* interfaces, we should probably consider dropping 
them from the spec. Currently we have two open issues in the spec issue tracker 
(http://www.w3.org/2009/dap/track/products/25), and some other issues 
highlighted in the spec itself.

Cheers,

-Anssi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SVN mirrors (ex*.webkit.org is down)

[William Siegrist]

On May 8, 2012, at 9:18 AM, Osztrogonac Csaba  wrote:

> Hi All,
> 
> Nowadays there were too many svn.webkit.org downtime which made
> folks and buildbots many times so sad (and rm -rf and new checkout).


For what it is worth, we are in the process of deploying new hardware that 
replaces all of the old hardware and should result in better performance and 
reliability. We still need a couple weeks to bring it up before services start 
moving, so expect more detailed emails (and planned downtime) in the future. In 
the meantime, I appreciate your patience and help with our infrastructure 
problems. 

-Bill

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

Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

[Adam Barth]

That's a good question.  I happened upon this feature because it's
implemented in Chrome on Android, and we want to fully merge Chrome on
Android's WebKit with upstream.

Adam


On Wed, May 9, 2012 at 1:44 AM, TAMURA, Kent  wrote:
> I wonder if the standardization is active.  Even the editor's draft has not
> been updated for one year.
>
>
> On Mon, Feb 20, 2012 at 1:44 PM, JongSeok Yang 
> wrote:
>>
>>
>> Hi webkit-dev!
>>
>> I want to let you know that I plan to add HTML Media Capture to WebKit.
>> HTML Media Capture :
>> http://www.w3.org/TR/2011/WD-html-media-capture-20110414/
>>
>> The spec has two sparate features - 1) to invoke a capture panel  2)
>> WebIDL inteface for MediaFile.getFormatData()
>> First, my plan is just to implement the interface to invoke a capture
>> panel and it will be behind the ENABLE_HTML_MEDIA_CAPTURE feature define.
>> See: https://bugs.webkit.org/show_bug.cgi?id=63062
>>
>> I expect this feature to be eventually enabled by all ports.
>> If you have any commnet, please let me know.
>>
>> Thank you.
>> Jongseok Yang.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Default viewport value on WAP DTDs

[Gustavo Noronha Silva]

On Fri, 2012-05-04 at 23:18 -0700, Martin Robinson wrote:
> We chose between faking Chromium or faking OS X on all operating
> systems. We are now a port of Chromium called "WebKitGTK+". I don't
> see any easy way out of this mess.

Me neither. Also 'Safari on Linux' was being seen as "Android", it
seems, by some sites. Even with all of that work some sites still refuse
to work or hand us dumbed down content, Google properties included. The
only solution to the mess seems to be to fake U-A indeed.

Cheers,

-- 
Gustavo Noronha Silva 
GNOME Project

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

[webkit-dev] Fwd: New Module For Javascript

[Neha Narang]

Hello Everyone,

I would like to give an update that I'll add the Javascript as a new
supported target language to swig to automate the generation of
javascript wrapper over c++ using webkit (Javascriptcore).
There is often a need to have Javascript embedded in the native code
written in C++. For example, we may need to attach native objects to
javascript objects, so that we can manipulate the native objects from
script code.
Alternatively, we may want to run script code from inside our native
application, to have access to features of the scripting language
which the native language does not have.

The first result you might get from the project on mid of July.

You can get more information regarding this project on
-swig-de...@lists.sourceforge.net.

Join the list and any suggestion are welcome.

There is also ongoing process for widgets are going on with links;
- https://github.com/oliver/wxWidgets
: https://github.com/oliver/embrajs

Regards,
Neha
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Default viewport value on WAP DTDs

[Kenneth Rohde Christiansen]

Hi there,

Just wanted to say that I sent an email to www-style:
http://lists.w3.org/Archives/Public/www-style/2012May/0371.html

Cheers,
Kenneth

On Tue, May 8, 2012 at 10:07 PM, Kenneth Rohde Christiansen
 wrote:
> Hi there,
>
> Now that I have all this info, I will write an email to www-style this
> week (hopefully tomorrow). Thanks John Mellor for clarifying what
> Android does.
>
> Here is some info about WP7 Internet Explorer which does very similar things:
> http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx
>
> Cheers,
> Kenneth
>
> On Tue, May 8, 2012 at 8:58 PM, Ojan Vafai  wrote:
>> On Tue, May 8, 2012 at 11:32 AM, Hugo Parente Lima 
>> wrote:
>>>
>>> On Tuesday, May 08, 2012 07:22:17 PM John Mellor wrote:
>>> > Both Chrome for Android and the legacy Android Browser do what Hugo
>>> > described, i.e. we default to a widthÞvice-width viewport* when an
>>>
>>> > XHTML-MP doctype is provided.
>>> >
>>> > And as suggested in wkbug.com/55874, we similarly default to a
>>> > widthÞvice-width viewport if a legacy HandheldFriendly meta tag is
>>> > present, e.g.:
>>> >
>>> > 
>>>
>>> >
>>> > and if a legacy MobileOptimized meta tag is present then we will use a
>>> > viewport with the width provided, e.g. if the following tag is present:
>>> >
>>> > 
>>> >
>>> > we will treat that the same as a "width$0" viewport tag (though IIRC the
>>>
>>> > legacy Android Browser ignored the provided width and just treated it as
>>> > device-width).
>>> >
>>> > However note that we give these implicit viewport declarations lower
>>> > priority than actual viewport meta tags, so irrespective of the order
>>> > they
>>> > appear in the document, a viewport meta tag will override any behaviour
>>> > we
>>> > infer from the doctype or those legacy meta tags.
>>> >
>>> > We do all this because some number of legacy sites depend on this
>>> > behaviour. I'm afraid we don't know how common these sites still are;
>>> > but
>>> > these heuristics have never seemed to cause us any problems.
>>> >
>>> > It makes sense to propose standardizing the XHTML-MP behaviour on
>>> > www-style
>>> > since I agree with Kenneth that this is something that should be covered
>>> > by
>>> > the http://dev.w3.org/csswg/css-device-adapt/ spec. That would also be a
>>> > good place to try and standardize how we deal with legacy mobile meta
>>> > tags.
>>> > And we'd be happy to see any of these heuristics incorporated into
>>> > WebKit (either before or after they get standardized) so we don't need
>>> > to
>>> > fork them.
>>>
>>> Kenneth pointed that the XHTML-MP behavior is already on the spec, but on
>>> a
>>> non normative section, the introduction:
>>>
>>> "Certain DOCTYPEs (for instance XHTML Mobile Profile) are used to
>>> recognize
>>> mobile documents which are assumed to be designed for handheld devices,
>>> hence
>>> using the viewport size as the initial containing block size."
>>>
>>> on http://www.w3.org/TR/css-device-adapt/
>>
>>
>> I see. Given this and the fact that Android already does this, I think this
>> change is fine. Do any Apple/iOS folk object?
>>
>> The Android behavior seems a little more conservative to me, so I'd prefer
>> if we did that (e.g. don't mess with zooming). We should make the most
>> minimal change we can to optimize compatibility.
>>
>> Before making this change, I'd still like to see discussion on www-style for
>> this. Specifically, it would be good for this to move to a normative section
>> and to be more concretely specified. This open-ended language is not useful
>> for actually achieving interoperability across mobile browser vendors. It
>> should say specifically which doctypes and how it relates to the viewport
>> meta tag. Again, I prefer the Android behavior here of always having the
>> viewport meta tag win.
>>
>> Speaking of which, given the note in the spec, has there already been
>> discussion on www-style about this?
>>
>> Ojan
>>
>>>
>>>
>>>
>>> > Cheers,
>>> > John
>>> >
>>> > *: (unlike Hugo's current patch, we don't add "initial-scale1.0,
>>> > user-scalableno", just "widthÞvice-width", since there doesn't seem to
>>>
>>> > be any reason to assume that XHTML-MP sites want to disable zooming, and
>>> > it
>>> > may actually lead to a worse user experience).
>>>
>>> You are right, setting just the width should be enough.
>>>
>>> > On Sat, May 5, 2012 at 12:58 PM, Kenneth Rohde Christiansen <
>>> >
>>> > kenneth.christian...@gmail.com> wrote:
>>> > > Hi there,
>>> > >
>>> > > On Sat, May 5, 2012 at 7:12 AM, Ojan Vafai  wrote:
>>> > > > I see. That's unfortunate. I don't really know the best path forward
>>> > >
>>> > > here.
>>> > >
>>> > > > I'm inclined to agree with Alexey that we should at least try to
>>> > >
>>> > > st
>>> ndardize
>>> > >
>>> > > > this before committing code. It's not clear to me where this should
>>> > > > be
>>> > > > specced. Easiest path forward is to make this proposal to both
>>> > > > wha...@whatwg.org for t

Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

[TAMURA, Kent]

I wonder if the standardization is active.  Even the editor's draft has not
been updated for one year.

On Mon, Feb 20, 2012 at 1:44 PM, JongSeok Yang wrote:



Hi webkit-dev!



I want to let you know that I plan to add HTML Media Capture to WebKit.
HTML Media Capture :
http://www.w3.org/TR/2011/WD-html-media-capture-20110414/



The spec has two sparate features - 1) to invoke a capture panel  2)
WebIDL inteface for MediaFile.getFormatData()
First, my plan is just to implement the interface to invoke a capture
panel and it will be behind the ENABLE_HTML_MEDIA_CAPTURE feature define.
See: https://bugs.webkit.org/show_bug.cgi?id=63062



I expect this feature to be eventually enabled by all ports.
If you have any commnet, please let me know.



Thank you.
Jongseok Yang.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





--
TAMURA Kent
Software Engineer, Google



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

Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore

[JongSeok Yang]

Title: Samsung Enterprise Portal mySingle



 
Dear Adam,
 
Thank you for your interest in the implementation.
And I'm sorry that there has been no more action.
 
Your implementation is good to me. My original implementation was just to add "capture" attribute like your.
But, some reviewers did not want to use "FileChooser" "RenderFileUploadControl" for HTML Media Capture.
 
Could you please let know what you think about that?
 
Thanks and regards,
Jongseok.
 
 
--- Original Message ---
Sender : Adam Barth
Date : 2012-05-09 15:50 (GMT+09:00)
Title : Re: Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore
 Jongseok,Did you get around to contributing your patch?  I've uploaded awork-in-progress implementation of one part of the spec here:https://bugs.webkit.org/show_bug.cgi?id=85958Thanks,AdamOn Sun, Feb 19, 2012 at 9:36 PM, JongSeok Yang wrote:>> It's unrelated to WebRTC.> HTML Media Capture is just to get the result file from a native camera or recoder application/panel. So, it's just to choose a file from the outside.> WebRTC is to handle multimedia streams directly. So, it can be used to make a web-based camera application.>> Jongseok Yang. --- Original Message ---> Sender : Adam Barth> Date : 2012-02-20 13:57 (GMT+09:00)> Title : Re: [webkit-dev] Adding ENABLE_HTML_MEDIA_CAPTURE to WebCore>> How does this feature relate to WebRTC ?>> Adam>>> On Sun, Feb 19, 2012 at 8:44 PM, JongSeok Yang wrote: Hi webkit-dev! I want to let you know that I plan to add HTML Media Capture to WebKit.>> HTML Media Capture : http://www.w3.org/TR/2011/WD-html-media-capture-20110414/ The spec has two sparate features - 1) to invoke a capture panel  2) WebIDL inteface for MediaFile.getFormatData()>> First, my plan is just to implement the interface to invoke a capture panel and it will be behind the ENABLE_HTML_MEDIA_CAPTURE feature define.>> See: https://bugs.webkit.org/show_bug.cgi?id=63062 I expect this feature to be eventually enabled by all ports.>> If you have any commnet, please let me know. Thank you.>> Jongseok Yang.>> ___>> webkit-dev mailing list>> webkit-dev@lists.webkit.org>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev