Re: [webkit-dev] compact ICU unicode

[Martin Robinson]

On Fri, Jun 14, 2013 at 4:34 PM, Laszlo Gombos  wrote:
> Qt port of WebKit trunk can only be built with Qt v5, which has a hard
> dependency on ICU. Older version of Qt and WebKit (v4.8) had an option to
> build with or without ICU. See [1] an [2] for more background information.

Given that Qt now has a hard dependency on ICU, does the Qt port still
plan to support the Qt Unicode backend or are there plans to
transition to using the ICU backend? Just curious. :)

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

Re: [webkit-dev] compact ICU unicode

[Laszlo Gombos]

Hi Mark,

>> I think some Qt port's platform doesn't use ICU either so you might want
to coordinate with their maintainer to do this.  In fact, WTF had an
abstraction layer around ICU to do this the last time I checked.

Qt port of WebKit trunk can only be built with Qt v5, which has a hard
dependency on ICU. Older version of Qt and WebKit (v4.8) had an option to
build with or without ICU. See [1] an [2] for more background information.

[1] https://lists.webkit.org/pipermail/webkit-qt/2011-November/002165.html
[2] https://bugs.webkit.org/show_bug.cgi?id=76821

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

Re: [webkit-dev] Web Inspector

[Timothy Hatcher]

Sorry for the duplicate message.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Web Inspector

[Timothy Hatcher]

On Tuesday the Safari team upstreamed the Safari Web Inspector to WebKit as a 
new top-level project — WebInspectorUI. This version of Web Inspector is nearly 
two years in the making. We now feel it is time to share our hard work with the 
WebKit project and further accelerate developer tool innovation with help from 
all of you.

The previous Web Inspector UI is still part of WebCore and is used by a number 
of ports currently. However, the previous version of Web Inspector is largely 
unmaintained at this point — since the departure of Chromium back in April. At 
this time, we would like to deprecate the previous Web Inspector and encourage 
ports to move over to using the new WebInspectorUI project.

We realize a transition like this can't happen overnight. For starters, the 
current UI assumes the Mac platform with keyboard shortcuts and other 
conventions. Another area would be making it work with the Inspector protocol 
vended over a WebSocket. To facilitate a smooth transition for ports, we are 
ready to help and review patches to get issues resolved as quickly as possible.

We hope you are as excited about this as we are, and are looking forward to 
working with all of you to make Web Inspector even better!

— Timothy Hatcher

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

Re: [webkit-dev] compact ICU unicode

[Ryosuke Niwa]

On Fri, Jun 7, 2013 at 12:15 PM, Salisbury, Mark wrote:
>
> What would people think about including specific ICU data tables in WTF in
> order to provide a lightweight (but functional) unicode implementation?
>

I don't think we want to do that. Maintaining such a table will be a
nightmare for us.

On embedded systems the size of ICU is prohibitive.  Determining the right
> way to package it to make it small enough isn't simple either.
>

It seems like this is a problem with ICU.  I think some Qt port's platform
doesn't use ICU either so you might want to coordinate with their
maintainer to do this.  In fact, WTF had an abstraction layer around ICU to
do this the last time I checked.

