Re: [webkit-dev] WebVR on WebKit

[Alexis Menard]

Hi,

> On Aug 3, 2017, at 9:19 AM, Sergio Villar Senin <svil...@igalia.com> wrote:
> 
> O Xov, 03-08-2017 ás 08:44 -0700, Alexis Menard escribiu:
>> Hi,
>> 
>>> On Aug 3, 2017, at 7:52 AM, Dean Jackson <d...@apple.com> wrote:
>>> 
>>> 
>>> 
>>>> On 2 Aug 2017, at 19:55, Sergio Villar Senin <svil...@igalia.com>
>>>> wrote:
>>>> 
>>>> 
>>>> Our main interest is to eventually have some implementation
>>>> working on
>>>> WebKitGtk and/or WPE on Linux but obviously there is a lot of
>>>> cross-
>>>> platform work that needs to be done as well. Our initial idea
>>>> would be
>>>> to use the OpenVR API as Valve released a Linux version of their
>>>> SDK
>>>> some months ago. Looks like a safe bet as other vendors like
>>>> Firefox or
>>>> Chromium already include it in their trees as third party.
>>> 
>>> I agree with the idea to assume use of the OpenVR SDK at the
>>> moment. It
>>> is the only major VR SDK that is available for macOS, Linux and
>>> Windows.
>>> 
>>> So maybe our platform API should be very similar to the OpenVR API?
>>> I haven't looked at other SDKs like Oculus, but hopefully it isn't
>>> too
>>> different.
>> 
>> You should also keep an eye on OpenXR which is being discussed in
>> Khronos. These seems like the future standard API for applications to
>> hook into to support VR (independently of the underlaying VR
>> runtime). More info there : https://www.khronos.org/openxr
> 
> Right I'm aware of that effort. The thing is that using OpenXR does not
> imply that you can get rid of native SDKs anyway. From conversations I
> had with some other people involved in WebVR efforts it looks like the
> main SDKs (like Oculus or Vive's) will be used anyway if available and
> that OpenXR would be more like a fallback for the hundreds of devices
> that will hit the market soon.

That’s correct that native VR runtimes will still be a requirements but they 
are going to be under the OpenXR application layer (read Oculus and Steam will 
most likely make their runtime OpenXR compliant). The benefits of OpenXR for 
WebKit (or any engine) is that you’ll have a unique backend to talk to a VR 
runtime (whatever the user has installed).

Please note that OpenXR is two folds, an application interface/API for 
applications (say in this case WebKit) to talk to a VR runtime and render stuff 
(as well as getting information from the device) and a Device Layer used by 
HMDs manufacturers (or hundred devices as you say) so that VR runtimes can talk 
to any OpenXR compliant devices. This will help for example SteamVR or Oculus 
Runtime to be compatible with the gazillions of devices flooding the market at 
some point provided the later are compliant with OpenXR.

But OpenXR is 2018 material so indeed OpenVR is probably a good bet for 
immediate support. Please note that SteamVR allows you to use Oculus Rift HMD 
not just HTC Vive so in theory (but I haven’t tried it with OpenVR) you 
shouldn’t need a dedicated backend for Oculus.

> 
> BR

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

Re: [webkit-dev] WebVR on WebKit

[Alexis Menard]

Hi,

> On Aug 3, 2017, at 7:52 AM, Dean Jackson  wrote:
> 
> 
> 
>> On 2 Aug 2017, at 19:55, Sergio Villar Senin  wrote:
>> 
>> 
>> Our main interest is to eventually have some implementation working on
>> WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
>> platform work that needs to be done as well. Our initial idea would be
>> to use the OpenVR API as Valve released a Linux version of their SDK
>> some months ago. Looks like a safe bet as other vendors like Firefox or
>> Chromium already include it in their trees as third party.
> 
> I agree with the idea to assume use of the OpenVR SDK at the moment. It
> is the only major VR SDK that is available for macOS, Linux and Windows.
> 
> So maybe our platform API should be very similar to the OpenVR API?
> I haven't looked at other SDKs like Oculus, but hopefully it isn't too
> different.

You should also keep an eye on OpenXR which is being discussed in Khronos. 
These seems like the future standard API for applications to hook into to 
support VR (independently of the underlaying VR runtime). More info there : 
https://www.khronos.org/openxr 
> 
> Dean
> 
> 
> ___
> 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] Changes in QtWebKit development

[Alexis Menard]

Hi Darin,

I think he forgot to paste the link which add a bit of meat to the
conversation.

http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/

Thanks.


On Fri, Sep 13, 2013 at 2:03 PM, Darin Adler da...@apple.com wrote:

 On Sep 13, 2013, at 4:50 AM, Albisser Zeno zeno.albis...@digia.com
 wrote:

 Qt WebEngine


 What is that? Is it based on a fork of WebKit?

 -- Darin

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




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] error while make webkit clutter

[Alexis Menard]

Hi,

As Benjamin told in the other mail sent earlier : This is the wrong
Mailing list. ClutterWebKit is a completely separate project, it is not
developed on WebKit.org.

Thanks.



