Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013

[Hugo Lima]

On Fri, Dec 13, 2013 at 5:52 PM, Anders Carlsson  wrote:
>
> I’m about to land a patch that will require variadic templates, and I plan to 
> do the same thing for range-based for loops. These are both supported by GCC 
> 4.6.
>
> Going forward I’d really like us to start using template aliases, which is a 
> 4.7 feature. If that’s a problem we can hold off that for the time being.

If such features will be mandatory why not also avoid OVERRIDE, FINAL,
etc macros and use the C++ the real keywords directly since all
compilers supporting variadic templates also support those keywords?

- Hugo

> - Anders
>
> ___
> 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] Code cleaning: LEGACY_VIEWPORT_ADAPTION

[Hugo Lima]

On Tue, Oct 29, 2013 at 9:00 PM, Benjamin Poulain  wrote:
> Hi WebKit,

Hi,

> I plan to remove the code guarded by LEGACY_VIEWPORT_ADAPTION and the flag
> itself.

I was reading the original bug report[1] to find a list of websites
targeting mobile devices that don't render well if this feature is
disabled, the original list includes:

m.yahoo.com
m.google.com
m.facebook.com

All this if you do not use some apple-like user agent, I did test them
again today to check the current status and just m.google.com is still
using those legacy DTD causing WebKit to render the page into a 980px
canvas where it was designed to be rendered into a 320px canvas. There
may be other (old) sites not rendering well but at least at the time
of the bug report this small list with very popular websites was
enough to add this feature to a product (N9 phone) then to WebCore.

I also found that besides Blackberry, Chromium turned on this flag[2]
last year, but I didn't check if it still enabled on blink.

Support legacy stuff is a pain and just inject undesirable code in the
codebase, but I would like to know if there are other options rather
than just removing the feature and let few, but some important,
website not working?

[1] https://bugs.webkit.org/show_bug.cgi?id=85425
[2] https://bugs.webkit.org/show_bug.cgi?id=90991

Regards,
Hugo

> The reason is: this code is mostly incorrect and leads to valid viewport
> configurations only with the most trival cases.
>
> It seems to be only enabled by Nix and Blackberry but I can't tell if it is
> intentional.
>
> Benjamin
> ___
> 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] Is OwnPtr deprecated in favor of std::unique_ptr?

[Hugo Lima]

On Fri, Oct 25, 2013 at 9:38 PM, Darin Adler  wrote:
> On Oct 25, 2013, at 2:23 PM, Hugo Lima  wrote:
>
>> I would like to know what's the current recommendation regarding 
>> std::unique_ptr use: never use; use on X and Y situations or just slowly 
>> replace OwnPtr by unique_ptr.
>
> We are replacing PassOwnPtr and OwnPtr with std::unique_ptr. This is part of 
> a general trend where we are adopting some C++11 language and library 
> features.
>
> It doesn’t have to be slow, but it should be done carefully and we don’t want 
> to rush it or get in the way of more valuable changes.

All clear, thanks very much.

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

[webkit-dev] Is OwnPtr deprecated in favor of std::unique_ptr?

[Hugo Lima]

Hi,

There are some code using std::unique_ptr and some using
OwnPtr/PassOwnPtr all over WebKit, a grep based search shows:

OwnPtr: 4130
PassOwnPtr: 1660
unique_ptr: 587

I would like to know what's the current recommendation regarding
std::unique_ptr use: never use; use on X and Y situations or just
slowly replace OwnPtr by unique_ptr.

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

Re: [webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Fri, Sep 13, 2013 at 4:31 PM, Antonio Gomes  wrote:
> So will you advocate your users to use your external GitHub version or
> the one in
> WebKit?
>
> Please consider not being half upstream.

It wont be half upstream, but the github repository will be for
example a fallback for a working bleeding edge Nix just in case of
WebCore changes that break Nix on webkit.org. We can also push things
first there then on webkit.org if a faster development pace if needed,
as all Nix developers use git this also means that experimental
feature branches will exists on github repo too (don't tell me about
create svn branches).

The worst scenario is if a WK2 change doesn't get accepted at all, but
I don't think gonna happen if the change isn't wrong.

In other words, no, it's not our intent to do half upstream like IIRC
happened with Blackberry port.

> On Fri, Sep 13, 2013 at 2:37 PM, Hugo Lima  wrote:
>> On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>>>
>>> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>>>
>>>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
>>>>> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
>>>>> remember correctly, that layer had to be modified constantly as
>>>>> WebCore/WebKit code was refactored so I'm a bit worried about this.
>>>>
>>>> Yes, in fact we got some API from them.
>>>
>>> This is my biggest concern with the Nix port; that it will end up exposing 
>>> implementation details of our platform layer, making it harder for us to 
>>> perform sweeping changes to said layer (for example, like what Darin is 
>>> doing with his pasteboard cleanup patches).
>>>
>>> In fact, it reminds me of the WebKit2 situation (before we instituted the 
>>> build policy) where some changes that should in theory take days would end 
>>> up taking weeks because of:
>>>
>>> - Churn waiting for the EWS bots to do their thing.
>>> - Churn due to patches being rolled out for breaking other ports (due to 
>>> certain build flags being enabled in said ports).
>>> - Churn due to patches being rolled out for breaking other ports (due to 
>>> misconceptions about the correct WebKit2 semantics in said ports).
>>>
>>> Maybe we would need a similar build policy for WebCore?
>>>
>>>>> But it sounds like you're suggesting that Nix port's maintainers will be
>>>>> responsible for making any code changes necessary to support
>>>>> WebCore/WebKit/WebKit2 refactoring?
>>>>
>>>> Yes, this is the idea, is our concern to keep our code working.
>>>
>>> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
>>> port without having patches rolled out by members of the Nix team?
>>
>> This already happen nowadays, so it would not change too much our
>> development. Even after nix upstream process we will probably keep a
>> copy on github with few additional patches that may not fit on e.g.
>> WebKit2 or need to be landed a bit faster on our tree due to some
>> customer needs.
>>
>> I didn't talk with other team members about it, but IMO it's not a big
>> deal to break it on these kind of WebCore changes that affect all
>> ports, I'm saying this because the chance of having these patches
>> breaking other ports as well is considerable too, besides if the
>> change get announced on this ML before get landed we'll have enough
>> time to adapt to it.
>>
>>> - Anders
>>>
>> ___
>> 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] Announcing new port: Nix

[Hugo Lima]

On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>
> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>
>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
>>> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
>>> remember correctly, that layer had to be modified constantly as
>>> WebCore/WebKit code was refactored so I'm a bit worried about this.
>>
>> Yes, in fact we got some API from them.
>
> This is my biggest concern with the Nix port; that it will end up exposing 
> implementation details of our platform layer, making it harder for us to 
> perform sweeping changes to said layer (for example, like what Darin is doing 
> with his pasteboard cleanup patches).
>
> In fact, it reminds me of the WebKit2 situation (before we instituted the 
> build policy) where some changes that should in theory take days would end up 
> taking weeks because of:
>
> - Churn waiting for the EWS bots to do their thing.
> - Churn due to patches being rolled out for breaking other ports (due to 
> certain build flags being enabled in said ports).
> - Churn due to patches being rolled out for breaking other ports (due to 
> misconceptions about the correct WebKit2 semantics in said ports).
>
> Maybe we would need a similar build policy for WebCore?
>
>>> But it sounds like you're suggesting that Nix port's maintainers will be
>>> responsible for making any code changes necessary to support
>>> WebCore/WebKit/WebKit2 refactoring?
>>
>> Yes, this is the idea, is our concern to keep our code working.
>
> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
> port without having patches rolled out by members of the Nix team?

This already happen nowadays, so it would not change too much our
development. Even after nix upstream process we will probably keep a
copy on github with few additional patches that may not fit on e.g.
WebKit2 or need to be landed a bit faster on our tree due to some
customer needs.

I didn't talk with other team members about it, but IMO it's not a big
deal to break it on these kind of WebCore changes that affect all
ports, I'm saying this because the chance of having these patches
breaking other ports as well is considerable too, besides if the
change get announced on this ML before get landed we'll have enough
time to adapt to it.

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

Re: [webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Thu, Sep 12, 2013 at 5:29 PM, Geoffrey Garen  wrote:
>> Sure. We at University of Szeged who work on WebKitNix from this year
>> contributed many fixes to various part of WebKit: JavaScriptCore,
>> WebCore, Tools, …
>
> Thank you for this list. I started reading through it, but I noticed a high 
> percentage of patches that were port-specific build fixes or port-specific 
> features like support for legacy ARM chips. For example, “...on ARM 
> traditional” (). Those patches are 
> cost to core WebKit development, not benefit.

The way you said sounds like if Apple stop shipping ARM based devices
all ARM related patches on WebKit are of no benefit to the project.

> Can you clarify this list by editing out patches like that?
>
> Thanks,
> Geoff
> ___
> 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] Announcing new port: Nix

[Hugo Lima]

On Thu, Sep 12, 2013 at 2:54 PM, Darin Adler  wrote:
> On Sep 12, 2013, at 10:36 AM, Hugo Lima  wrote:
>
>> the Nix implementation will just delegate the implementation to the 
>> application
>
> I think what this means is that Nix will export interfaces that closely match 
> WebKit internals as the Nix API to WebKit.
>
> This may well create a long term problem for the WebKit project. Changes that 
> would be fine for other platforms, internal restructuring, could be a problem 
> for the Nix platform. Generally speaking, this is what the platform layers in 
> the WebKit directory provide; a port that omits this level of abstraction and 
> indirection could pose some serious challenges to us as we make major changes 
> to WebKit internals while preserving external API compatibility.
>
> I’m not saying this is an immediate show-stopper, but it’s a critical topic 
> to discuss.

This is the challenge, the Nix::Platform API need to focus on the
primitives of the problem and not just being just a thin wrapper tied
to the WebCore implementation, if the internals of WebCore change we
just need to solve the problem on the glue code between WebCore and
our API without need to change either, our API or the WebCore change.

This is a issue that could happen in the future for sure, but I don't
think it will be a show-stopper for any WebCore refactor, it will just
add a bit of work to the Nix port layer the same way it will add to
other ports, maybe a bit more for us due to the "low level" nature of
our API, but not much if we do our job right.

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

Re: [webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
> remember correctly, that layer had to be modified constantly as
> WebCore/WebKit code was refactored so I'm a bit worried about this.

Yes, in fact we got some API from them.

> But it sounds like you're suggesting that Nix port's maintainers will be
> responsible for making any code changes necessary to support
> WebCore/WebKit/WebKit2 refactoring?

Yes, this is the idea, is our concern to keep our code working.

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

Re: [webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Thu, Sep 12, 2013 at 1:46 PM, Darin Adler  wrote:
> In my work on clipboard and pasteboard recently, I started with the Mac port. 
> The Qt and GTK ports have been easy to work with. Contributors to those ports 
> have helped me get the details right, and the code for those ports is 
> relatively self explanatory. The Windows port has been pretty easy, too. The 
> most difficult port for me has been EFL, since there is code peppered with 
> “notImplemented()” and so not testable. See, for example, PasteboardEfl.cpp. 
> This has made me uncertain about what to do for EFL and has made that port 
> one of the most difficult to deal with.
>
> What is the NIX port approach for pasteboard?

Pasteboard still on the roadmap (so it still not implemented yet), as
pasteboard depends on the underlying platform the Nix implementation
will just delegate the implementation to the application, so the work
will be just to define an API to put on Source/Platform/nix/public and
use them, besides write some mock for WTR, API tests and backends on
some of our examples to prove and test the API usage.

The easiest way to imagine what it would be is to take
PasteboardQt.cpp, take away all uses of QClipboard and replace by some
Nix::Platform API calls, so an application using Nix can implement the
Pasteboard related stuff on Nix::Platform API and use QClipboard,
GtkClipboard, or whatever it wants in the implementation.

The "move all specific platform stuff implementation out of Nix shared
library" makes the creation of simple apps hard because you get almost
nothing out of box from Nix, but for this you already have other ports
like Qt, GTK or EFL, however the idea is to have these backends
implementation easy to just "copy and paste" from our examples to any
project if the technology used fits, otherwise the Nix user need to
write their own backend, but without worry about the whole WebKit
tree. The work on this isn't done yet, but we have a goal and are
walking towards it.

> -- Darin
> ___
> 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] Announcing new port: Nix

[Hugo Lima]

Hi

On Tue, Sep 10, 2013 at 6:48 PM, Geoffrey Garen  wrote:
> What value do you think this port will bring to WebKit? For example:
>
> Does your code fix bugs or improve performance in WebCore or 
> JavaScriptCore?

As any other WebKit port WebCore bugs are fixed when we found it and
need a fix, our current performance focus is on CoordinatedGraphics
and there are another team working on get the canvas faster.

> Does the simplification you mentioned allow us to remove existing 
> port-related code?

Not really, it's possible to unite the glib users in many parts, but
to remove existing port-related code depend on the existing port
owners.

> You mentioned that EFL, GTK, and/or Qt could switch to this port. Do 
> they have any plans to do so?

No, we can't decide what other ports do, would be nice to have a
convergence to glib on GTK, EFL and Nix ports, but this doesn't depend
on us. In fact a port can be built on top of Nix, but I doubt any
existing port will do this right now.

> Do you have a specific plan to ship a NIX-based browser to a large 
> number of customers?

Nix can be used to make a browser, in fact due to their nature of let
some decisions to the application instead of inject pre-defined
behavior on the port itself it can be a better choice if the default
behavior of other ports aren't desired. However the project target is
to have an easy way to use WebKit on whatever product (TV, setup box,
browser, etc) without (or drastically reducing) the need to fork
WebKit just to change those little details involved on the adaptation
of WebKit to whatever platform or software. Another advantage is the
lack of toolkit, so if you want to use WebKit on your brand new and
bizarre platform you only need to port WebKit avoiding the pain of
porting large toolkits with their different build systems like Qt, EFL
or GTK, i.e. Nix have a different target.

> Geoff
>
> On May 17, 2013, at 5:41 AM, Luciano Wolf  wrote:
>
>> The openBossa team at INdT Brazil is proud to announce “Nix” - a new
>> WebKit2 port based on POSIX and OpenGL. Nix stands for “WebKit for
>> unix-like platforms” and, if you consider the German meaning of the
>> word "nix", it can be taken as “WebKit plus nothing”. We are looking
>> forward to upstreaming and maintaining this port. Below you will find
>> a brief history about Nix, besides its main goals and motivation.
>>
>>
>> :: A little bit of history ::
>>
>> The first of Nix basic ideas arose from a conversation between Kenneth
>> Rohde Christiansen and Noam Rosenthal, who were wondering about the
>> idea of having a “platform/glib” or platform/posix”.  Other ports such
>> as EFL, GTK and Qt would then be able to develop themselves on top of
>> it, having a common source core.
>>
>> While QtWebKit’s QQuickWebView is great for embedding web content into
>> QtQuick, a few people felt they needed more freedom to implement a
>> different WebView behavior than the one being provided by Qt. Behavior
>> more suitable for tricky use cases like embedding web content in a 3D
>> world, for example. A private API called QRawWebView was implemented
>> to fulfil this gap.
>>
>> Motivated by the 2 aforementioned concepts and by the idea of having a
>> “lightweight” GL based port for developing some prototypes on a
>> RaspberryPi, in August 2012 Caio Oliveira and Jesus Sanchez-Palencia,
>> long term WebKit developers and former INdT employees, kick-started
>> what they called WebKitNix. They started from the EFL port, took out
>> every EFL-specific piece of code, implemented a “raw” GL-based
>> WebView, provided a C API in the WK2 fashion and a set of
>> platform/device APIs based on the former Chromium’s Source/Platform.
>>
>> We can summarize its evolutionary process as:
>>
>> 1. Initial idea: platform/posix or platform/glib (share code);
>> 2. Evolved problem: we wanted to have different behaviors for
>> QQuickWebView -> Qt Raw WebView
>> 3. Network: QtWebKit + Soup experiment
>> 4. Efl Raw WebView experiment
>> 5. Efl Without Efl :)
>> 6. Nix was born.
>>
>> :: What is inside it? ::
>>
>> Most of Nix’s building pieces are shared with other existing ports:
>> CMake build system, GLib, libsoup and Cairo. Also, it uses Coordinated
>> Graphics, Tiled Backing Store and existing WebKit2 C APIs. Having such
>> a tiny WebKit API means that Nix has the smallest possible footprint
>> on the rest of the WebKit project.
>>
>> We take seriously the notion that the WebKit project is for a web
>> rendering engine and nothing else, and try to develop as much of the
>> auxiliary features as possible outside the WebKit project, on top of
>> the API or in the injected bundle.
>>
>> Nix is already covered by Layout Tests, API Tests (TestWebKitAPI) and
>> Ref Tests which are run by our buildbot[1]. Perf tests are supported
>> but we don’t have a buildbot ready for them at this time. Pixel Tests
>> are on the way. Today we have around 75% of layout tests coverage.
>>
>> We have been mergi