WinCE Unicode originally came in here:
> https://bugs.webkit.org/show_bug.cgi?id=27305.  The reason it was
> introduced was to save space (filesystem and RAM).  ICU, if not packaged
> very carefully (http://userguide.icu-project.org/packaging), is actually
> larger than webkit itself.  On embedded systems, this is a big deal.  The
> original plan with the bug above was to include specific ICU data tables in
> webkit.
>
> I've been compiling WTF with Unicode tables embedded for some time now.  I
> don't believe I've seen many layout test regressions due to using a
> simplified ICU implementation.
>

Have you thoroughly tested your browser in CJK, Hebrew, Arabic, and Thai?
 I don't think we can rely on layout tests to catch all ICU dependencies.

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

Re: [webkit-dev] compact ICU unicode

[Salisbury, Mark]

Thanks Glenn for the feedback.  I rather like how Torch Mobile slimmed it down 
back in '09 for porting to WinCE, but if the primary concern is architectural 
purity / long term maintainability -- that argument makes sense and I can see 
why we don't want to muddy WTF with it.

At the same time, ICU IS huge and contains way more functionality than WebKit 
uses ... perhaps it can be slimmed down sufficiently following standard 
procedures (http://userguide.icu-project.org/packaging) and have it still work. 
 If anyone has had success doing this for WebKit and wouldn't mind sharing what 
they did to tune it down, I'd appreciate hearing about it.  The way it's built 
for windows (and shipped with WebKitLibraries.zip) it is rather large - larger 
than WebKit.dll.

Thomas is right about WebKit growing substantially - but I notice recently it 
has shrunk a few MB.  (I presume due to pulling out huge features like memory 
inspector / shadow DOM that are not unmaintained...)

Mark

-Original Message-
From: Thomas Fletcher [mailto:tho...@cranksoftware.com] 
Sent: Thursday, June 13, 2013 7:38 PM
To: Glenn Adams
Cc: Salisbury, Mark; WebKit Development (webkit-dev@lists.webkit.org)
Subject: Re: [webkit-dev] compact ICU unicode

What if we created a new project, based off of ICU called lilICU .. 
would the WebKit community then accept an alternative binding to this new 
library?

Not to split hairs, but that is essentially what it seems that we would have to 
do, create a new library, before the WebKit community becomes interested in 
ways of trimming down WebKit for embedded devices where the resource 
impositions of dependent libraries are significant.

Having worked at porting WebKit to a variety of embedded platforms over the 
last five years (most of the work non-recontributable due to lack of interest 
in esoteric and non-mainstream platforms) the size of a typical WebKit build 
has grown significantly while the number of tuning options has decreased.

Thanks,
  Thomas

Glenn Adams wrote:
>
>
>
> On Sat, Jun 8, 2013 at 3:15 AM, Salisbury, Mark  > wrote:
>
> Hello,
>
> What would people think about including specific ICU data tables in
> WTF in order to provide a lightweight (but functional) unicode
> implementation?
>
>
> FWIW, I'd suggest you port ICU to your platform or if the size is too 
> large, port the portion of it that WK uses, and then use that portion.
> However, I think the ICU library or even a subset should NOT be added 
> to WTF.
>
>
> On embedded systems the size of ICU is prohibitive.  Determining the
> right way to package it to make it small enough isn't simple either.
>
> A patch was reviewed once that attempted to add ICU data tables
> directly in WTF and there were two concerns:
> 1) Checking in generated files
> (https://bugs.webkit.org/show_bug.cgi?id=27305#c8)
> 2) Questions concerning if the ICU license is compatible with
> WebCore (https://bugs.webkit.org/show_bug.cgi?id=27305#c9)
>
> I believe the patch could be done differently as to not check in
> generated files.  Regarding the second concern, ICU has a very
> permissive license
> (http://www.icu-project.org/repos/icu/icu/trunk/license.html).
>   There are three requirements, basically that the copyright and
> permission notice has to appear with copies of the software.  I
> believe that is already a requirement for distributions of webkit
> that use ICU.  Except for WChar unicode, I believe all webkit builds
> now use ICU Unicode.
>
> This Unicode path could replace WCHAR_UNICODE or be introduced as a
> third option, call it what you like - BASIC_ICU_UNICODE,
> ICU_LITE_UNICODE, COMPACT_ICU_UNICODE, etc..  I think it might be
> valuable for other ports that are size conscious - the up and coming
> NIX port comes to mind.
>
> Thanks,
> Mark
>
> Background:
> After rebasing my WinCE port of webkit, I ran into an ASSERT in
> WebCore/platform/text/wchar/TextBreakIteratorWchar.cpp,
> acquireLineBreakIterator().  I thought I'd be able to easily fix
> this, since I had already modified how LineBreakIterator works to
> take prior context into account (on my own branch) and find line
> break in a stream of non-ASCII characters.
>
> However, the WCHAR Unicode implementation is very bare bones and
> does not even support returning the Unicode character category
> 
> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/unicode/wchar/UnicodeWchar.cpp#L35).
>   WCHAR Unicode was originally called WinCE Unicode, then it was
> properly renamed as it had nothing to do with WinCE.
>
> WinCE Unicode originally came in here:
> https://bugs.webkit.org/show_bug.cgi?id=27305.  The reason it was
> introduced was to save space (filesystem and RAM).  ICU, if not
> packaged very carefully
> (http://userguide.icu-project.org/packaging), is actua