On Wed, Jun 12, 2013 at 8:17 AM, sant ssanthsht...@gmail.com wrote:

 following this link https://github.com/rkudiyarov/ClutterWebkit.git

 help me to solve this error
 ./ClutterWebkit-master/WebKitTools/Scripts/build-webkit –prefix=”$ROOT_DIR”
 –host=”$TARGET” –target=”i586-mingw32msvc” –clutter –minimal –debug

 CXX WebCore/svg/libwebkit_clutter_1_0_la-SVGZoomEvent.lo
 CXX WebCore/bindings/js/libwebkit_clutter_1_0_la-ScriptControllerClutter.lo
 CXX WebCore/platform/text/libwebkit_clutter_1_0_la-TextCodecICU.lo
 CXX WebCore/platform/text/libwebkit_clutter_1_0_la-TextBreakIteratorICU.lo
 CXX

 WebCore/platform/graphics/cairo/libwebkit_clutter_1_0_la-FontCacheFreeType.lo
 In file included from ../../WebCore/bridge/npruntime_internal.h:28,
 from ../../WebCore/plugins/PluginStream.h:38,
 from ../../WebCore/plugins/PluginView.h:47,
 from ../../WebCore/bindings/js/ScriptControllerClutter.cpp:35:
 ../../WebCore/bridge/npapi.h:93:22: error: X11/Xlib.h: No such file or
 directory
 ../../WebCore/bridge/npapi.h:94:23: error: X11/Xutil.h: No such file or
 directory
 In file included from ../../WebCore/plugins/PluginStream.h:38,
 from ../../WebCore/plugins/PluginView.h:47,
 from ../../WebCore/bindings/js/ScriptControllerClutter.cpp:35:
 ../../WebCore/bridge/npruntime_internal.h:33:31: error: X11/Xresource.h: No
 such file or directory
 CXX

 WebCore/platform/graphics/cairo/libwebkit_clutter_1_0_la-FontCustomPlatformData.lo
 CXX

 WebCore/platform/graphics/cairo/libwebkit_clutter_1_0_la-FontPlatformDataFreeType.lo
 CXX

 WebCore/platform/graphics/cairo/libwebkit_clutter_1_0_la-GlyphPageTreeNodeCairo.lo
 CXX

 WebCore/platform/graphics/cairo/libwebkit_clutter_1_0_la-SimpleFontDataCairo.lo
 In file included from ../../WebCore/bridge/npruntime_internal.h:28,
 from ../../WebCore/plugins/PluginStream.h:38,
 from ../../WebCore/plugins/PluginView.h:47,
 from ../../WebCore/bindings/js/ScriptControllerClutter.cpp:35:
 ../../WebCore/bridge/npapi.h:269: error: ISO C++ forbids declaration of
 ‘Display’ with no type
 ../../WebCore/bridge/npapi.h:269: error: expected ‘;’ before ‘*’ token
 ../../WebCore/bridge/npapi.h:270: error: ISO C++ forbids declaration of
 ‘Visual’ with no type
 ../../WebCore/bridge/npapi.h:270: error: expected ‘;’ before ‘*’ token
 ../../WebCore/bridge/npapi.h:271: error: ‘Colormap’ does not name a type
 In file included from
 ../../WebCore/bindings/js/ScriptControllerClutter.cpp:35:
 ../../WebCore/plugins/PluginView.h:402: error: ‘Pixmap’ does not name a
 type
 ../../WebCore/plugins/PluginView.h:403: error: ISO C++ forbids declaration
 of ‘Visual’ with no type
 ../../WebCore/plugins/PluginView.h:403: error: expected ‘;’ before ‘*’
 token
 ../../WebCore/plugins/PluginView.h:404: error: ‘Colormap’ does not name a
 type
 ../../WebCore/plugins/PluginView.h:405: error: ISO C++ forbids declaration
 of ‘Display’ with no type
 ../../WebCore/plugins/PluginView.h:405: error: expected ‘;’ before ‘*’
 token
 ../../WebCore/plugins/PluginView.h:407: error: ‘XEvent’ has not been
 declared
 CXX WebKit/clutter/webkit/libwebkit_clutter_1_0_la-webkitenumtypes.lo
 CXX JavaScriptCore/wtf/libJavaScriptCore_la-HashTable.lo
 make[1]: ***
 [WebCore/bindings/js/libwebkit_clutter_1_0_la-ScriptControllerClutter.lo]
 Error 1
 make[1]: *** Waiting for unfinished jobs….
 In file included from ../../WebKit/clutter/webkit/webkitwebview.h:35,
 from ././WebKit/clutter/webkit/webkitenumtypes.h:70,
 from WebKit/clutter/webkit/webkitenumtypes.cpp:6:
 ../../WebKit/clutter/webkit/webkitactor.h:67:7: warning: no newline at end
 of file
 make[1]: Leaving directory
 `/home/emo2/Music/ClutterWebkit/ClutterWebkit-master/WebKitBuild/Debug’
 make: *** [all] Error 2

 Failed to build WebKit using ‘make’!
 root@emo2:/home/emo2/Music# cd ClutterWebkit/
 root@emo2:/home/emo2/Music/ClutterWebkit# cd ClutterWebkit-master/
 root@emo2:/home/emo2/Music/ClutterWebkit/ClutterWebkit-master# make clean
 make[1]: Entering directory
 `/home/emo2/Music/ClutterWebkit/ClutterWebkit-master/JavaScriptCore’
 ( xcodebuild -target All -alltargets clean `perl -I../WebKitTools/Scripts
 -Mwebkitdirs -e ‘print XcodeOptionString()’` | grep -v setenv  exit
 ${PIPESTATUS[0]} )
 /bin/sh: 1: xcodebuild: not found
 make[1]: *** [clean] Error 1
 make[1]: Leaving directory
 `/home/emo2/Music/ClutterWebkit/ClutterWebkit-master/JavaScriptCore’
 make: *** [clean] Error 2

 ./ClutterWebkit-master/WebKitTools/Scripts/build-webkit –prefix=”$ROOT_DIR”
 –host=”$TARGET” –target=”i586-mingw32msvc” \
 –clutter –minimal –debug –with-target=win32
 gives error as

 *** Warning: linker path does not have real file for library -lpthread.
 *** I have the capability to make that library automatically link in when
 *** you link to this library. But I can only do this if you have a
 *** shared version of the library, which you do 

Re: [webkit-dev] Christophe Dumez is now a WebKit reviewer

[Alexis Menard]

Congrats.


On Fri, May 10, 2013 at 10:10 AM, Dongseong Hwang luxte...@gmail.comwrote:

 Congrats, Chris!

 - DS that is using your previous desk in Finland

 On Fri, May 10, 2013 at 11:27 AM, Kenneth Rohde Christiansen 
 kenneth.christian...@gmail.com wrote:

 Congrats! Well deserved!


 On Fri, May 10, 2013 at 9:55 AM, Sudarsana Nagineni 
 nagine...@gmail.comwrote:

 Congratulations Chris!


 On Fri, May 10, 2013 at 3:22 AM, Laszlo Gombos 
 laszlo.gom...@gmail.comwrote:

 Hi,

 I'm happy to announce that Christophe Dumez is now a WebKit reviewer.

 Chris has done great work on WebKit2 (test infrastructure, support for
 new device APIs) and one of the driving forces behind the EFL port. Lately
 he has been doing work on the Soup and GStreamer backends and the binding
 generators.

 Please join me in congratulating Chris !

 Thanks,
   Laszlo


 ___
 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




 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4294 9458 / E-mail kenneth at webkit.org

 ﹆﹆﹆

 ___
 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




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] obtaining webkit.org address?

[Alexis Menard]

Hi,

Stats are totally busted for WebKit because of that so I agree with simon here.

Also with webkit.org email you can't make sure you're speaking on
behalf of your company or not (work time vs spare time).

Thanks.

On Mon, Apr 29, 2013 at 2:17 PM, Simon Fraser simon.fra...@apple.com wrote:
 I don't think WebKit has a strict policy on this.

 I would actually prefer that we phase out webkit.org email addresses. I like
 to be able to determine what someone's affiliation is.

 Simon

 On Apr 28, 2013, at 9:10 PM, Glenn Adams gl...@skynav.com wrote:


 On Sun, Apr 28, 2013 at 8:46 PM, Glenn Adams gl...@skynav.com wrote:

 And if one prefers to use a webkit.org address, like you are doing?


 A little follow-up: when I got my SVN account and credentials earlier this
 year as a committer, I expected to be given or at least asked if I wanted a
 webkit.org address, to which I would have said yes. However, I wasn't asked
 and the credentials went through with my company address. As my company is
 basically just me, I would prefer to use a webkit.org address in order to
 identify better with the community as such. So I'm just now following up on
 this inquiry about how to get a community address.




 On Sun, Apr 28, 2013 at 11:55 AM, Antonio Gomes toniki...@webkit.org
 wrote:

 Previously people used to get SVN accounts associated to a @webkit.org
 alias. Today it seems like it is preferable to get a company email as alias,
 and credential to write-access SVN.


 On Sunday, April 28, 2013, Glenn Adams wrote:

 How does a committer/reviewer obtain a webkit.org address? I notice that
 the majority of existing committers and reviewers have either a webkit.org
 or a chromium.org address listed in contributors.json. I think it an
 important part of being part of the WK community to be able to identify
 oneself as being in that community, and having a usable webkit.org address
 seems a good way to effect that.

 G.





 ___
 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] Feature announcement: Web VHS API

[Alexis Menard]

Hi Ryosuke,

Thank you for the feedback.

On Mon, Apr 1, 2013 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Why are rewind(), forward(), pause() and eject() all blocking APIs? I don't
 think we should be blocking the main thread while those operations are
 taking place.  In particular, rewind() can take anywhere from a few seconds
 to a few minutes.  We should let authors show some kind of UI for rewinding,
 and keep the web page responsive while VHS is rewinded.

The tape WG wanted to preserve the synchronous aspect of the VCR, the
physical eject of a VCR takes few seconds and you're usually watching
it and not doing anything else. It should be the same for the UA.

I tend to agree for rewind() and forward(), we may get them async,
letting UA the freedom to implement a nice rewinding/forwarding
animation while the command is executed.


 I'm also confused by the fact VHSOutput interface has a method,
 streamToYouTube, that specifically supports one website.  Are we expecting
 to add methods like streamToDailyMotion, streamToUStream, etc...?  I'd
 prefer coming up with a generic format and let author specify an URL to
 which the video is streamed.

Yes future-proof APIs were not part of Level 1.


 Also, why are VHSInput and VHSOutput separate interfaces?  It appears that
 all methods on those two interfaces can just be on VHSAccess.

The more complex it appears the more serious it looks like.


 - R. Niwa


 On Mon, Apr 1, 2013 at 4:17 AM, Alexis Menard ale...@webkit.org wrote:

 Hello,

 I would like to let you know that I plan to add support for the Web VHS
 API to WebCore. The Web VHS API is a specification to bring VHS support to
 the Web.

 This support will be behind the ENABLE_WEB_VHS feature define.

 The spec is here:
 http://bit.ly/YVHIga

 Here is the tracking bug:
 https://bugs.webkit.org/show_bug.cgi?id=113697

 Let me know if you have any questions or comments.

 Best regards,
 Alexis

 --
 Software Engineer @
 Intel Open Source Technology Center

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





--
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

[Alexis Menard]

On Tue, Mar 26, 2013 at 5:40 PM, Dirk Pranke dpra...@chromium.org wrote:
 On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.org
 wrote:

 On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote

 If we have consensus that we should just switch to paths relative to
 Source (or maybe a couple different options), that would be (IMO) a big win.
 It sounds like Daniel  co. have already done the big bang conversion.


 I think using full path would be a serious hit regarding hackability.

 I would rather spend some time tweaking my compiler to cache each
 directory content than waste time finding where is every single header I
 need to include.


 Interesting. I have the exact opposite experience, having to paw around to
 figure out where Font.h actually lives rather than just seeing
 WebCore/platform/graphics/Font.h.

But a modern IDE can easily solve that for you. You just click on the
header and it opens it for you. Xcode, QtCreator handles it very well.

That said if you don't use an IDE then I understand your point :).


 At any rate, to be clear, I would be in favor of that change but I'm not
 expecting it to happen :).

 -- Dirk

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




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.

[Alexis Menard]

Hi,

It's now landed http://trac.webkit.org/changeset/141578

Please CC me on bugs that could occur and related to it.

I will move on the CSS Animations now.

Thanks.

On Tue, Jan 29, 2013 at 11:22 PM, Eric Seidel e...@webkit.org wrote:
 Thank you for sharing!

 It appears that unless you're logged into WordPress (I had to go dig
 up my credentials) you just get a 404.


 On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson d...@apple.com wrote:
 Related: when the unprefixed transitions are enabled by default, we plan
 to make a long-overdue blog post on Recent Updates to Transitions and 
 Animations
 where recent means about 2 or 3 years :)

 http://www.webkit.org/blog/?p=2233preview=true

 The idea is that it would cover all the interesting things we've added, even 
 if
 we think most people know about them. Feel free to edit the draft (if that's 
 possible
 - otherwise email me), especially if there are features we've forgotten.

 Dean


 On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote:

 Hi,

 Last month I started working on supporting unprefixed CSS Transitions
 in WebKit. Today this work is guarded behind
 CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in
 trunk (but disabled in Chrome and probably release branches of other
 ports). After various patches we (Dean Jackson and myself) feel
 confident that the work on the transitions is ready for prime time. We
 still have bugs open in our bug tracker but that doesn't block the
 unprefixed version to go live.

 So the proposal is the following one :
 - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to
 CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for
 unprefixing the animations and the transforms (that I plan to focus
 after this).
 - Ship CSS Transitions unprefixed enabled by default with no feature
 flag to disable it.

 My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216

 We can also be proud to say our implementation is maybe the most
 complete one (thanks to the various people involved).

 On a side note the usage of prefixed/unprefixed version is monitored
 through the FeatureObserver so we can later in the future have an idea
 of the usage and maybe remove the prefixed support.

 Thoughts?

 Patched landed :
 http://trac.webkit.org/changeset/141119
 http://trac.webkit.org/changeset/140560
 http://trac.webkit.org/changeset/140448
 http://trac.webkit.org/changeset/140010
 http://trac.webkit.org/changeset/139922
 http://trac.webkit.org/changeset/139762
 http://trac.webkit.org/changeset/139200
 http://trac.webkit.org/changeset/139106
 http://trac.webkit.org/changeset/139070
 http://trac.webkit.org/changeset/138728
 http://trac.webkit.org/changeset/138721
 http://trac.webkit.org/changeset/138184

 Thanks.

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 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
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

[Alexis Menard]

On Thu, Jan 31, 2013 at 6:56 AM, Patrick Gansterer par...@paroga.com wrote:
 Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:

 On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org
 wrote:

 Another option is to add a webkit-patch command for modifying the build
 files. That way, the syntax doesn't need to be overly human friendly. There
 was also some attempt to write a tool to add files automatically:
 https://bugs.webkit.org/show_bug.cgi?id=61772  I would expect that such a
 tool becomes easier if it would only modify one source of truth and
 generates all other artifacts such as Xcode projects from it.


 I don't want build file's syntax to be so human unfriendly that I need a
 tool for it.

 Often times, these syntax problems can be improved dramatically by simple
 changes. e.g. we had a similar discussion about TestExpectation syntax, and
 I'm much happier with the new syntax even though the new syntax is
 functionally equivalent to the old one, and two syntaxes are very similar.

 On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote:

 I’ve experimented with this in the past and you’re right that it shouldn’t
 be particularly difficult to do. However, I suspect that the task would be
 similar in scope to defining an improved syntax for gyp. And if the syntax
 is the primary sticking point with gyp then it’d seem preferable to tackle
 initially.


 Yeah. In fact, we can just come up with whatever syntax we like and convert
 it to the existing gyp format if the syntax was the biggest issue.


 Do we want to define the whole build system (including information how to
 invoke the generators) with the new system, or is a simple list for the
 input files sufficient? IMHO adding a new generator build step happens very
 rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl)
 into new files.
 Then GYP and CMake can read them and generate the build system out of them
 directly (like they to already today) instead of listing the files in the
 *.gpyi and *.cmake. This might work for other systems like qmake too.
 For XCode we can maybe have a template XCode project and generate the
 work XCode project with a script. This script then only need to fill in
 the files from the input file list into the template XCode project.
 Defining the feature flags can be done like Maciej suggested with Port.h
 files.

My 2 cents.

One advantage CMake has over other proposals is that it's already
working for 2 ports (and potentially 4). It is an open source project
so we could potentially contribute to it to add or fix what is needed.
One other good point for CMake is that it's widely used in the
industry and it is backed by a company. When KDE switched over CMake
the guys behind CMake were very very responsive, I believe they will
be too if we plan to switch to CMake. The more famous projects they
have running CMake, the better it is for them. So if we need to
improve the Xcode support then I bet we can count on them. CMake has
also some support in various IDE, and if not then the native solution
is a fallback.

Sure the syntax is maybe not the best but it no worst than Gyp, Xcode,
Makefiles, qmake or some perl script. We already live with all these
syntax and people are also used to edit the CMake related project.

Perfect build system do not exist it's a fact.

On the other hand I don't want to loose the native support like Xcode.
I don't know if many are using it but I find incredibly convenient to
open the Xcode workspace of WebKit, setup the two little things
instructed in the wiki and press cmd+b and it just works, it builds,
it integrate with Xcode (so you get the neat features of pretty output
compiles errors with jumping, ...) and I press cmd+r and it launch
MiniBrowser or something else to debug from within the IDE. This is
what makes the Mac port a very great port to work on.


 -- Patrick

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




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Wishes

[Alexis Menard]

On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel e...@webkit.org wrote:
 I wish we only had one build system (it were easy to add/remove/move files).

 I believe changes like http://trac.webkit.org/changeset/74849 are an
 unhealthy sign for the project.  Adam is not the only person who has chosen
 to empty files instead of removing them.  The pain of updating 8 build
 system is so great, we jump through hoops to avoid it.  Which means it took
 us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
 WebCore/platform.


 I wish I felt like reviewers understood/trusted each other more.

 I’ve worked at both Apple and Google.  The WebKit community is full of
 brilliant engineers.  Yet I frequently feel a lack of trust in my (or
 others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
 don’t think it’s that people don’t trust me after nearly 8 years (!?) on
 this project, but rather that we forget, or fail to communicate trust among
 ourselves.  Social problems are perhaps harder to solve for us technical
 types, but I worry that for many of us it’s just become “us” and “them” and
 we’ve stopped trying.


 I wish it were easy to work on feature branches.

 We have no good solution for features.  For one-patch features, you do them
 on your own.  For larger, you maybe use github or most likely you just land
 on trunk behind a #define.  None of these have worked well.  Some of this is
 the limits of SVN, but it should be trivial for someone to work on a new
 feature a long time, w/o endangering trunk or having massive merge pain
 every day.  Other projects can do this.  So should we.  This is both
 impeding progress, and destabilizing trunk.


 I wish we didn’t have to worry about platforms we couldn’t test.

 It can’t be the job of the core maintainers to care about all the peripheral
 ports which contribute very little core code. Our code needs to be
 structured in such a manner that its easy for the core to march forward,
 while letting the ports catch up as they need to asynchronously.  Platform
 support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
 platform abstractions should be trivial, but core developers (which probably
 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
 worry about keeping all ports working.

Sure. I'm wondering how you would define a peripheral port? Anything
not Apple or Google?

Many little ports are very active every day, sure some of them does
not contribute as much as they should on common parts but some
companies behind these are just limited on resources. They are not
Google or Apple with an army of engineers who have time to take any
spec of W3C and implements it.

In WebCore the contribution is pain mostly because the buildsystem.
For the rest if EWS goes red, in many cases it's a real bug, a real
problem.

Coming from a so called peripheral port I find very frustrating and
demotivating that our contributions are devalorized the way they are
or our reviews discredited. Many of us contributes important feature
and improvements to WebCore and sure not as visible as Google or Apple
in terms of log but still crucial or important.

I believe you and many people are not aware what little ports
contribute because we don't work on high visibility feature such as
Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR,
media queries, viewport interactions, @viewport rule, various work on
tests infrastructure, WebGL fixes) and I'm talking only of the people
in my company and I'm probably forgetting some work. The number of
contributions per day makes hard for me to see what others than Google
or Apple are doing.

I tend to agree that some are not playing the game but for the ones
who try their best it's sad to be rejected like that.



 I wish that the tree always built and tested cleanly.

 Other (much larger) projects than WebKit accomplish this.  Yet somehow
 Google pays 2 full-time engineers to watch our bots and yet we fail.  I know
 other companies do similar.  Automated rollouts is one solution.
 Branched-based development, or trybots are others.  But at the size and
 scale we’re at now, every minute of a broken tree, is 100x or more minutes
 of potentially lost developer productivity.


 I wish I felt like I could follow what was going on (and trust WebKit to
 guard the web, instead of depending on Apple or Google).

 We’re the leading browser engine, with hundreds of committers, any of whom
 can add an API to 50% of internet browsers with a single commit.  I wish we
 had a public process for feature/web-api review.  I wish I felt like both
 major companies were willing participants in such.  (Google has an internal
 process, but it sees limited use, in part because it’s powerless -- a ‘yes’
 from our process is not a ‘yes’ from WebKit.)  I want to feel like I can
 better observe and participate in the development of our web-api (and trust
 that it’s being done well!) without 

[webkit-dev] Enabling unprefixed CSS Transitions by default.

[Alexis Menard]

Hi,

Last month I started working on supporting unprefixed CSS Transitions
in WebKit. Today this work is guarded behind
CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in
trunk (but disabled in Chrome and probably release branches of other
ports). After various patches we (Dean Jackson and myself) feel
confident that the work on the transitions is ready for prime time. We
still have bugs open in our bug tracker but that doesn't block the
unprefixed version to go live.

So the proposal is the following one :
- Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to
CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for
unprefixing the animations and the transforms (that I plan to focus
after this).
- Ship CSS Transitions unprefixed enabled by default with no feature
flag to disable it.

My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216

We can also be proud to say our implementation is maybe the most
complete one (thanks to the various people involved).

On a side note the usage of prefixed/unprefixed version is monitored
through the FeatureObserver so we can later in the future have an idea
of the usage and maybe remove the prefixed support.

Thoughts?

Patched landed :
http://trac.webkit.org/changeset/141119
http://trac.webkit.org/changeset/140560
http://trac.webkit.org/changeset/140448
http://trac.webkit.org/changeset/140010
http://trac.webkit.org/changeset/139922
http://trac.webkit.org/changeset/139762
http://trac.webkit.org/changeset/139200
http://trac.webkit.org/changeset/139106
http://trac.webkit.org/changeset/139070
http://trac.webkit.org/changeset/138728
http://trac.webkit.org/changeset/138721
http://trac.webkit.org/changeset/138184

Thanks.

-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] distributed build for WebKit on Mac OS 10.8

[Alexis Menard]

On Mon, Jan 21, 2013 at 1:41 PM, Mihai Maerean mmaer...@adobe.com wrote:
 Hi


Hi,


 Building WebKit on a MacPro 5,1 (mid 2010 - 2.8GHz quad core Xeon with
 SSD, 20 gb of ram, gigabit LAN) with Mac OS 10.8 takes 30 minutes and it
 really slows down the daily work.

 Buying new Macs is just too expensive and the current ones have plenty of
 computing power if we use them to the full extent.

 Back in the 10.6 days, distcc did a great job at speeding up the builds.

 How can the build of WebKit be distributed on all the Macs in the LAN to
 fully utilize the computing power?


Good question.

You could try :

https://github.com/icecc/icecream

I know for fact that it works fine on linux but it claims to to work
on Mac OS too and according to git log it seems that clang support is
possible.

Let me know if it works for you, I haven't had time to try yet.



 Mihai

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



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

On Sat, Jan 12, 2013 at 10:07 PM, Ryosuke Niwa rn...@webkit.org wrote:
 What happens to corresponding event constructors (e.g.
 WebKitTransitionEvent) and content attributes (e.g. onwebkittransitionend)?

As I said in the mail we'll need to add them (could be done in a
separate patch). There is also some objective-c bindings that I need
to look at.


 On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote:

 Hi all,

 As you know I'm working on unprefixing CSS transitions and I need a
 few advice from the DOM experts.

 Problem : CSS Transitions when they finish to animate send a DOM event
 transitionend as specified there [1] to give the developer a notice
 that the transition finished. Today WebKit sends the prefixed
 counterpart webkitTransitionEnd. Animations also have the same event
 and few more. So today the problem is when we should send the prefixed
 event and when we should send the unprefixed one, and if we should
 send both.

 I think that sending both events will break content somewhere as JS
 functions attached with addEventListener will be called two times.

 Sending only the unprefixed event will break WebKit-only content the
 day we ship CSS Transitions unprefixed. I know they should not produce
 WebKit only code but it's not the point of the discussion.

 A solution is to send the prefixed or the unprefixed event depending
 if someone is listening to it or not. Let me explain.

 Let say there is a listener on the prefixed event only then we deliver
 the prefixed event *only*.

 If there is a listener on the unprefixed event only we deliver the
 unprefixed event *only*.

 If there are listeners on both events then we send the unprefixed one
 *only* forcing people to rely on the unprefixed.

 It seems that this approach is an elegant one and allows us to remove
 later in the future the support for prefixed transitions (including
 the events). As a side note Opera is acting the same as the proposed
 solution.

 Now obviously prefixed and unprefixed events in the DOM is something
 new because it never happens in the past so we don't have support for
 having such a mechanism for event delivery.

 I thought that we could somewhere in the Animation/Transition code be
 smart and try to figure which event to send but it practically
 impossible to access the EventListenerMap so I thought we could
 support it somehow generically in the DOM events code. It will be
 useful for the animations and maybe in the future (we're not really
 sure if prefixed event will again show but who knows).

 So I did a first patch there [2] and I would like to gather feedback
 whether the approach is correct (I don't know much the DOM related
 code) or if somebody has a better idea on how to resolve the problem.
 Also if I have missed something, please point it to me. The patch
 doesn't include the support for HTML ontransitionend attribute which I
 prefer to do in a later patch.

 Thanks.

 [1]
 http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property
 [2] https://bugs.webkit.org/show_bug.cgi?id=105647
 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev





-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote:
 I've been wondering about the implications of prefixed events.  Do we have
 other examples of events that had prefixed names and were later unprefixed?


We've never had such a case in the past. It's the first time we have
to unprefix DOM events.

 In particular, what are the composition implications of your solution?  When
 you say depending
 if someone is listening to it or not you mean whether there is a handler
 attached that will be triggered by this event, not whether there is a
 handler for that type of event anywhere on the page, right?  Is it likely

I'm not sure to understand this part. What is the difference you are
talking about? Do you mean whether the user added an event listener on
an element or on the document. If it's the case then WebKit event
delivery code does not make any difference from what I can see.

 that existing code might put handlers on the document (eg. maybe as a sort
 of polling mechanism when there are many elements that may be involved in
 transitions?), and if so are we likely to have trouble with different
 libraries that used to co-exist peacefully in the same site no longer
 working together?  The philosophy of forcing a site to update to the
 unprefixed name really only makes sense to me if you think of a site as a
 single application, not as a collection of separately maintained libraries
 and components.

Well usually libraries tend to support multiple vendors so if we send
the unprefixed version then I'm pretty sure it's handled somewhere.
For example, Opera and Mozilla ship unprefixed for some time so I
believe anyway the web is slowly updating. Worst I believe that
because WebKit does not ship unprefixed transitions and animations
they end up having code extra to support us.


 Rick

 On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote:

 That does sound like a tricky problem.  Your approach sounds
 reasonable to me.  If you like, we can use the FeatureObserver [1] to
 estimate how often these various cases occur.

 Adam

 [1]
 http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html


 On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org wrote:
  Hi all,
 
  As you know I'm working on unprefixing CSS transitions and I need a
  few advice from the DOM experts.
 
  Problem : CSS Transitions when they finish to animate send a DOM event
  transitionend as specified there [1] to give the developer a notice
  that the transition finished. Today WebKit sends the prefixed
  counterpart webkitTransitionEnd. Animations also have the same event
  and few more. So today the problem is when we should send the prefixed
  event and when we should send the unprefixed one, and if we should
  send both.
 
  I think that sending both events will break content somewhere as JS
  functions attached with addEventListener will be called two times.
 
  Sending only the unprefixed event will break WebKit-only content the
  day we ship CSS Transitions unprefixed. I know they should not produce
  WebKit only code but it's not the point of the discussion.
 
  A solution is to send the prefixed or the unprefixed event depending
  if someone is listening to it or not. Let me explain.
 
  Let say there is a listener on the prefixed event only then we deliver
  the prefixed event *only*.
 
  If there is a listener on the unprefixed event only we deliver the
  unprefixed event *only*.
 
  If there are listeners on both events then we send the unprefixed one
  *only* forcing people to rely on the unprefixed.
 
  It seems that this approach is an elegant one and allows us to remove
  later in the future the support for prefixed transitions (including
  the events). As a side note Opera is acting the same as the proposed
  solution.
 
  Now obviously prefixed and unprefixed events in the DOM is something
  new because it never happens in the past so we don't have support for
  having such a mechanism for event delivery.
 
  I thought that we could somewhere in the Animation/Transition code be
  smart and try to figure which event to send but it practically
  impossible to access the EventListenerMap so I thought we could
  support it somehow generically in the DOM events code. It will be
  useful for the animations and maybe in the future (we're not really
  sure if prefixed event will again show but who knows).
 
  So I did a first patch there [2] and I would like to gather feedback
  whether the approach is correct (I don't know much the DOM related
  code) or if somebody has a better idea on how to resolve the problem.
  Also if I have missed something, please point it to me. The patch
  doesn't include the support for HTML ontransitionend attribute which I
  prefer to do in a later patch.
 
  Thanks.
 
  [1]
  http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property
  [2] https://bugs.webkit.org/show_bug.cgi?id=105647
  --
  Software Engineer @
  Intel Open Source

Re: [webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers rby...@chromium.org wrote:
 On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard ale...@webkit.org wrote:

 On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers rby...@chromium.org wrote:
  I've been wondering about the implications of prefixed events.  Do we
  have
  other examples of events that had prefixed names and were later
  unprefixed?
 

 We've never had such a case in the past. It's the first time we have
 to unprefix DOM events.

  In particular, what are the composition implications of your solution?
  When
  you say depending
  if someone is listening to it or not you mean whether there is a
  handler
  attached that will be triggered by this event, not whether there is a
  handler for that type of event anywhere on the page, right?  Is it
  likely

 I'm not sure to understand this part. What is the difference you are
 talking about? Do you mean whether the user added an event listener on
 an element or on the document. If it's the case then WebKit event
 delivery code does not make any difference from what I can see.


 Sorry, what I'm trying to ask is, what happens when:
  - e1 has a 'webkitTransitiionEnd' handler, and
  - e2 has a 'transitionend' handler

 You made it clear that if e1==e2 then you'd dispatch only transitionend.
 But what about when e1 is neither an ancestor or descendant of e2?  I.e. are
 you looking at all handlers on the page to determine which events to
 dispatch, or only some subset of them specific to the context of the event
 being dispatched?

In that particular case, from my testing e1 handler will be called and
e2 handler too. The case I was raising is if you have an event handler
installed on the same element for both events.



  that existing code might put handlers on the document (eg. maybe as a
  sort
  of polling mechanism when there are many elements that may be involved
  in
  transitions?), and if so are we likely to have trouble with different
  libraries that used to co-exist peacefully in the same site no longer
  working together?  The philosophy of forcing a site to update to the
  unprefixed name really only makes sense to me if you think of a site as
  a
  single application, not as a collection of separately maintained
  libraries
  and components.

 Well usually libraries tend to support multiple vendors so if we send
 the unprefixed version then I'm pretty sure it's handled somewhere.
 For example, Opera and Mozilla ship unprefixed for some time so I
 believe anyway the web is slowly updating. Worst I believe that
 because WebKit does not ship unprefixed transitions and animations
 they end up having code extra to support us.


 Oh, if most important libraries have already updated to always listen for
 the unprefixed events (and most important sites using those libraries have
 updated  to a version that does this), then I agree there shouldn't be any
 such composition concerns.  I don't have any data, but I just assumed with
 the history of CSS animations on webkit-dominated mobile, that there could
 still be a lot of deployed code (especially in the mobile space) that looks
 only for webkitTransitionEnd.

Adam proposed a solution to gather data, I think we should do it.


 
  Rick
 
  On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth aba...@webkit.org wrote:
 
  That does sound like a tricky problem.  Your approach sounds
  reasonable to me.  If you like, we can use the FeatureObserver [1] to
  estimate how often these various cases occur.
 
  Adam
 
  [1]
  http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html
 
 
  On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard ale...@webkit.org
  wrote:
   Hi all,
  
   As you know I'm working on unprefixing CSS transitions and I need a
   few advice from the DOM experts.
  
   Problem : CSS Transitions when they finish to animate send a DOM
   event
   transitionend as specified there [1] to give the developer a notice
   that the transition finished. Today WebKit sends the prefixed
   counterpart webkitTransitionEnd. Animations also have the same
   event
   and few more. So today the problem is when we should send the
   prefixed
   event and when we should send the unprefixed one, and if we should
   send both.
  
   I think that sending both events will break content somewhere as JS
   functions attached with addEventListener will be called two times.
  
   Sending only the unprefixed event will break WebKit-only content the
   day we ship CSS Transitions unprefixed. I know they should not
   produce
   WebKit only code but it's not the point of the discussion.
  
   A solution is to send the prefixed or the unprefixed event depending
   if someone is listening to it or not. Let me explain.
  
   Let say there is a listener on the prefixed event only then we
   deliver
   the prefixed event *only*.
  
   If there is a listener on the unprefixed event only we deliver the
   unprefixed event *only*.
  
   If there are listeners on both events then we send

[webkit-dev] Unprefixed and prefixed DOM events.

[Alexis Menard]

Hi all,

As you know I'm working on unprefixing CSS transitions and I need a
few advice from the DOM experts.

Problem : CSS Transitions when they finish to animate send a DOM event
transitionend as specified there [1] to give the developer a notice
that the transition finished. Today WebKit sends the prefixed
counterpart webkitTransitionEnd. Animations also have the same event
and few more. So today the problem is when we should send the prefixed
event and when we should send the unprefixed one, and if we should
send both.

I think that sending both events will break content somewhere as JS
functions attached with addEventListener will be called two times.

Sending only the unprefixed event will break WebKit-only content the
day we ship CSS Transitions unprefixed. I know they should not produce
WebKit only code but it's not the point of the discussion.

A solution is to send the prefixed or the unprefixed event depending
if someone is listening to it or not. Let me explain.

Let say there is a listener on the prefixed event only then we deliver
the prefixed event *only*.

If there is a listener on the unprefixed event only we deliver the
unprefixed event *only*.

If there are listeners on both events then we send the unprefixed one
*only* forcing people to rely on the unprefixed.

It seems that this approach is an elegant one and allows us to remove
later in the future the support for prefixed transitions (including
the events). As a side note Opera is acting the same as the proposed
solution.

Now obviously prefixed and unprefixed events in the DOM is something
new because it never happens in the past so we don't have support for
having such a mechanism for event delivery.

I thought that we could somewhere in the Animation/Transition code be
smart and try to figure which event to send but it practically
impossible to access the EventListenerMap so I thought we could
support it somehow generically in the DOM events code. It will be
useful for the animations and maybe in the future (we're not really
sure if prefixed event will again show but who knows).

So I did a first patch there [2] and I would like to gather feedback
whether the approach is correct (I don't know much the DOM related
code) or if somebody has a better idea on how to resolve the problem.
Also if I have missed something, please point it to me. The patch
doesn't include the support for HTML ontransitionend attribute which I
prefer to do in a later patch.

Thanks.

[1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property
[2] https://bugs.webkit.org/show_bug.cgi?id=105647
-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Unprefixing CSS Animation, Transitions and Transform.

[Alexis Menard]

Hi all,

I would like to announce that I will start the work to unprefix CSS
Animations, Transitions and Transform. It may sounds quick to do but
it's not, there are few things to do before we can unprefix and
unleash them to the world (e.g. -webkit-perspective accept valueless
number but perspective doesn't) and we need to make few fixes to do to
make sure we are compliant with the spec while keeping the behaviour
as-is for the current unprefixed version. Also there is few
unimplemented things.

The bug is tracked here : https://bugs.webkit.org/show_bug.cgi?id=93136

In the following days I will add new bugs as blocker to this one to
track the work left to do. If you think of something missing feel free
to open a new bug and mark is as blocker for 93136. Please put a
detailed description on the bug.

I will land the work behind a feature flag
CSS_TRANSFORM_ANIMATION_TRANSITION_UNPREFIXED (I accept alternatives
on the name :), I believe three feature flags for that is overkill)
enabled by default on trunk as it is important for me to get the bots
running the code. You can turn off the feature in your release
branches up until the work is done (maybe afterwards we should even
remove the feature flag).

Thanks.

-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Unprefixing CSS Animation, Transitions and Transform.

[Alexis Menard]

On Wed, Dec 12, 2012 at 10:52 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
 I believe we also want to keep the unprefixed versions using the
 current behavior.

 Do you intent to keep these?

Yes as I said in the original mail : while keeping the behaviour
as-is for the current unprefixed version.

That's why there will be a bit of plumbing work to allow this.


 Cheers
 Kenneth

 On Wed, Dec 12, 2012 at 2:49 PM, Alexis Menard ale...@webkit.org wrote:
 Hi all,

 I would like to announce that I will start the work to unprefix CSS
 Animations, Transitions and Transform. It may sounds quick to do but
 it's not, there are few things to do before we can unprefix and
 unleash them to the world (e.g. -webkit-perspective accept valueless
 number but perspective doesn't) and we need to make few fixes to do to
 make sure we are compliant with the spec while keeping the behaviour
 as-is for the current unprefixed version. Also there is few
 unimplemented things.

 The bug is tracked here : https://bugs.webkit.org/show_bug.cgi?id=93136

 In the following days I will add new bugs as blocker to this one to
 track the work left to do. If you think of something missing feel free
 to open a new bug and mark is as blocker for 93136. Please put a
 detailed description on the bug.

 I will land the work behind a feature flag
 CSS_TRANSFORM_ANIMATION_TRANSITION_UNPREFIXED (I accept alternatives
 on the name :), I believe three feature flags for that is overkill)
 enabled by default on trunk as it is important for me to get the bots
 running the code. You can turn off the feature in your release
 branches up until the work is done (maybe afterwards we should even
 remove the feature flag).

 Thanks.

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

 ﹆﹆﹆



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Tue, Dec 4, 2012 at 8:36 AM, Alexis Menard ale...@webkit.org wrote:
 On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote:

 On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 Why does this feature have a flag at all? background-position with up to 4 
 arguments is specified with CSS3 background and borders. There are three 
 major implementations with this feature. So we are just catching up. If the 
 future works as expected (and we should have tests that verify it), then we 
 should remove the flag completely.

 Sounds like good practice to me.

 Why _not_ start that feature with a flag then remove the flag when fully 
 ready/tested???

 Depends on the future. But for such a small patch, a new flag seems to be 
 overdone. I looked into the patch, and adding the flag caused more code, 
 then the actual feature (even if the computed style is missing). I believe 
 we should remove the flag ASAP. Flags are for bigger new features of 
 features that likely will change IMO. Both seems not to be the case for 
 background-position.

 The computed style is there see
 http://trac.webkit.org/changeset/136378. I split the whole thing into
 two pieces to ease the review process.

So as today the feature is enable on all ports with bots (Chromium,
Mac, GTK, Qt, EFL) and tests are doing fine. We had to rebase a test
in ietestcenter that was buggy because it was landed with a wrong
expected png, luckily the Chromium bots were here to tell me.

I also turned on the feature for -webkit-mask which now align with the spec [1].

Anybody objects to remove the flag?


[1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property



 Greetings,
 Dirk


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

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



 --
 Software Engineer @
 Intel Open Source Technology Center



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

Le 10 déc. 2012 09:24, Alexis Menard ale...@webkit.org a écrit :

 On Tue, Dec 4, 2012 at 8:36 AM, Alexis Menard ale...@webkit.org wrote:
  On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote:
 
  On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org
wrote:
 
  On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com
wrote:
  Why does this feature have a flag at all? background-position with up
to 4 arguments is specified with CSS3 background and borders. There are
three major implementations with this feature. So we are just catching up.
If the future works as expected (and we should have tests that verify it),
then we should remove the flag completely.
 
  Sounds like good practice to me.
 
  Why _not_ start that feature with a flag then remove the flag when
fully ready/tested???
 
  Depends on the future. But for such a small patch, a new flag seems to
be overdone. I looked into the patch, and adding the flag caused more code,
then the actual feature (even if the computed style is missing). I believe
we should remove the flag ASAP. Flags are for bigger new features of
features that likely will change IMO. Both seems not to be the case for
background-position.
 
  The computed style is there see
  http://trac.webkit.org/changeset/136378. I split the whole thing into
  two pieces to ease the review process.

 So as today the feature is enable on all ports with bots (Chromium,
 Mac, GTK, Qt, EFL) and tests are doing fine. We had to rebase a test
 in ietestcenter that was buggy because it was landed with a wrong
 expected png, luckily the Chromium bots were here to tell me.

 I also turned on the feature for -webkit-mask which now align with the
spec [1].

 Anybody objects to remove the flag?



The patch is there https://bugs.webkit.org/show_bug.cgi?id=104539 up for
review. The mac ews is sick at the moment but my work environment is Mac so
it should be fine.

 [1]
http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property

 
 
  Greetings,
  Dirk
 
 
  Benjamin
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
  --
  Software Engineer @
  Intel Open Source Technology Center



 --
 Software Engineer @
 Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote:

 On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote:
 Why does this feature have a flag at all? background-position with up to 4 
 arguments is specified with CSS3 background and borders. There are three 
 major implementations with this feature. So we are just catching up. If the 
 future works as expected (and we should have tests that verify it), then we 
 should remove the flag completely.

 Sounds like good practice to me.

 Why _not_ start that feature with a flag then remove the flag when fully 
 ready/tested???

 Depends on the future. But for such a small patch, a new flag seems to be 
 overdone. I looked into the patch, and adding the flag caused more code, then 
 the actual feature (even if the computed style is missing). I believe we 
 should remove the flag ASAP. Flags are for bigger new features of features 
 that likely will change IMO. Both seems not to be the case for 
 background-position.

The computed style is there see
http://trac.webkit.org/changeset/136378. I split the whole thing into
two pieces to ease the review process.


 Greetings,
 Dirk


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

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



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

Hi everyone,

I wanted to let you know that I have added the new CSS3
background-position offsets support to WebKit.

This support is behind the ENABLE_CSS3_BACKGROUND feature define and
it's disabled by default on all ports. I took the conservative
approach despite it's a cool feature.

Long story short, it allows you to specify three or four values to
background-position. It's a nice addition as you can now position the
images using length or values in relation to any of the four corners
of elements, not just the top left corner.

Opera, IE10 and Firefox implements this feature already (though the
latter returns weird results using getComputedStyle).

It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
two patches landed (parsing and rendering) are
http://trac.webkit.org/changeset/135632 and
http://trac.webkit.org/changeset/136378.

I believe the position type (3-4 values) could be/or is used in
other cases so we can reuse the parsing code for four/three values if
needed. I will investigate this afterwards and make appropriate
patches.

I plan to enable it by default on Qt and EFL ports this week. If
somebody wants me to enable it on their ports please tell me, I'll be
happy to do it.

Looking forward to your comments.

Spec : http://www.w3.org/TR/css3-background/#the-background-position

-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote:

 Hi everyone,

 I wanted to let you know that I have added the new CSS3
 background-position offsets support to WebKit.

 This support is behind the ENABLE_CSS3_BACKGROUND feature define and
 it's disabled by default on all ports. I took the conservative
 approach despite it's a cool feature.

 Long story short, it allows you to specify three or four values to
 background-position. It's a nice addition as you can now position the
 images using length or values in relation to any of the four corners
 of elements, not just the top left corner.

 Opera, IE10 and Firefox implements this feature already (though the
 latter returns weird results using getComputedStyle).

 It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
 two patches landed (parsing and rendering) are
 http://trac.webkit.org/changeset/135632 and
 http://trac.webkit.org/changeset/136378.

 I believe the position type (3-4 values) could be/or is used in
 other cases so we can reuse the parsing code for four/three values if
 needed. I will investigate this afterwards and make appropriate
 patches.

 I really hope that we don't use it any where else again (with the exception 
 of -webkit-mask-position which should have same behavior as 
 background-position). This is the use case for the calc() function. Sadly the 
 calc() function came to late for CSS3 Backgrounds.

-webkit-mask-position should behave the same way as
background-position? Even if I add feature to the latter? Why so?

it seems like transform-origin supports something similar. I need to look at it.

http://www.w3.org/TR/css3-transforms/#transform-origin-property


 That said, great work regarding the interoperability with other browsers.

 Greetings,
 Dirk



 I plan to enable it by default on Qt and EFL ports this week. If
 somebody wants me to enable it on their ports please tell me, I'll be
 happy to do it.

 Looking forward to your comments.

 Spec : http://www.w3.org/TR/css3-background/#the-background-position

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Mon, Dec 3, 2012 at 10:42 AM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 5:31 AM, Alexis Menard ale...@webkit.org wrote:

 On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote:

 Hi everyone,

 I wanted to let you know that I have added the new CSS3
 background-position offsets support to WebKit.

 This support is behind the ENABLE_CSS3_BACKGROUND feature define and
 it's disabled by default on all ports. I took the conservative
 approach despite it's a cool feature.

 Long story short, it allows you to specify three or four values to
 background-position. It's a nice addition as you can now position the
 images using length or values in relation to any of the four corners
 of elements, not just the top left corner.

 Opera, IE10 and Firefox implements this feature already (though the
 latter returns weird results using getComputedStyle).

 It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
 two patches landed (parsing and rendering) are
 http://trac.webkit.org/changeset/135632 and
 http://trac.webkit.org/changeset/136378.

 I believe the position type (3-4 values) could be/or is used in
 other cases so we can reuse the parsing code for four/three values if
 needed. I will investigate this afterwards and make appropriate
 patches.

 I really hope that we don't use it any where else again (with the exception 
 of -webkit-mask-position which should have same behavior as 
 background-position). This is the use case for the calc() function. Sadly 
 the calc() function came to late for CSS3 Backgrounds.

 -webkit-mask-position should behave the same way as
 background-position? Even if I add feature to the latter? Why so?

 Because -webkit-mask and background share the same properties and syntax. Why 
 should it be different on -webkit-mask-position? (Btw. CSS Masking already 
 adapted the background-position syntax for mask-position[1])

Ok sure. Then I will make -webkit-mask-position to behave the same per
http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position
. I did know they share the code but I didn't know how far. Thanks for
pointing it out.



 it seems like transform-origin supports something similar. I need to look at 
 it.

 http://www.w3.org/TR/css3-transforms/#transform-origin-property

 It definitely does not :)

Sorry about that I read super quickly and based my thought of one of
the test of css3test.com which expect right 10px bottom 20px and
https://bugs.webkit.org/show_bug.cgi?id=37514#c8 . I'm not sure what
is valid or not. Maybe Simon could tell us.


 Greetings,
 Dirk

 [1] 
 http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position



 That said, great work regarding the interoperability with other browsers.

 Greetings,
 Dirk



 I plan to enable it by default on Qt and EFL ports this week. If
 somebody wants me to enable it on their ports please tell me, I'll be
 happy to do it.

 Looking forward to your comments.

 Spec : http://www.w3.org/TR/css3-background/#the-background-position

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Mon, Dec 3, 2012 at 12:08 PM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 6:12 AM, Alexis Menard ale...@webkit.org wrote:

 On Mon, Dec 3, 2012 at 10:42 AM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 5:31 AM, Alexis Menard ale...@webkit.org wrote:

 On Mon, Dec 3, 2012 at 10:19 AM, Dirk Schulze dschu...@adobe.com wrote:

 On Dec 3, 2012, at 4:51 AM, Alexis Menard ale...@webkit.org wrote:

 Hi everyone,

 I wanted to let you know that I have added the new CSS3
 background-position offsets support to WebKit.

 This support is behind the ENABLE_CSS3_BACKGROUND feature define and
 it's disabled by default on all ports. I took the conservative
 approach despite it's a cool feature.

 Long story short, it allows you to specify three or four values to
 background-position. It's a nice addition as you can now position the
 images using length or values in relation to any of the four corners
 of elements, not just the top left corner.

 Opera, IE10 and Firefox implements this feature already (though the
 latter returns weird results using getComputedStyle).

 It is tracked by https://bugs.webkit.org/show_bug.cgi?id=37514 and the
 two patches landed (parsing and rendering) are
 http://trac.webkit.org/changeset/135632 and
 http://trac.webkit.org/changeset/136378.

 I believe the position type (3-4 values) could be/or is used in
 other cases so we can reuse the parsing code for four/three values if
 needed. I will investigate this afterwards and make appropriate
 patches.

 I really hope that we don't use it any where else again (with the 
 exception of -webkit-mask-position which should have same behavior as 
 background-position). This is the use case for the calc() function. Sadly 
 the calc() function came to late for CSS3 Backgrounds.

 -webkit-mask-position should behave the same way as
 background-position? Even if I add feature to the latter? Why so?

 Because -webkit-mask and background share the same properties and syntax. 
 Why should it be different on -webkit-mask-position? (Btw. CSS Masking 
 already adapted the background-position syntax for mask-position[1])

 Ok sure. Then I will make -webkit-mask-position to behave the same per
 http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position
 . I did know they share the code but I didn't know how far. Thanks for
 pointing it out.



 it seems like transform-origin supports something similar. I need to look 
 at it.

 http://www.w3.org/TR/css3-transforms/#transform-origin-property

 It definitely does not :)

 Sorry about that I read super quickly and based my thought of one of
 the test of css3test.com which expect right 10px bottom 20px and
 https://bugs.webkit.org/show_bug.cgi?id=37514#c8 . I'm not sure what
 is valid or not. Maybe Simon could tell us.

 Simon and I discussed it with the CSS WG and we came to the conclusion that 
 we should not introduce the background-position syntax somewhere else in 
 favor for calc(). -webkit-mask is so similar to background, that people have 
 the expectations to behave the same. This is why -webkit-mask-position is an 
 exception.

Cool then I will make it behave the same.


 Greetings
 Dirk



 Greetings,
 Dirk

 [1] 
 http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-position



 That said, great work regarding the interoperability with other browsers.

 Greetings,
 Dirk



 I plan to enable it by default on Qt and EFL ports this week. If
 somebody wants me to enable it on their ports please tell me, I'll be
 happy to do it.

 Looking forward to your comments.

 Spec : http://www.w3.org/TR/css3-background/#the-background-position

 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Software Engineer @
 Intel Open Source Technology Center
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Software Engineer @
 Intel Open Source Technology Center



-- 
Software Engineer @
Intel Open Source Technology Center
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Alexis Menard]

On Dec 3, 2012 6:21 PM, Dirk Schulze dschu...@adobe.com wrote:


 On Dec 3, 2012, at 1:15 PM, Benjamin Poulain benja...@webkit.org wrote:

  On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze dschu...@adobe.com
wrote:
  Depends on the future. But for such a small patch, a new flag seems to
be overdone. I looked into the patch, and adding the flag caused more code,
then the actual feature (even if the computed style is missing). I believe
we should remove the flag ASAP. Flags are for bigger new features of
features that likely will change IMO. Both seems not to be the case for
background-position.
 
  See http://trac.webkit.org/wiki/AddingFeatures
 

 The policy for adding new (major) features to WebKit is:

 major says everything IMO. background-position is not a major feature.

 However, to stay at the topic: Is there anything blocking
'background-position' with the new syntax? Any objections to remove the
flags? If yes, I would like to know more about the problems.


I can still remove the flag when everything is done. Probably tomorrow or
so.

 Greetings,
 Dirk

  I personally appreciate when authors take the time to have feature
flags until the feature is finished. It has many advantages for making
releases.
 
  Benjamin
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho

[Alexis Menard]

Congrats!

On Mon, Oct 8, 2012 at 6:44 PM, Alexis Menard men...@kde.org wrote:
 Congrats!

 On Mon, Oct 8, 2012 at 6:27 PM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:
 Congrats!

 On Mon, Oct 8, 2012 at 11:20 PM,  noam.rosent...@nokia.com wrote:
 I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer.
 Caio has been working in many areas in the past years, starting with focus 
 on the Qt port with improvements to the Qt/JS bridge, font test results and 
 render-theme.
 More recently has also work on the UndoManager and other aspects of editing 
 code and CSS parsing, his latest contributions being around WTF HashMap 
 iterators.
 Since Caio has been involved in so many parts of WebKit, I'm probably 
 forgetting a few other contributions...

 Please join me in congratulating Caio for his new reviewer status!
 No'am
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Kenneth Rohde Christiansen
 Senior Engineer, WebKit, Qt, EFL
 Phone  +45 4093 0598 / E-mail kenneth at webkit.org

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

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Alexis Menard]

On Thu, Jul 19, 2012 at 3:01 PM, Oliver Buchtala
oliver.bucht...@googlemail.com wrote:
 On 19.07.2012 19:53, Andreas Kling wrote:

 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:


 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
 wrote:

  On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
  On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
  wrote:
 
  Hi,
 
  For those who secretly use printf debugging :). I know the
  recommended way is to use a debugger and it's not the point of this
  discussion.
 
  A lot of us do this, and sometimes it's necessary.  I agree with the
  gripe and support adding something easier.
 
  So I propose wtf() and its stream operator.
 
  Usage :
 
  wtf()HelloWorld34.53322323; will output : Hello World 3
  4.53322
 
  There is no reason to bring in stream operators - that are willfully
  absent from WebCore - just for debugging.
 
 
  But it's really nice for that purpose, and somehow match std::cout

 And we quite purposefully don't use std::cout in the project.

  Overloading functions works just as well.
 
  I'm not sure to understand what you mean here…

 I mean relying on C++'s overloading of functions for the different types
 you'd like to printf debug.

 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);

 etc etc etc.

 debug(someFrame);
 debug(someNode);
 debug(someString);

 Especially that last one would help me from remembering how to type
 printf(%s, someString.utf8().data()) which is all I've ever really
 wanted.


 Hello fellow printfers!

 While I'm just as ashamed of my printf habits as the next guy, I think it'd
 be great if we could move forward with this somehow.

 Coming from a background in Qt, the stream operator syntax looks perfectly
 normal to me, perhaps you could expand on why we want to avoid using these
 in WebKit. Is there a technical reason, or is it more of a language purity
 issue?

 Regardless, adding a consistent set of debug(WebCore::MyCoolOverload)
 methods as suggested would still be massively useful.

 -Kling


 Hi,

 I am probably one of those people who much dislike printf-debugging.
 What is your problem with using a debugger?

Say you have a low powered machine that can't link WebKit in debug
even stripped out of SVG etc...


 Maybe because the displayed information is not appropriate?
 E.g., you would like
 someString.utf8().data()
 instead of
 someString

 FWIW, there is a gdb python API for changing the behavior... so called
 pretty printers.
 It is not too difficult to write such pretty-printers.

I think we have some of those.


 Maybe providing a set of useful pretty-printers is a better approach than
 providing a set of debug functions?

 Regards,
 Oliver


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




-- 
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/webkit-dev

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Alexis Menard]

On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote:
 One reason for preferring printf syntax is that it results in dramatically
 more compact code. In JSC we take advantage of this to have debug printf
 support built even in release builds. So or example if you want CodeBlock to
 print itself in a release build, you don't first have to #define a bunch of
 things - the relevant method is already built.

As the Changelog said in the patch, thingy()  ... are not meant to
land but to help you locally.


 The reason for the compactness is the number of calls for a typical printing
 action. Consider this:

 dataLog(foo %d bar %x baz %p\n, a, b, c);

 This is one procedure call and one string constant. Note that the machine
 code to get the string constant is often as big as a procedure call, on some
 platforms.

 Now consider the stream form:

 thingy  foo   a   bar   someWeirdNonsenseToEnableHex  b  
 baz   c  endl;

Ok you give me a valid example (and nice looking) for you in JSC.
Nobody force you to use the thingy if you don't like it. It seems low
level printf is better for you, great!

Now see another use case :

LayoutRect rect;
printf(Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), rect.height());

for me to get the rect values.

thingy()  rect; (as LayoutRect could have a  overload, I give an
example in the patch with IntRect)

Granted we can achieve it with a

printf(Rect is %s, debug(rect)); same provided that debug() for a
LayoutRect is implemented.

One way or another I'm fine. I just want to ease the process here.


 This is 8 procedure calls and three string constants. This code will be
 somewhere around 8 times fatter. Hence, you will be less likely to want to
 enable such debug statements in release builds both due to fears concerning
 unnecessary increases in binary size, and unnecessary increases in compile
 times.

As I said, we do not want to land these thingy() .


 And I'm not even going to start complaining about how unnatural it is to set
 padding preferences, switch to hex, etc.

Which is not what the class is meant to solve.


 -Filip

 On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote:

 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:


 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
 wrote:

  On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
 
  On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
  wrote:
 
  Hi,
 
  For those who secretly use printf debugging :). I know the
  recommended way is to use a debugger and it's not the point of this
  discussion.
 
  A lot of us do this, and sometimes it's necessary.  I agree with the
  gripe and support adding something easier.
 
  So I propose wtf() and its stream operator.
 
  Usage :
 
  wtf()HelloWorld34.53322323; will output : Hello World 3
  4.53322
 
  There is no reason to bring in stream operators - that are willfully
  absent from WebCore - just for debugging.
 
 
  But it's really nice for that purpose, and somehow match std::cout

 And we quite purposefully don't use std::cout in the project.

  Overloading functions works just as well.
 
  I'm not sure to understand what you mean here…

 I mean relying on C++'s overloading of functions for the different types
 you'd like to printf debug.

 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);

 etc etc etc.

 debug(someFrame);
 debug(someNode);
 debug(someString);

 Especially that last one would help me from remembering how to type
 printf(%s, someString.utf8().data()) which is all I've ever really
 wanted.


 Hello fellow printfers!

 While I'm just as ashamed of my printf habits as the next guy, I think it'd
 be great if we could move forward with this somehow.

 Coming from a background in Qt, the stream operator syntax looks perfectly
 normal to me, perhaps you could expand on why we want to avoid using these
 in WebKit. Is there a technical reason, or is it more of a language purity
 issue?

 Regardless, adding a consistent set of debug(WebCore::MyCoolOverload)
 methods as suggested would still be massively useful.

 -Kling

 ___

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


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




-- 
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/webkit-dev

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Alexis Menard]

On Thu, Jul 19, 2012 at 4:11 PM, Filip Pizlo fpi...@apple.com wrote:
 But I do want a debugging utility to does land, is always compiled in, and 
 that everyone enjoys using.

The header itself in the patch would land so you can use it right away
(and compile even in release). But the actual traces or thingy()
calls in the code are not meant to stay/land. I'm not sure I'm clear.


 -Filip

 On Jul 19, 2012, at 11:37 AM, Alexis Menard alexis.men...@openbossa.org 
 wrote:

 On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote:
 One reason for preferring printf syntax is that it results in dramatically
 more compact code. In JSC we take advantage of this to have debug printf
 support built even in release builds. So or example if you want CodeBlock to
 print itself in a release build, you don't first have to #define a bunch of
 things - the relevant method is already built.

 As the Changelog said in the patch, thingy()  ... are not meant to
 land but to help you locally.


 The reason for the compactness is the number of calls for a typical printing
 action. Consider this:

 dataLog(foo %d bar %x baz %p\n, a, b, c);

 This is one procedure call and one string constant. Note that the machine
 code to get the string constant is often as big as a procedure call, on some
 platforms.

 Now consider the stream form:

 thingy  foo   a   bar   someWeirdNonsenseToEnableHex  b  
 baz   c  endl;

 Ok you give me a valid example (and nice looking) for you in JSC.
 Nobody force you to use the thingy if you don't like it. It seems low
 level printf is better for you, great!

 Now see another use case :

 LayoutRect rect;
 printf(Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), 
 rect.height());

 for me to get the rect values.

 thingy()  rect; (as LayoutRect could have a  overload, I give an
 example in the patch with IntRect)

 Granted we can achieve it with a

 printf(Rect is %s, debug(rect)); same provided that debug() for a
 LayoutRect is implemented.

 One way or another I'm fine. I just want to ease the process here.


 This is 8 procedure calls and three string constants. This code will be
 somewhere around 8 times fatter. Hence, you will be less likely to want to
 enable such debug statements in release builds both due to fears concerning
 unnecessary increases in binary size, and unnecessary increases in compile
 times.

 As I said, we do not want to land these thingy() .


 And I'm not even going to start complaining about how unnatural it is to set
 padding preferences, switch to hex, etc.

 Which is not what the class is meant to solve.


 -Filip

 On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote:

 On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote:


 On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
 wrote:

 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:

 On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
 wrote:

 Hi,

 For those who secretly use printf debugging :). I know the
 recommended way is to use a debugger and it's not the point of this
 discussion.

 A lot of us do this, and sometimes it's necessary.  I agree with the
 gripe and support adding something easier.

 So I propose wtf() and its stream operator.

 Usage :

 wtf()HelloWorld34.53322323; will output : Hello World 3
 4.53322

 There is no reason to bring in stream operators - that are willfully
 absent from WebCore - just for debugging.

 But it's really nice for that purpose, and somehow match std::cout

 And we quite purposefully don't use std::cout in the project.

 Overloading functions works just as well.

 I'm not sure to understand what you mean here…

 I mean relying on C++'s overloading of functions for the different types
 you'd like to printf debug.

 void debug(WebCore::String);
 void debug(WebCore::Frame*);
 void debug(WebCore::Node*);

 etc etc etc.

 debug(someFrame);
 debug(someNode);
 debug(someString);

 Especially that last one would help me from remembering how to type
 printf(%s, someString.utf8().data()) which is all I've ever really
 wanted.


 Hello fellow printfers!

 While I'm just as ashamed of my printf habits as the next guy, I think it'd
 be great if we could move forward with this somehow.

 Coming from a background in Qt, the stream operator syntax looks perfectly
 normal to me, perhaps you could expand on why we want to avoid using these
 in WebKit. Is there a technical reason, or is it more of a language purity
 issue?

 Regardless, adding a consistent set of debug(WebCore::MyCoolOverload)
 methods as suggested would still be massively useful.

 -Kling

 ___

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


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



 --
 Alexis

Re: [webkit-dev] Web APIs and class name collisions

[Alexis Menard]

So far in the css/ directory we tried to renamed slowly classes so that :

CSS* prefixed classes are the implementation of CSSOM
whatevername is for internal classes. For example we renamed
CSSStyleApplyProperty class to StyleBuilder because it's internal.

Hope that helps.

On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser simon.fra...@apple.com wrote:
 I'd prefer we keep Region for the low-level graphics primitive Region
 (just like Path), and use something prefixed for the higher-level layout
 concept.

 Simon

 On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote:

 On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll
 also suggest we rename the existing Region class now that the term region
 has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion?

 IntRegion? It seems closer to an IntRect than a LayoutRect.

 - Ryosuke

 On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote:

 I would go with CSSRegion, and stick it in the css/ folder.  Much of
 the CSS folder is our implementation of the CSS Object Model (CSSOM).
 At some point it might make sense to pull all the classes which
 implement the CSSOM out of css/ into a new cssom/ similar to dom/, but
 that's a later discussion.

 -eric

 On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur abu...@adobe.com wrote:
  From my knowledge the CSS prefix is reserved for the CSS engine
  classes in
  WebKit. Prefixing the Region class with CSS could prove confusing.
 
  Regards,
  Andrei.
 
  From: Alan Stearns stea...@adobe.com
  Date: Thursday, July 12, 2012 7:39 PM
  To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com
 
  Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Web APIs and class name collisions
 
  The spec itself consistently and deliberately calls them CSS Regions,
  so a
  CSS prefix could be appropriate.
 
  Thanks,
 
  Alan
 
 
  From: Adam Barth aba...@webkit.org
  To: Andrei Bucur abu...@adobe.com
  Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] Web APIs and class name collisions
 
  One common thing we do is prefix DOM to DOM-level concepts.  For
  example,
  DOMWindow and DOMFileSystem.  I'm not sure if we have an established
  convention for CSS-level concepts.
 
  Adam
 
 
  On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.com wrote:
 
  Hello Webkittens!
 
  While implementing the Region interface (
  http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've
  noticed
  that the name Region is already taken by a class in
  platform/graphics. I'd
  like to know what's the best approach in these kind of situations:
 
  Rename the existing WebCore class to something else and use the name
  Region for the Web API so there's parity between the implementation
  and
  the spec
  Somehow prefix the Web API implementation class name?
 
  As the Web APIs expand I suppose this situation may occur again in the
  future and I suppose there should be a rule describing what's the best
  approach to take.
 
  Thanks!
  Andrei.
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev


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


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



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




-- 
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/webkit-dev

Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.

[Alexis Menard]

On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:

 On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote:

 Hi,

 For those who secretly use printf debugging :). I know the
 recommended way is to use a debugger and it's not the point of this
 discussion.

 A lot of us do this, and sometimes it's necessary.  I agree with the gripe 
 and support adding something easier.

 So I propose wtf() and its stream operator.

 Usage :

 wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322

 There is no reason to bring in stream operators - that are willfully absent 
 from WebCore - just for debugging.


But it's really nice for that purpose, and somehow match std::cout

 Overloading functions works just as well.

I'm not sure to understand what you mean here...


 ~Brady



-- 
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/webkit-dev

[webkit-dev] Easing printf based debugging in WebKit with an helper.

[Alexis Menard]

Hi,

For those who secretly use printf debugging :). I know the
recommended way is to use a debugger and it's not the point of this
discussion.

The other day I was working on the Mac port (with no real possibility
to have a debug build) and I missed a lot a great feature we have in
Qt : qDebug(). I find the usage of printf cumbersome (so is LOG and
dataLog).
QDebug prettify and ease printf based debug workflow. Even in WebKit
using QDebug is pretty handy as very important core types of WebKit
have a Qt representation (e.g. WTF::String can be converted to a
QString). So you can do something like : String string(HELLO);
qDebug()string and it just output HELLO for you. Much more
efficient (to write ofc) than : fprintf(stderr, %s\n,
string.utf8().data());
Still today a lot of WebKit core type have no counterpart in Qt (and
will never have) so qDebug pretty much fail (worst case it shows a
pointer address if possible).

I'm also aware of NSLog but it unfortunately only work in objective c files.

Then I thought about adding a dedicated debugging helper for WebKit in
general, not Qt related so it could benefit everyone not just a given
port.

So I propose wtf() and its stream operator.

Usage :

wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322

IntRect rect(10, 20, 50, 100);
wtf()Rectrect; will output : Rect IntRect(10,20 50x100)

VectorString v;
v.append(3);
v.append(4);
v.append(5);
wtf()v; will output : Vector (3, 4, 5);

These are basic examples but we can really extend it to virtually
anything, like higher level classes.

Here is the bug with a patch attached :

https://bugs.webkit.org/show_bug.cgi?id=90823

wtf() is not meant to stay in a given function/patch. It is for
developers only who wants to debug, we don't want to add overhead in
release build and we do have the LOG macro doing a job similar.

An other alternative could be to extend dataLog to support this
streaming operator case. I'm open to this alternative too.

It's a work in progress but I want to get feedback before I continue
further (adding some stream operator overload for example) and also I
need to make sure it builds on all ports.

Do you think it is useful? Do you think it will ease/make you faster
when debugging when you use printf? Do you want that in WebKit?

I'm open to suggestion and maybe later improvements (such as showing
the line numbers, fct names...). If people think that is useless then
forget about it.

Thanks.

-- 
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/webkit-dev

Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?

[Alexis Menard]

On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser simon.fra...@apple.com wrote:
 I think imported tests should be outside of LayoutTests/fast.

I agree a dedicated folder seems more appropriate.

My two cents.


 Simon

 On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote:

 Hi,

 I realized that there are a whole bunch of tests in LayoutTests/css3 that
 use layoutTestController (e.g. css3/calc, css3/filters, etc...), which
 appears to mean that they're our own tests. However, css3/selectors3 is an
 imported W3C test suite. It's very confusing to mix imported tests and
 WebKit's own tests. Can we put the imported W3C tests in imported-w3c
 directory as proposed earlier?

 Best,
 Ryosuke Niwa
 Software Engineer
 Google Inc.

 ___
 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




-- 
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

[webkit-dev] Deprecation of CSSStyleDeclaration - getPropertyShorthand method.

[Alexis Menard]

Hi,

Let's try the new deprecation process documented as
http://trac.webkit.org/wiki/DeprecatingFeatures.

I would like to propose the deprecation and removal of
getPropertyShorthand of CSSStyleDeclaration.

State of art :
- This method is exposed to the Web.
- Its purpose is to get whether a given CSS property was set from
within a shorthand (i.e.
shouldBeEqualToString(test0.style.getPropertyShorthand('overflow-x'),
overflow); is true if the CSS code is setting the overflow and not
overflow-x).
- It is used in 4 layout tests (fast/inspector-support/style.html,
fast/css/font-shorthand.html, fast/css/overflow-property.html,
fast/backgrounds/repeat/resources/background-repeat-shorthand.js)
- It is exposed in the Objective C API.
- It is not implemented by any other vendors (Opera, Firefox, Internet
Explorer).
- There is no specification about it.
- It was added in 2005 http://trac.webkit.org/changeset/11481.

Why removing it?
- It reduces the complexity : CSSProperty class doesn't need to handle
the shorthandID member anymore (and we can remove all the related
functions, simplify the constructor), CSSParser could loose its
m_currentShorthand and m_inParseShorthand members, we also can remove
ShorthandScope class as it would not be needed anymore (ShorthandScope
is created on the stack every time we parse a shorthand). Almost no
impact on performance or memory but still a very good cleanup.
- The API doesn't seem to bring much

Cons?
- It is exposed to the web therefore it could potentially break
something. A quick search of getPropertyShorthand on google doesn't
show much except stuff happening on webkit.org (i know this is far
from being accurate on whether this function is used or not but it
means nobody ever wrote about it).
- It is exposed in objective C. Maybe some Apple folks could figure
out if someone is using it inside Apple?

This function was added by Dave Hyatt and reviewed by Maciej
Stachowiak, maybe you guys can tell us why you added it back then (if
your memory is very good as we are talking about 2005 material)?

Thoughts?

Thanks.

-- 
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] Deprecation of CSSStyleDeclaration - getPropertyShorthand method.

[Alexis Menard]

On Mon, May 21, 2012 at 3:21 PM, Evan Martin e...@chromium.org wrote:
 On Mon, May 21, 2012 at 11:09 AM, Alexis Menard
 alexis.men...@openbossa.org wrote:
 - It is exposed to the web therefore it could potentially break
 something. A quick search of getPropertyShorthand on google doesn't
 show much except stuff happening on webkit.org (i know this is far
 from being accurate on whether this function is used or not but it
 means nobody ever wrote about it).

 A search over the code on github:
  https://github.com/search?q=getPropertyShorthand+-InjectedScript+-CSSStyleDeclaration+-DOMCSSStyleDeclaration+-%22overflow-property-expected%22+-style.htmlrepo=langOverride=start_value=1type=Codelanguage=

 found at least one user:
  https://github.com/keishi/JSSyntaxHighlight/blob/14467eef9ae9a4e4624d8ee5bac0b8e0b42b7db1/utilities.js#L390
 However, that file has an Apple copyright on it so it might be
 borrowed from the inspector or something.

Indeed it was borrowed from there. I couldn't find where it is shown
in the Inspector, what part of the UI. Maybe someone can point me
that.


 (Github's search query syntax isn't so predictable so I may have
 missed something.)


 I also checked Google's source repository (e.g. gmail/docs/etc) and
 found no uses.



-- 
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] Deprecation of CSSStyleDeclaration - getPropertyShorthand method.

[Alexis Menard]

On Mon, May 21, 2012 at 4:29 PM, Maciej Stachowiak m...@apple.com wrote:

 On May 21, 2012, at 11:09 AM, Alexis Menard alexis.men...@openbossa.org 
 wrote:

 Hi,

 Let's try the new deprecation process documented as
 http://trac.webkit.org/wiki/DeprecatingFeatures.

 I would like to propose the deprecation and removal of
 getPropertyShorthand of CSSStyleDeclaration.

 State of art :
 - This method is exposed to the Web.
 - Its purpose is to get whether a given CSS property was set from
 within a shorthand (i.e.
 shouldBeEqualToString(test0.style.getPropertyShorthand('overflow-x'),
 overflow); is true if the CSS code is setting the overflow and not
 overflow-x).
 - It is used in 4 layout tests (fast/inspector-support/style.html,
 fast/css/font-shorthand.html, fast/css/overflow-property.html,
 fast/backgrounds/repeat/resources/background-repeat-shorthand.js)
 - It is exposed in the Objective C API.
 - It is not implemented by any other vendors (Opera, Firefox, Internet
 Explorer).
 - There is no specification about it.
 - It was added in 2005 http://trac.webkit.org/changeset/11481.

 [...]

 This function was added by Dave Hyatt and reviewed by Maciej
 Stachowiak, maybe you guys can tell us why you added it back then (if
 your memory is very good as we are talking about 2005 material)?

 I don't know of any reason for this to exist other than for benefit of the 
 inspector. It appears to no longer be used by the Web Inspector, thought it 
 has its own function with the same name (assuming I am reading the code 
 right). It would be fine to stop exposing it to the web if it is in fact 
 unused or hardly used.

I was looking at the code of the inspector and also assuming I'm
reading the code right it is not used.

The C++ method getPropertyShorthand seems to be used in
InspectorStyleSheet.cpp which then is used in
inspector/front-end/CSSStyleModel.js and its usage seems to be
confined in styleTextWithShorthands which is not used anywhere (at at
least grep says so).

But Pavel and Vsevolod can confirm that.


  - Maciej




-- 
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] Qt Mac buildbot got crazy

[Alexis Menard]

On Mon, Apr 30, 2012 at 7:49 AM, Alexis Menard
alexis.men...@openbossa.org wrote:
 On Sat, Apr 28, 2012 at 3:41 AM, Osztrogonac Csaba o...@inf.u-szeged.hu 
 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] *.webkit.org is down

[Alexis Menard]

Hi,

Many contributors in #webkit have problems to connect to bugs.webkit.org.

Wiliam could you look at it?

Thanks.

On Thu, Jan 19, 2012 at 7:51 PM, Jesus Sanchez-Palencia
je...@webkit.org wrote:
 It's back! :)

 cheers,
 jesus


 On Thu, Jan 19, 2012 at 7:26 PM, William Siegrist wsiegr...@apple.com
 wrote:

 I think you have the same problem as Gustavo. His email to webkit-dev
 seems to imply a problem in between Brazil and webkit.org.

 -Bill


 On Jan 19, 2012, at 2:00 PM, Alexis Menard wrote:

  Hi,
 
  I can't also access from home : IP - 186.215.1.122
 
  Thanks.
 
  On Thu, Jan 19, 2012 at 6:05 PM, William Siegrist wsiegr...@apple.com
  wrote:
  If you are still having trouble access the site, send me your IP
  address and
  I will see if its anything on the server.
 
  -Bill
 
 
 
 
  On Jan 19, 2012, at 12:34 PM, Jesus Sanchez-Palencia wrote:
 
  I'm also in Brazil and I can confirm it doesn't work for me as well.
 
  I guess kov is also in Brazil and I just saw him mentioning on IRC that
   both bugs.webkit.org and git.webkit.org are timing out...
 
  Cheers,
  Jesus
 
  On Thu, Jan 19, 2012 at 5:24 PM, Philip Rogers p...@google.com wrote:
 
  http://www.downforeveryoneorjustme.com/
 
  (It's up for me too).
 
 
  On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nicholls jar...@webkit.org
  wrote:
 
  On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard
  alexis.men...@openbossa.org wrote:
 
  Hi,
 
  It seems that *.webkit.org are down (bugs.webkit.org,
  trace.webkit.org,
  …).
 
 
  I can confirm here in Maryland, USA that www, bugs, trac, etc. are
  all
  up.
 
 
 
  Here in Brazil we can't access to any of them. I tried two different
  internet providers with their own DNS and I even tried google DNS
  with no
  luck.
 
 
  Might you try OpenDNS?  208.67.222.222/208.67.220.220
 
 
  Talking to some people in #webkit it seems that not everyone is
  affected
  (maybe only people outside US?).
 
  Anyone who knows where the servers sits would mind to have a look at
  them?
 
  Thank you very much.
  ___
  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
 
 
  ___
  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
 
 
 
 
  --
  Alexis Menard (darktears)
  Software Engineer
  INdT Recife Brazil





-- 
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] Qt Mac buildbot got crazy

[Alexis Menard]

On Sat, Apr 28, 2012 at 3:41 AM, Osztrogonac Csaba o...@inf.u-szeged.hu 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.

 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Debugging With Xcode

[Alexis Menard]

Hi,

On Mon, Apr 23, 2012 at 10:07 PM, Mark Rowe mr...@apple.com wrote:

 On 2012-04-23, at 18:02, Eric Seidel e...@webkit.org wrote:

 Does anyone still debug WebKit on Mac OS X with Xcode 4?


 1.  I don't know how to actually set up Xcode to point to WebKitBuild
 like it used to.
 http://www.webkit.org/building/debug.html
 Mentions a Legacy option which does not exist for me.

I also didn't manage to make it work for me also. I managed to get
Safari launching (after a long wait) but when running debug it doesn't
stop on the breakpoints.



 This page was updated recently to reflect the terminology used in the
 current version of Xcode. The diff may provide the information you need to
 get this working in earlier versions of Xcode.

 2.  Xcode tries to Re-index WebCore, seemingly every time I open
 WebCore.xcodeproj.  This is a hour+ process on my 12-core Mac Pro!

 The re-indexing takes a lot of processing power, and seems to render
 both my machine, and Xcode largely unusable.


 That's interesting. If you're seeing that with the latest released version
 of Xcode then I'd strongly suggest filing a bug report at
 http://bugreport.apple.com/ so that the Xcode folks can address it.

I also noticed the same, every git pull start to re-index the entire
project and my old MacBook Pro almost die away after that.

I use the latest Mac App store version.

Additional question : is it possible to actually build WebCore or any
subproject (JSC, ...) from XCode so you could get a fancy ui for
compilation issues (maybe provided you already ran once build-webkit)
?


 - Mark


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




-- 
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] trac.webkit.org is down

[Alexis Menard]

Hi,

On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote:
 This should be fixed now.

trac is down today for us.

bugs.webkit.org is also down with this error :

Software error:

Can't connect to the database.
Error: could not connect to server: Operation timed out
Is the server running on host 10.0.99.99 and accepting
TCP/IP connections on port ?
  Is your database installed and up and running?
  Do you have the correct username and password selected in localconfig?

Thanks.


 -Bill


 On Feb 29, 2012, at 5:40 AM, Ashod Nakashian wrote:

 Update: trac.webkit.org was back up for a short while then died again.
 (Could we the eastern-hemispherics be overloading it?)
 Where previously it was not responding at all, now it's protesting...

 Traceback (most recent call last):
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
 line 376, in send_error
 'text/html')
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/chrome.py,
 line 733, in render_template
 message = req.session.pop('chrome.%s.%d' % (type_, i))
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/api.py,
 line 195, in __getattr__
 value = self.callbacks[name](self)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/main.py,
 line 265, in _get_session
 return Session(self.env, req)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
 line 157, in __init__
 self.get_session(sid)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
 line 178, in get_session
 super(Session, self).get_session(sid, authenticated)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/web/session.py,
 line 51, in get_session
 db = self.env.get_db_cnx()
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/env.py,
 line 285, in get_db_cnx
 return DatabaseManager(self).get_connection()
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/api.py,
 line 92, in get_connection
 return self._cnx_pool.get_cnx(self.timeout or None)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
 line 176, in get_cnx
 return _backend.get_cnx(self._connector, self._kwargs, timeout)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/pool.py,
 line 109, in get_cnx
 cnx = connector.get_connection(**kwargs)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
 line 69, in get_connection
 params)
   File
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/trac/db/postgres_backend.py,
 line 185, in __init__
 cnx = psycopg.connect(' '.join(dsn))
 OperationalError: server closed the connection unexpectedly
   This probably means the server terminated abnormally
   before or while processing the request.


 
 From: Ashod Nakashian ashodnakash...@yahoo.com
 To: WebKit Development webkit-dev@lists.webkit.org
 Sent: Wednesday, February 29, 2012 2:40 PM
 Subject: [webkit-dev] trac.webkit.org is down

 Hi,

 As of ~20mins ago trac.webkit.org is down, webkit.org, bugs and build are
 OK. Don't know who to notify so I'm spamming webkit-dev, sorry.

 Who should be contacted in such cases?

 -Ash

 ___
 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




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] When should we turn on new features?

[Alexis Menard]

On Mon, Feb 13, 2012 at 11:09 PM, Maciej Stachowiak m...@apple.com wrote:

 I think we're talking about a couple of different things now:

 1) Table of what the WebKit community as a whole (instead of individual point 
 maintainers) thinks should be enabled in stable releases. This would be input 
 to port maintainers looking to make a release.

 2) Documenting what enable flags are actually on for given ports as shipped. 
 Probably hard to gather this info, but might be useful input for the WebKit 
 community.

 3) Changing build systems to enable compiling nightly and stable versions 
 from the same tree, so both modes are documented in trunk. Requires some 
 coding for various build systems.

 I like (2) and (3), but I don't think they replace the usefulness of (1). I 
 think the mention of the feature-table page is blending (2) and (1), which 
 would serve different purposes.

Hi,

I think one is totally useful and more than welcome. I would say that
the page should sit in the SVN so that whenever someone add a feature
the file had to be updated too. Also when someone add some UI bits for
a given port he can also update the file/page accordingly. The closer
this file is to the code the more chance it has to be up to date.

In QtWebKit we had
http://trac.webkit.org/wiki/QtWebKitSupportedStandards (but not up to
date) to track which release comes with what. It's missing the last
release funny enough.

There will be an initial work on each port to fill the default values
but hey nothing comes for free.


 Regards,
 Maciej


 On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:

 (Re-sending from the right address...)

 I'd +1 Adam's point.

 It would be great if we can do something like webkit-build --gtk
 --stable, webkit-build --chromium --canary or webkit-build
 --nightly where the script read the central configuration file and
 find an appropriate configuration. In this way, there would be no
 duplication we should maintain.

 Even though some ports currently don't support switches through
 build-webkit, we can gradually switch over to the central list-based
 configuration settings by, for example, generating features.gypi,
 FeatureDefines.xcconfig or a set of flags for autoconf.

 Also the feature-table page could be generated from the list. We can
 even start from simply generating an HTML from the machine-readable
 configuration file, then integrate it to each build system.

 Although it might be overkill, I personally prefer this kind of don't
 repeat youself direction.
 --
 morrita

 On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote:

 On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:

 On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:

 I think you raise a good point. Another point worth mentioning is that
 sometimes a feature can be complete and useful in one port, but half-baked
 in another (for example, fullscreen API was shipped in Safari and at the
 same time present but non-functional in Chrome).

 I think in the past, port owners have made clear that they want to own the
 final decisions on what features are enabled in their ports.

 But we as a community could do better, by having a shared recommendation
 of what features we think should be enabled in shipping releases. In some
 cases, this may not match the settings on trunk, as some features may be
 desirable to enable for experimental builds, but not in shipping product.
 For features that we recommended disabling, ideally we'd identify a reason.
 And in some cases, those might be port-specific issues.


 Right. Even just having a list of new features with flag(s) to
 enable/disable and the status (e.g. list of outstanding bugs) on wiki page
 will be helpful.

 For example, vertical writing mode doesn't work on Windows, Chromium, etc...
 but port owners may not necessarily realize that the feature is enabled by
 default and each port needs to modify the code that draws text.


 I personally think such a page would be a good idea. I'd love to hear input
 from more folks on whether this is a good idea and what the right approach
 is.

 Cheers,
 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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Alexis Menard]

On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
 On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:

 In the light of discovering that some SVN scripts have fallen behind in
 terms of maintenance[1] and WebKit's strong Git support and infrastructure,
 against my better judgement, I'd like to distract you from being productive
 by bringing up this topic (again).

 The wiki page of the same name[2] was created 3 years ago and hardly
 updated since[3]. I know we're all busy with more important things, but IMHO
 I think we can at least update the wiki and perhaps vote on when/how we
 should do the eventual transition.

 I understand that while this type of work isn't necessarily very
 productive, maintaining two repositories and sets of scripts (with their
 docs and issues) has a very real cost as well. I'm proposing we reevaluate
 the situation and act accordingly.


 Re-evaluating the situation is good, but I'm still opposed.

I don't use svn but the only benefit I see of WebKit using svn is the
linear history, clean, easy to read and to explore. Git repos tend to
have merging commits a lot and it leads to make bisecting/history
browsing harder (my taste).

Then for everything else I use git and its power locally.


 - Ryosuke


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




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Alexis Menard]

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik kpias...@rim.com wrote:
 It is possible to keep linear history with git.  This just requires you to 
 fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

 Konrad
 Sent from my BlackBerry on the Rogers Wireless Network

 - Original Message -
 From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
 Sent: Thursday, March 08, 2012 12:27 PM
 To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Moving to Git?

 El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
 On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
  On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian ashodnakash...@yahoo.com
  wrote:
 
  In the light of discovering that some SVN scripts have fallen behind in
  terms of maintenance[1] and WebKit's strong Git support and 
  infrastructure,
  against my better judgement, I'd like to distract you from being 
  productive
  by bringing up this topic (again).
 
  The wiki page of the same name[2] was created 3 years ago and hardly
  updated since[3]. I know we're all busy with more important things, but 
  IMHO
  I think we can at least update the wiki and perhaps vote on when/how we
  should do the eventual transition.
 
  I understand that while this type of work isn't necessarily very
  productive, maintaining two repositories and sets of scripts (with their
  docs and issues) has a very real cost as well. I'm proposing we reevaluate
  the situation and act accordingly.
 
 
  Re-evaluating the situation is good, but I'm still opposed.

 I don't use svn but the only benefit I see of WebKit using svn is the
 linear history, clean, easy to read and to explore. Git repos tend to
 have merging commits a lot and it leads to make bisecting/history
 browsing harder (my taste).

 I agree about merging commits, but I think it's possible to enforce all
 merges to be fast-forward and without merging commits. In general
 browsing git history is easier and cleaner than svn, and more important
 it's much faster (my taste :-P)

 Then for everything else I use git and its power locally.

 I would be more than happy with the switch :-)

 --
 Carlos Garcia Campos
 http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3

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

 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Alexis Menard]

 of 
  commits
  is crucial.

 I think this is an interesting point. It seems there are two solutions. We
 can enforce fast-forward as many have pointed out and we can maintain an SVN
 mirror. Although I don't like the idea of maintaining an SVN repo, and it's
 almost universally agreed that git offers superior tools to SVN.

 I don't think so. I like the simplicity of svn. While git client works
 great, I always get frustrated by the complexity of having multiple branches
 locally and the amount of work required to merge the remote changes on the
 branch I'm working on.

 - Ryosuke


 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from your
 system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 --
 --Antonio Gomes
 ___
 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




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

[Alexis Menard]

On Thu, Mar 8, 2012 at 7:30 PM, Alexis Menard
alexis.men...@openbossa.org wrote:
 On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote:

 It seems like there are a couple of different issues here that affect how we
 do version control. Currently we have an SVN primary repository, some
 contributors use SVN, and others use git via git-svn.

 It seems like there are two possible changes we can make, and it is not
 really clear to me which is being advocated:

 1) Offer only a git repository; everyone uses git.
 2) Use a git central repository; but some form of svn access is provided (is
 this even possible?)

 And then there is the status quo:

 3) Continue doing what we're doing; central repository is svn, but anyone is
 free to use git and we try to make it convenient to do so.

 One interesting asymmetry here is that, while many git users proseltyze git
 and advocate total removal of svn support from our tools and infrastructure,
 no one seems to advocate completely removing git support. So I left that
 option off. There are also other distributed version control systems out
 there such as Mercurial or Bazaar, but no one seems much in favor of using
 them for WebKit, so those options are also left off.

 If we are to assess these options in a deeper way than just everyone saying
 what they personally like, we need to identify the pros and cons of options
 (1) and (2) relative to (3). That's assuming (2) is even possible. It seems
 like there are at least a few factors to consider:

 A) Future quality of life for current git users.
 B) Future quality of life for current svn users.
 C) Benefits of the master repository being either git or svn, regardless of
 what clients are supported. (For example, many folks seem to think
 human-understandable revision identifiers is a benefit of the master being
 SVN).
 D) Cost to the project of maintaining support for two different version
 control systems.

 Git advocates on this thread have mostly focused on convincing svn users how
 much they'd like using git instead. It seems at least some svn users do not
 believe their quality of life would improve by switching to git, including
 some who have actually tried git. No one has really identified what benefits
 there would be to git users if a change is made. Could someone describe
 those?

 To the global infrastructure :
 - Local history for git. svn log access to the server every time you
 call that command. Will improve the load of the server.
 - Performance of checkouts/pull as data are send compressed from the server.

 To git user :
 - Using git push rather than having to use git-svn (which you need to
 keep in sync).
 - Simplified workflow, we don't need to mess with git-svn.
 - Companies who fork (we all do) can simplify their workflow a bit
 regarding branches.

 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts

- Bot maintainers :
Power outage or network interruption in the middle of a svn
checkout/up lock the repo sometimes and you need to manually svn
cleanup the checkout (maybe someone have a tool or script to avoid
that???). I had much more svn locked repos than git dead checkout
because of interruptions.


 The real downside is for the svn users to learn a bit git workflow.

 I'm forgetting stuff for sure.


 Regards,
 Maciej


 On Mar 8, 2012, at 12:13 PM, Antonio Gomes wrote:

 (For those valuable contributors who are against Git and have manifested
 somehow here, please do not take it personally)

 IMO, none of the arguments used here so far seem like a real problem for a
 switch. Of course, SVN people would have to adapt their workflow and it
 could take days (no more than that, trust me), but it is for a greater goal
 at the end.

 In my opinion, SVN concepts are completely obsolete these days. It is hard
 to me to even hear someone arguing in favor of SVN against GIT, but I
 respect anyone's opinion. I just do not feel them strong enough given the
 whole context.

 On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason jma...@rim.com wrote:

 It seems to me that there's no need to use multiple local branches in git
 if you find it confusing - it's an additional feature, but I don't see
 anything that requires it.

 What workflow do you have that requires you to have multiple branches
 locally in git, and how do you solve it in svn without using branches?

 What precisely do you find difficult about merging remote changes, and how
 is the svn equivalent easier?
 
 From: webkit-dev-boun...@lists.webkit.org
 [webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa
 [rn...@webkit.org]
 Sent: Thursday, March 08, 2012 3:00 PM
 To: Ashod Nakashian

[webkit-dev] RDF related stuff in WebKit.

[Alexis Menard]

Hi,

I stumble across the RDF work in W3C. I was wondering if that make
sense for WebKit.

What WebKit could do with the semantic data extracted from the
document? Feeding some underlaying indexing application? Or to help
some application embedding WebKit but interested in extracting the
data using the proposed JS API?

How this relate to HTML Microdata? Does it conflict? Does it cover more stuff?

Thanks for the pointers.

Links :
http://www.w3.org/TR/2012/WD-rdfa-core-20120131/
http://www.w3.org/TR/2011/WD-rdfa-api-20110419/
http://www.w3.org/TR/2012/WD-xhtml-rdfa-20120131/
http://www.w3.org/TR/2012/WD-microdata-rdf-20120112/
http://www.w3.org/TR/2011/WD-rdfa-in-html-20110525/

-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Including new IETestCenter tests in the LayoutTests

[Alexis Menard]

The code we submit in WebKit has to be BSD or LGPL compatible code.
(/me remember how hard it is to find real world CSS BSD compatible
chunk to write a perf test)

I found http://msdn.microsoft.com/en-us/cc300389.aspx then you have to
see if that is ok for us. In any case the copyright is Microsoft.

On Tue, Feb 14, 2012 at 9:31 PM, Adam Barth aba...@webkit.org wrote:
 On Tue, Feb 14, 2012 at 3:03 PM, Dave Tharp dth...@codeaurora.org wrote:
 I am currently looking at the WebKit CSS3  failures on IETestCenter
 (http://samples.msdn.microsoft.com/ietestcenter/ ).

 I’m making some progress, and getting ready to submit a patch.  I’ve
 contacted Beth Dakin about my approach on the first patch, and she says I
 should proceed.

 As part of the patch, of course I need to submit a passing layout test.
 This is where a question for the community arises:

 Presuming it is legal (I have my legal department looking at it),  I think
 it makes sense to bring in the tests verbatim from the IETestCenter site.  I
 do understand that there will likely be some overlap (thus, inefficiency) in
 coverage, but I think having a complete, identical set of tests will make it
 easier to verify WebKit’s performance in this test suite.  There is a
 precedent for this:  the IETestCenter javascript tests are already present
 in the LayoutTests tree.

 Assuming there are no legal barriers, importing the whole test suite
 would be valuable.  The LayoutTests contain a number of test suites
 developed externally (e.g., acid3, W3C conformance tests).  Some of
 these tests are redundant with other tests, but having the whole test
 suite as a unit is valuable itself.

 The alternative is to write new tests or enhance existing tests in the
 current LayoutTests tree.

 I’m open to either approach,  just need some direction from the team.

 That path is also fine.  I would encourage you to import all of the IE
 test center CSS tests (assuming it passes legal muster).

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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Qt Snow Leopard buildbot.

[Alexis Menard]

And we're back!

The graphic card burned, but I managed to get all data and I could put
them in an other machine to do the job.

On Tue, Feb 14, 2012 at 8:38 AM, Alexis Menard
alexis.men...@openbossa.org wrote:
 Hi all,

 Qt Snow Leopard build bot is experiencing some hardware issues. It
 seems like the MacBook Pro it was running on died, the machine doesn't
 even want to switch on. I'll try to bring it back to life today.

 Sorry for the inconvenience.

 Thanks.

 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Qt Snow Leopard buildbot.

[Alexis Menard]

Hi all,

Qt Snow Leopard build bot is experiencing some hardware issues. It
seems like the MacBook Pro it was running on died, the machine doesn't
even want to switch on. I'll try to bring it back to life today.

Sorry for the inconvenience.

Thanks.

-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] *.webkit.org is down

[Alexis Menard]

Hi,

It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …).

Here in Brazil we can't access to any of them. I tried two different internet 
providers with their own DNS and I even tried google DNS with no luck.

Talking to some people in #webkit it seems that not everyone is affected (maybe 
only people outside US?).

Anyone who knows where the servers sits would mind to have a look at them?

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

Re: [webkit-dev] *.webkit.org is down

[Alexis Menard]

On Jan 19, 2012, at 5:19 PM, Alexis Menard wrote:

 Hi,
 
 It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …).

I meant trac.webkit.org (Mac OS Lion auto-correction is too efficient).

 
 Here in Brazil we can't access to any of them. I tried two different internet 
 providers with their own DNS and I even tried google DNS with no luck.
 
 Talking to some people in #webkit it seems that not everyone is affected 
 (maybe only people outside US?).
 
 Anyone who knows where the servers sits would mind to have a look at them?
 
 Thank you very much.

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

Re: [webkit-dev] Patch in Qmake to split libQtWebkit.so

[Alexis Menard]

2012/1/13 Konstantin Tokarev annu...@yandex.ru:


 13.01.2012, 10:07, Subha subhara...@gmail.com:
 The libQtWebkit.so size is too large and is around 32MB for MIPS Platform. Is
 there a patch in qmake to split the  libQtWebkit.so?

 I also use QtWebKit on embedded platform. Some recommendations based on my
 personal experience:

 1) Build QtWebKit stand-alone with build-webkit script, and disable all 
 unneeded features.
 E.g. disabling SVG can save you a lot of space.

Maybe the --minimal of build-webkit is just enough for you?


 2) Add -fvisibility=hidden -fvisibility-inlines-hidden to build options 
 (i.e., revert commit
 5700b25 in git). This saves a lot of space too.

The conversation is more for webkit...@lists.webkit.org as it is Qt
specific. Let's move it there if someone have additional questions.


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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving WTF out of JavaScriptCore

[Alexis Menard]

On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote:
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673

 This will mean that WTF will be built as a separate static library on all 
 ports.

 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.

 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.

 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897

 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.

Hi Eric,

Is there a patch somewhere or you are still working on it? The bug
link contains nothing.

I would like to apply it here and test the Qt port so you'll get a bit
more confidence before landing it. I believe other ports are
interested too.

Thanks.


 Thanks!

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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving WTF out of JavaScriptCore

[Alexis Menard]

On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard
alexis.men...@openbossa.org wrote:
 On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote:
 We've been talking about moving WTF out of JavaScriptCore for a long
 time.  We believe we're nearly there.
 https://bugs.webkit.org/show_bug.cgi?id=75673

 This will mean that WTF will be built as a separate static library on all 
 ports.

 The plan is to do this move all in one piece, after work hours PST,
 when the tree is least active.

 It won't be the most beautiful transition (as we're likely to break at
 least one port in the process), but we'll try not to make too much of
 a mess.

 We believe all the ports are ready for the move, except AppleWin:
 https://bugs.webkit.org/show_bug.cgi?id=75897

 Once AppleWin is ready we'll schedule a date for the transition and
 announce it one this thread.

 Hi Eric,

 Is there a patch somewhere or you are still working on it? The bug
 link contains nothing.

 I would like to apply it here and test the Qt port so you'll get a bit
 more confidence before landing it. I believe other ports are
 interested too.

Nevermind wtf is already a static lib for Qt :D.

/me is going to hide himself for not opening wtf.pro for a while.


 Thanks.


 Thanks!

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



 --
 Alexis Menard (darktears)
 Software Engineer
 INdT Recife Brazil



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] use binary webkit

[Alexis Menard]

On Mon, Oct 24, 2011 at 1:57 AM, Adam Barth aba...@webkit.org wrote:
 On Sun, Oct 23, 2011 at 9:42 PM, Peter Kelly kelly...@gmail.com wrote:
 On 23/10/2011, at 10:58 PM, Eric Seidel wrote:
 This is the wrong list for this question.  webkit-help is a better
 choice for these topics.

 There is no free-to-distribute version of WebKit for windows to my
 knowledge.  Apple's windows version (the DLLs from the nightly)
 requires non-redistributable libraries from Apple.  Making it
 il-suited for use with 3rd-party applications.

 It seems there are a lot of people who wish to embed WebKit in their 
 applications, but this is not simple to do on any platform I'm aware of at 
 the moment (correct me if I'm wrong). Given the prominence of the project 
 and the number of potential use cases for it, It seems to me that it would 
 be nice to have something that anyone can easily distribute as part of their 
 app, as they can do with pretty much every other open source library out 
 there (think SQLite and libxml, which are used by many applications).

 I myself am developing an application which embeds WebKit and have found it 
 a huge amount of effort to integrate because of its current state. In my 
 case I am developing for Android, but need to use a custom build to include 
 some bug fixes which affect my application. This has involved porting the 
 Android fork of the Chromium fork of WebKit to build under the NDK, which is 
 not possible natively due to it's reliance on private APIs. Once I have it 
 working I plan to release the port publicly (both due to the LGPL 
 requirements and to help others who may wish to do the same thing). I also 
 may wish to port my application to windows in the future.

 The situation with respect to the Chromium Android flavor of WebKit
 should improve with time.  Folks are in the process of getting that
 working directly in WebKit trunk.  Once that's done, you should be
 able to build and run WebKit on Android with the NDK and no extra
 magic.

 While I understand that Apple and Google's priorities for WebKit lie in 
 their respective browsers and OS APIs, perhaps there might others in the 
 open source community and those working on various ports who would be 
 willing to participate in an effort to make an easily-redistributable 
 library of the nature that Atena was suggesting. I would certainly be 
 willing to contribute to such an effort.

 If I was to start a project to make this happen, and get enough interest 
 from others, would it be possible to do this as part of the mainline webkit 
 development tree?

 I believe both the Qt and GTK ports of WebKit have this as one of
 their goals (though neither supports Android, as far as I'm aware).
 If you're interested in contributing in that direction, you might want
 to chat with folks on #webkit-gtk to see what needs to be done.

I think the Qt port of WebKit should work pretty ok on Win7 but yes we
don't support Android.

#qtwebkit is also an alternative.


 Brent Fulgham also has a similar goal for the WinCairo port.  If
 you're interested in seeing this happen on Windows, you might want to
 chat with him.

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




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] QtWebKit 2.2 Build on Windows with Audio/Video Support

[Alexis Menard]

Hi,

On Fri, Oct 21, 2011 at 5:21 PM, Dev D dev.77...@gmail.com wrote:
 Hello Everyone,
 I am trying to build QtWebkit 2.2 on windows using MSVC. I didn't find a set
 of instructions for this particular scenario so, this is what i did
 1. downloaded/installed active perl
 2. downloaded/installed all the GNU tools
 3. downloaded/installed windows platform SDK 6.1
 4. downloaded/installed VC express 2008
 5. Set all the evn variables
 6. downloaded/installed Qt 4.7.4 libraries (MS based)
 7. ran Tools/Scripts/build-webkit --qt --release
 [the build was successful, but it doesnt have audio/video support] :(
 HTML5Test.com gave 0,0 for audio, video
 so i looked at the build-webkit switches and found --video (though by
 default video is enabled)
 so i did that
build-webkit --qt --release --video
 and now i run into this error
 MediaPlayer.cpp
 ..\..\..\Source\WebCore\platform\graphics\MediaPlayer.cpp(196) : error
 C2653: 'P
 latformMediaEngineClassName' : is not a class or namespace name
 ..\..\..\Source\WebCore\platform\graphics\MediaPlayer.cpp(196) : error
 C3861: 'r
 egisterMediaEngine': identifier not found
 NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
 9.0\VC\BIN
 \cl.EXE' : return code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio
 9.0\VC\BIN
 \nmake.exe' : return code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'cd' : return code '0x2'
 Stop.
 Building results into: C:/myprojects/newqtwebkit/QtWebKit-2.2.0/WebKitBuild
 Use of uninitialized value in print at
 C:/myprojects/newqtwebkit/QtWebKit-2.2.0/
 Tools/Scripts/webkitdirs.pm line 1229.
 WEBKITOUTPUTDIR is set to:
 WEBKITLIBRARIESDIR is set to:
 C:\myprojects\newqtwebkit\QtWebKit-2.2.0\WebKitLib
 raries\win
 'Tools\Scripts\print-vse-failure-logs' is not recognized as an internal or
 exter
 nal command,
 operable program or batch file.
 I had something similar when i build this on Linux, i looked at the scripts
 and found that
 under Linux
 if no gstreamer - no video support // i like it
 but how do i resolve this in windows - i am kind of new to building webkit
 on windows


This is the wrong list we have a dedicated webkit-qt mailing list.

Short answer : you need qtmultimedia, therefore QtMobility.

 thanks in advance
 Dev D



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] New Qt build bot for Mac OS SnowLeopard.

[Alexis Menard]

Hi,

I'm very happy to announce a new Qt WebKit build only bot for the Qt port on 
Mac OS SnowLeopard. I hope it will be useful to the community to catch 
problems. QtWebKit team never had such a bot in the past. I'll be maintaining 
it so if you have any question please contact me.

http://build.webkit.org/builders/Qt%20SnowLeopard%20Release

Thanks to the ones who helped.

Alexis Menard

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

[webkit-dev] Heads up : Qt port and its multimedia support.

[Alexis Menard]

Hello,

Just a small heads up on the multimedia support for the Qt port. At
the last webkit summit I've heard some Google folks a bit confused
about our multimedia story and I'm sure others are so here is the
story :

We had a first Phonon backend, abandoned and really far from feature
completion and far from working well : I removed it with
http://trac.webkit.org/changeset/89832 as we thought it was not good
idea to let it broken on the trunk.

Then we have a QtMultimedia media player (Qt Multimedia is a separate
add-on for Qt) that was added to the tree last year to provide a more
extensive API than Phonon and supporting more platforms (Symbian).
Unfortunately Qt Multimedia lacks of stability, the quality of the
backends is really heterogenous and they behaves differently. I felt
the support was built on unstable foundations so I decided it was not
good option either.

As a fun project, QtWebKit people decided to give a try on how the Qt
port could use the GStreamer backend of webkit maintained by our GTK
friends. Main changesets related :
http://trac.webkit.org/changeset/72184,
http://trac.webkit.org/changeset/83078.

I also did the same on Mac, and it is possible for the Qt port to the
QtKit media player maintained by Apple. Main changesets
http://trac.webkit.org/changeset/87312 and
http://trac.webkit.org/changeset/89617.

Both implementation work pretty well with Qt, supports more features
than we had with QtMultimedia, have better results in LayoutTests and
make us work closer to the other webkit devs - only benefits :D
therefore after http://trac.webkit.org/changeset/91752 the GStreamer
media player is the default on Linux and QtKit the default media
player on Mac for the Qt port. On Windows and Symbian we still use
QtMultimedia media player for now.

Our Linux implementation is already covered by a bot so now the fellow
GStreamer media player contributors should watch the Qt bots when they
work on the media player. Unfortunately for our Apple friends we don't
have yet a Qt Mac bot, though we are working on making one ready for
build.webkit.org (we do have one running but not yet at the level to
be promoted to build.webkit.org) so I will watch carefully the stuff
going on the QtKit media player.

Anyway if you have any question on the multimedia support in Qt and if
you are unsure about a change that could affect QtWebKit in either
GStreamer and QtKit, CC me on a bug or reach me on IRC.

Thanks to Eric Carlson, Philippe Normand and others who helped me to
make all of this working.

Any questions?

-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Fixing the Platform fields in Bugzilla

[Alexis Menard]

On Tue, Jul 5, 2011 at 12:41 PM, Simon Fraser simon.fra...@apple.com wrote:
 The platform fields in Bugzilla are pretty much useless now. There's a 
 rep_platform popup (replicated platform?) containing:

 Unspecified
 All
 Macintosh PowerPC
 Macintosh Intel
 PC
 S60 Hardware
 S60 Emulator
 Android
 Other

  and an op_sys popup, both containing:

 Unspecified
 All
 Windows 2000
 Windows XP
 Windows Server 2003
 Windows Vista
 Windows 7
 Mac OS X 10.3
 Mac OS X 10.4
 Mac OS X 10.5
 Mac OS X 10.6
 Linux
 S60 3rd Edition
 Android
 Other

 These don't represent the suite of hardware and OSes that WebKit is used on 
 these days, nor do they represent the various ports. For example, there's no 
 way to indicate that a bug is in the QT port.

Though the component field let you choose WebKit Qt. That's how we
catch our bugs :D and the keywords, Qt, QtTriaged.


 Can we clean this up?

 Simon

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




-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Setting up Eclipse IDE for Webkit..

[Alexis Menard]

Hi,

Which port you want to build?

For Qt :

QtCreator for the Qt port works pretty well, just open the WebCore.pro
or QtWebKit.pro with it.

Though I've never tried Eclipse on the Qt port.

On Wed, Jun 22, 2011 at 10:19 AM, Tom Smith penguin.lin...@gmail.com wrote:
 Hi everyone,
   Has anyone used Eclipse IDE on Ubuntu?  If so do you have
 any recommendations?
 Thanks.
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev





-- 
Alexis Menard
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] API documentation in cpp files

[Alexis Menard]

On Jun 22, 2011, at 11:29 AM, Grzesiek Czajkowski wrote:

 Hi,

Hi,

 
 I am wondering why webkit has the most documentation in cpp files. In header 
 files only classes, structures are documented. Is there any reason to do it 
 in that way?
 
 If we will have all documentation in header files client programmer will take 
 devel package of webkit and he may generate a documentation by doxygen 
 command. He doesn't need the sources of WebKit.

In Qt we do the same because when a developer hack on the cpp files, the doc is 
right in front of his eyes, which means that there is more chance he will fix 
the doc and not forget about it. I also remember that it was done back in time 
so that when you just update the doc of an important file (included everywhere) 
you will not end up rebuilding *everything* because you changed the h file, 
i.e. you will only recompile the cpp file.

 
 Regards
 Grzegorz
 
 grzes.czajkow...@gmail.com
 ___
 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] Adding ENABLE_BATTERY_STATUS to WebCore

[Alexis Menard]

On Wed, Jun 15, 2011 at 2:02 PM, Andrei Popescu andr...@google.com wrote:
 On Wed, Jun 15, 2011 at 5:58 PM, Brett Wilson bre...@chromium.org wrote:
 On Wed, Jun 15, 2011 at 9:30 AM, Holger Freyther ze...@selfish.org wrote:
 On 06/15/2011 06:11 PM, laszlo.1.gom...@nokia.com wrote:
 Hi,



 The use-case for us is to enable content developers to implement 
 rudimentary power management (e.g. to stop expensive operations on the 
 page, perhaps save state). I'm not sure if this API is really meant for 
 accurately reporting all the possible power management states of the 
 system as Anssi pointed out.

 Okay, point on complexity taken. My question is what if you want to add
 complexity, is there something in the event that prevents that (I have no 
 idea
 about DOM compatibility issues)? Don't get me wrong I think having more 
 device
 support is great.

 My other complain was, it is too simple. E.g. 'isPlugged' has no guarantee
 that the battery is getting charged. Is this a problem?

 Why would a web page care about whether the battery is being charged
 when the device is plugged in?


 Because it would know not to start doing things that drain the
 battery. For instance, powering up a 3G antenna to download your
 latest emails could be annoying to users if the battery level is too
 low. 3G takes quite a bit of power and the device would be in danger
 of powering down.

But if the phone is plugged in it can't power down. Most of modern
phones don't switch off anymore even if you have the battery low and
you play games, surf WiFi, go 3G as soon as you plugged it in. What
Brett meant is that it's useless to know that the battery is charging
while the phone is plugged in, you just want to know that it will not
switch off in any case so you can do whatever you want.


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




-- 
Alexis Menard
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Building WebKit with Intel Compiler icc

[Alexis Menard]

2 months ago or something I managed to build trunk with ICC without
any issue. You just have to disable JIT.

On Sat, Jun 11, 2011 at 5:33 PM, Konstantin Tokarev annu...@yandex.ru wrote:


 11.06.2011, 21:36, cb07...@qmul.ac.uk:
 Do you have any pointers? Are there some flags or specific ways to specify 
 which compiler to use for the whole build system (the build scripts) or 
 should I be trying to use Intel Compiler to build each part separately?

 Any help will be greatly appreciated!


 IIRC I just used proper icc mkspec (see -platform option of configure and 
 mkspecs/ directory in Qt sources)

 Also (FYI), configure respects CC and CXX variables


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




-- 
Alexis Menard
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New Feature Flag Proposal: INPUT_COLOR

[Alexis Menard]

On Mon, May 23, 2011 at 9:57 PM, Keishi Hattori kei...@webkit.org wrote:
 Hi webkit-dev,

 I just wanted to notify everyone that I will be adding a new feature
 flag, INPUT_COLOR. http://webkit.org/b/61273

 This flag will enable input type=color

 I need this flag because the color picker UI needs to be implemented
 individually for each platform, and it is going to take some time.

If you need any help on the Qt side feel free to ping me (darktears).


 Also the current text field implementation will be disabled. This is
 to avoid feature detection so that web pages can fall back to JS color
 pickers.

 Thanks!

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




-- 
Alexis Menard
Software Engineer
INdT Recife Brazil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev