Re: [webkit-dev] New WebKit reviewer: Gyuyoung Kim

[Soo-Hyun Choi]

Good stuff and congratulations, Gyuyoung!


Soo-Hyun


Kenneth Rohde Christiansen wrote:

I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer.

Gyuyoung joined the WebKit team as part of an effort to port WebKit to
the EFL platform. Since then he has taken leadership of the Samsung
activities in WebKit trunk and helped integrating his team members in
the community and community practices. Lately, Gyuyoung have been
focused on adding device API's to WebKit, as well as refocusing the
EFL efforts on WebKit2.

Please join me in congratulating him in his new WebKit reviewer role.


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

Re: [webkit-dev] Adding the Vibration API to WebCore

[Soo-Hyun Choi]

It seems that a WebKit reviewer, Hajime Morrita, created another bug
(https://bugs.webkit.org/show_bug.cgi?id=78085) related to this patch.
As said in the bug #78085, it would be more preferred way not to
access Page and PageClient directly.

The author of this bug might want to check them before asking r+.

Kind regards,
Soo-Hyun


On Thu, Feb 2, 2012 at 03:11, Soo-Hyun Choi  wrote:
>
>
> On 2/2/12 1:01 AM, Robin Berjon wrote:
>> On Feb 1, 2012, at 11:02 , Soo-Hyun Choi wrote:
>>> On 2/1/12 3:00 AM, Simon Fraser wrote:
>>>> My comment was actually meant to be somewhat facetious, and intended to 
>>>> reflect how arbitrary the new APIs are. Why support GamePad input, and not 
>>>> TV remote control input? Why only deal with vibration on a mobile device, 
>>>> and not other kinds of hardware feedback? I don't think they are good APIs.
>>>
>>> Well, you are right in a sense that one may like to see some form of
>>> unified API that can represent various hardware feedback, but I guess
>>> that will take ages to be finalised at the W3C's point of view.
>>
>> If you're talking about full haptic feedback support, it's not just 
>> standards that's the bottleneck (though it would indeed take a while) but 
>> also the fact that it's a fast-moving innovation area that doesn't seem ripe 
>> for standardisation just yet. Also, too few devices are currently equipped 
>> with what it takes to make this interesting.
>
> Absolutely - that's why I have said that this patch shouldn't be
> questioned by the W3C's standard perspective at the particular moment.
> As far as I understand, Simon's original suggestion was to take these
> sort of APIs to W3C and come back later, which doesn't seem to be quite
> reasonable per the reason we discussed.
>
>>
>> I expect that if this becomes a feature of devices that customers come to 
>> expect and that is commonly put to good use, then there will be an API for 
>> it. But I wouldn't hold my breath at this point.
>>
>>> In this respect, I'd like to assume that they are not simply arbitrary
>>> APIs, but interesting ones that might be emerged into some other form(s)
>>> later as W3C elaborates the spec standards.
>>
>> Yes, and not only are they not arbitrary but they are (hopefully) made to be 
>> sufficiently orthogonal so as to be used together properly. If you search 
>> through (http://lists.w3.org/Archives/Public/public-device-apis/) you'll 
>> find a few occurrences of collaboration with the Gamepad team that ensure 
>> that you can call navigator.vibrate() to get your primary device to vibrate, 
>> but also gamepad.vibrate() with everything working the same as soon as you 
>> have a handle on a gamepad.
>>
>
> Fully agreed - I didn't particularly insist it to be integrated in a
> single abstract-level API that can be derived on usage basis. As you've
> mentioned, I agree they can be orthogonal in terms of
> usage/functionality, so it may not necessary at all to make them such way.
>
>
> The whole point I am making here is that it looks quite worthwhile to
> enable this vibration API in the WebKit trunk.
>
>
> Kind regards,
> Soo-Hyun
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Adding the Vibration API to WebCore

[Soo-Hyun Choi]

On 2/2/12 1:01 AM, Robin Berjon wrote:
> On Feb 1, 2012, at 11:02 , Soo-Hyun Choi wrote:
>> On 2/1/12 3:00 AM, Simon Fraser wrote:
>>> My comment was actually meant to be somewhat facetious, and intended to 
>>> reflect how arbitrary the new APIs are. Why support GamePad input, and not 
>>> TV remote control input? Why only deal with vibration on a mobile device, 
>>> and not other kinds of hardware feedback? I don't think they are good APIs.
>>
>> Well, you are right in a sense that one may like to see some form of
>> unified API that can represent various hardware feedback, but I guess
>> that will take ages to be finalised at the W3C's point of view.
> 
> If you're talking about full haptic feedback support, it's not just standards 
> that's the bottleneck (though it would indeed take a while) but also the fact 
> that it's a fast-moving innovation area that doesn't seem ripe for 
> standardisation just yet. Also, too few devices are currently equipped with 
> what it takes to make this interesting.

Absolutely - that's why I have said that this patch shouldn't be
questioned by the W3C's standard perspective at the particular moment.
As far as I understand, Simon's original suggestion was to take these
sort of APIs to W3C and come back later, which doesn't seem to be quite
reasonable per the reason we discussed.

> 
> I expect that if this becomes a feature of devices that customers come to 
> expect and that is commonly put to good use, then there will be an API for 
> it. But I wouldn't hold my breath at this point.
> 
>> In this respect, I'd like to assume that they are not simply arbitrary
>> APIs, but interesting ones that might be emerged into some other form(s)
>> later as W3C elaborates the spec standards.
> 
> Yes, and not only are they not arbitrary but they are (hopefully) made to be 
> sufficiently orthogonal so as to be used together properly. If you search 
> through (http://lists.w3.org/Archives/Public/public-device-apis/) you'll find 
> a few occurrences of collaboration with the Gamepad team that ensure that you 
> can call navigator.vibrate() to get your primary device to vibrate, but also 
> gamepad.vibrate() with everything working the same as soon as you have a 
> handle on a gamepad.
> 

Fully agreed - I didn't particularly insist it to be integrated in a
single abstract-level API that can be derived on usage basis. As you've
mentioned, I agree they can be orthogonal in terms of
usage/functionality, so it may not necessary at all to make them such way.


The whole point I am making here is that it looks quite worthwhile to
enable this vibration API in the WebKit trunk.


Kind regards,
Soo-Hyun

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

Re: [webkit-dev] Adding the Vibration API to WebCore

[Soo-Hyun Choi]

On 2/1/12 3:00 AM, Simon Fraser wrote:
> On Jan 31, 2012, at 12:50 PM, 권기홍 wrote:
> 
>>> For game pads that have vibration feedback, there's obviously a tie-in
>>> with the joystick API here:
>>> 
>>
>> Thanks for your comments Simon. 
>> I can see your point. However, while they can be tied-in each other, the 
>> current specs are not related between them. Perhaps, I envisage the next 
>> version of the vibration API might include the GamePad vibration feature, 
>> though I still think that the current vibration API and the GamePad API are 
>> sufficiently meaningful to be implemented in WebKit.
> 
> My comment was actually meant to be somewhat facetious, and intended to 
> reflect how arbitrary the new APIs are. Why support GamePad input, and not TV 
> remote control input? Why only deal with vibration on a mobile device, and 
> not other kinds of hardware feedback? I don't think they are good APIs.


Well, you are right in a sense that one may like to see some form of
unified API that can represent various hardware feedback, but I guess
that will take ages to be finalised at the W3C's point of view.

Meanwhile, many of us here, perhaps, want those interested features to
be included in WebKit as soon as they become available.

In this respect, I'd like to assume that they are not simply arbitrary
APIs, but interesting ones that might be emerged into some other form(s)
later as W3C elaborates the spec standards.

Kind regards,
Soo-Hyun

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

Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

[Soo-Hyun Choi]

Sachin,

On Thu, Jan 5, 2012 at 15:18, sachin nikam  wrote:
> i am running ubuntu 11.10 64 bit. I was able to eventually build with
> --makeargs="-j1".
> I will try increase the swap space and see if it helps.

WebKit Debug build over Ubuntu 64bit machines should've been fine
without any alteration.

I had troubles for building WebKit Debug over Ubuntu 32bit (3GB RAM),
but got it working by disabling SVG related features:
e.g.,) $> ./Tools/Scripts/build-webkit --efl --debug --no-svg --no-svg-fonts

Hope this helps for those who have similar problems when building WebKit Debug.

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

Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

[Soo-Hyun Choi]

Niko,

On Tue, Jan 3, 2012 at 17:21, Nikolas Zimmermann
 wrote:
> Just a side note: I'm building 32bit release builds on my 32bit MBP from 2006 
> with a set of specific xcode hack that I'm maintaining locally:
> Add all {Editing|Render|DOM}AllInOne.cpp files to build, remove all files 
> from WebCore target that are referenced in those files.
> This allows to use build-webkit, with all default features enabled.
>

WebKit Release build with 32-bit machines are fine without any
modification. People seem to have troubles building Debug option with
those machines. Thanks anyway for your note.

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

Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

[Soo-Hyun Choi]

Philippe,

On Mon, Jan 2, 2012 at 19:40, Philippe Normand  wrote:
> On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote:
>> I synced up the latest webkit code base and am trying to build webkit
>> gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs
>>
>> I tried with --makeargs="-j2" but still got "ld process terminated
>> signal[9]" error  which indicates that it ran out of memory.
>> I suspect i will still the get the same error with --makeargs="-j1".
>> Is there any other flag where we can restrict the memory usage?
>> Regards
>> Sachin
>
> Can you try with the GNU Gold linker? We use it on the GTK Debug bot.


I have tried GNU gold linker (Version: 2.20.1-3ubuntu7.1) on Ubuntu
10.04 (32-bit) without success. Could you let us know how you have
been successful to build WebKit Debug on 32-bit machines in more
detail? I have tried building Efl Debug, by the way.

Kind regards,
Soo-Hyun


>
> Philippe
>
> ___
> 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] Add a set of new APIs for the Custom Scheme and Content Handler.

[Soo-Hyun Choi]

On Wed, Nov 30, 2011 at 02:05, David Levin  wrote:
> Please don't rollback in the change that was rolled out. Feel free to use it
> as a guide but that patch was flawed in that it exposed an api which did
> nothing on some platforms which would break feature detection.
> dave
>

Sure - there's no problem using the rolled-out codes as a guide as you
mentioned.

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

Re: [webkit-dev] Add a set of new APIs for the Custom Scheme and Content Handler.

[Soo-Hyun Choi]

On Tue, Nov 29, 2011 at 17:59, Maciej Stachowiak  wrote:
>
> Looks like I was mistaken and misread the spec, so I withdraw this comment.
>
> Do other browsers that implement the register functions also implement the 
> related isRegistered and unregister functions?

Opera dev team has mentioned about it that they did not implemented
yet: 
.
However, I would envisage that they would check in the mentioned APIs
soon or later.

Also, by reading the spec and using my general sense, it seems all
right going into the development of those two APIs in order to form a
full functionality. When one can register protocol/content handler,
then he would also like to check it if it's registered, and then later
unregister them.

In short, I don't think it is a bad idea to implement these new APIs
in the WebKit at this right moment.

Soo-Hyun



>
>  - Maciej
>
> On Nov 29, 2011, at 12:08 AM, Maciej Stachowiak wrote:
>
>>
>> On Nov 28, 2011, at 8:54 PM, DongWoo Im wrote:
>>
>>> Hi webkit-dev,
>>>
>>> I would like to let you know that I'm planning to add a set of new APIs for 
>>> the Custom Scheme and Content Handler.
>>> ** Specification link : 
>>> http://dev.w3.org/html5/spec/Overview.html#custom-handlers
>>> ** Bugs
>>>    - Custom Scheme Handler :  https://bugs.webkit.org/show_bug.cgi?id=73176
>>>    - Custom Content Handler : https://bugs.webkit.org/show_bug.cgi?id=73177
>>>
>>> Originally, there just defined a kind of set functions, 
>>> 'registerProtocolHandler' and 'registerContentHandler'.
>>>
>>> In this patch (73176, 73177), two more APIs are added per each handler.
>>> (1) an API if a specific URL has been registered or not: 
>>> 'isProtocolHandlerRegistered' and 'isContentHandlerRegistered'.
>>> (2) an API to remove a registered URL: 'unregisterProtocolHandler' and 
>>> 'unregisterContentHandler'.
>>>
>>> I would think these additional APIs could make the Custom Handler more 
>>> useful.
>>>
>>>
>>> Also, I would like to roll back in the implementation of 
>>> 'registerContentHandler', which was rolled out earlier.
>>> This API was landed in r50477, but it rolled out in r62834 because the 
>>> implementation was not completed in any WebKit port.
>>> I will implement this API in the EFL port to support the 
>>> 'registerContentHandler'.
>>>
>>> It would be appreciated if you let me know how we could roll back in the 
>>> 'registerContentHandler'.
>>
>> I think you should propose these to the relevant standards group before 
>> adding them to WebKit (either WHATWG or HTML WG). They do not seem valuable 
>> enough to add as WebKit-only extensions. And other vendors may be against 
>> them, for example, on privacy grounds. So we should discuss with the 
>> standards group first.
>>
>> Regards,
>> Maciej
>> ___
>> 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev