Re: [webkit-dev] MathML renderer

[Maciej Stachowiak]

On Jan 4, 2011, at 7:09 PM, Alex Milowski wrote:

> On Tue, Jan 4, 2011 at 1:50 PM, Maciej Stachowiak  wrote:
>> 
>> On Jan 4, 2011, at 11:03 AM, Dirk Schulze wrote:
>> 
>>> Hi webkit-dev,
>>> 
>>> I was looking at the MathML code recently and I wonder, that all files are 
>>> located at WebCore/mathml, even the renderer. Shouldn't the rendering code 
>>> be moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?
>> 
>> Yes, the rendering code would be better placed in the rendering/ directory.
> 
> Well, not to buck the trend, but ...
> 
> I actually prefer having it all under the 'mathml' directory so that
> is what I did.  No one has complained before.
> 
> If there is a strong preference to move the RenderMathML* files to
> WebCore/rendering/, I'm not against it.

In general, the approach we've taken is to put all rendering code in WebCore, 
and the DOM aspect of each markup language in its own directory. I can see how 
there could be benefits to keeping it all together, but I think it's more 
important to stay consistent with the rest of the project.

It might make sense to use subdirectories of rendering/, as svg has started to 
(although this seems incomplete - SVG folks, is the plan to move the remaining 
SVG-related rendering files from rendering/ to rendering/svg?).

Regards,
Maciej

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

Re: [webkit-dev] libxml2 "override encoding" support

[Alex Milowski]

On Tue, Jan 4, 2011 at 7:05 PM, Alexey Proskuryakov  wrote:
>
> 04.01.2011, в 18:40, Alex Milowski написал(а):
>
>> Looking at the libxml2 API, I've been baffled myself about how to
>> control the character encoding from the outside.  This looks like a
>> serious lack of an essential feature.  Anyone know about this above
>> "hack" and can provide more detail?
>
>
> Here is some history: 
> , 
> .

Well, that is some interesting history.  *sigh*

I take it the "work around" is that data is read and decoded into an
internal string which is represented by a sequence of UChar.  As such,
we treat it as UTF16 character encoded data and feed that to the
parser, forcing it to use UTF16 every time.

Too bad we can't just tell it the proper encoding--possibly the one
from the transport--and let it do the decoding on the raw data.  Of
course, that doesn't guarantee a better result.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] libxml2 "override encoding" support

[Eric Seidel]

You should feel encouraged to speak with dv (http://veillard.com/)
more about this issue.

Certainly I'd love to get rid of the hack, but I gave up after that
email exchange.

-eric

On Tue, Jan 4, 2011 at 7:05 PM, Alexey Proskuryakov  wrote:
>
> 04.01.2011, в 18:40, Alex Milowski написал(а):
>
>> Looking at the libxml2 API, I've been baffled myself about how to
>> control the character encoding from the outside.  This looks like a
>> serious lack of an essential feature.  Anyone know about this above
>> "hack" and can provide more detail?
>
>
> Here is some history: 
> , 
> .
>
> - WBR, Alexey Proskuryakov
>
> ___
> 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] MathML renderer

[Alex Milowski]

On Tue, Jan 4, 2011 at 1:50 PM, Maciej Stachowiak  wrote:
>
> On Jan 4, 2011, at 11:03 AM, Dirk Schulze wrote:
>
>> Hi webkit-dev,
>>
>> I was looking at the MathML code recently and I wonder, that all files are 
>> located at WebCore/mathml, even the renderer. Shouldn't the rendering code 
>> be moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?
>
> Yes, the rendering code would be better placed in the rendering/ directory.

Well, not to buck the trend, but ...

I actually prefer having it all under the 'mathml' directory so that
is what I did.  No one has complained before.

If there is a strong preference to move the RenderMathML* files to
WebCore/rendering/, I'm not against it.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] libxml2 "override encoding" support

[Alexey Proskuryakov]

04.01.2011, в 18:40, Alex Milowski написал(а):

> Looking at the libxml2 API, I've been baffled myself about how to
> control the character encoding from the outside.  This looks like a
> serious lack of an essential feature.  Anyone know about this above
> "hack" and can provide more detail?


Here is some history: 
, 
.

- WBR, Alexey Proskuryakov

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

[webkit-dev] libxml2 "override encoding" support

[Alex Milowski]

I'm working through some rather thorny experiments with new XML
support within the browser and I ran into this snippet:

static void switchToUTF16(xmlParserCtxtPtr ctxt)
{
// Hack around libxml2's lack of encoding overide support by manually
// resetting the encoding to UTF-16 before every chunk.  Otherwise libxml
// will detect "?> blocks
// and switch encodings, causing the parse to fail.
const UChar BOM = 0xFEFF;
const unsigned char BOMHighByte = *reinterpret_cast(&BOM);
xmlSwitchEncoding(ctxt, BOMHighByte == 0xFF ?
XML_CHAR_ENCODING_UTF16LE : XML_CHAR_ENCODING_UTF16BE);
}

Looking at the libxml2 API, I've been baffled myself about how to
control the character encoding from the outside.  This looks like a
serious lack of an essential feature.  Anyone know about this above
"hack" and can provide more detail?

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Accessibility in WK2 update

[Chris Fleizach]

Just landed a large patch to make accessibility work in WK2

http://trac.webkit.org/changeset/75031

There were some changes that may have implications for other platforms, so if 
you work on accessibility read on.

• I replaced the getOrCreate method in AXObjectCache with rootObject, so that 
there's no ambiguity about how to get the top of the AX tree from WebKit/WK2.

• I made the root object be the ScrollView containing the RenderView (web 
area). The AX object representing the ScrollView is now handled by 
AccessibilityScrollView, instead of platform scroll views. This was needed 
because there are no platform scroll views in WK2. 

• The AccessibilityScrollView has 3 children, the 2 scroll bars (if visible) 
and the web area.

If any of these changes don't jive with your platform feel free to submit 
patches and I'll review them promptly.

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

Re: [webkit-dev] Handling of feature dependencies

[Benjamin]

On Tue, Jan 4, 2011 at 8:47 PM, Eric Seidel  wrote:

> Obviously many "devices" have already shipped with "full" copies of
> WebKit.  If you have a very low-memory/low-power device (more than a
> cell phone or a TV or a car or something that would run Qt -- all of
> these have numerous shipping example devices using WebKit), then
> WebKit is probably not what you want anyway. :)
>

There are a few people using QtWebKit on insanely constrained hardware where
there is simply not enough ram. The use cases are usually for simple html
(wikipedia reader, epub, etc).

The developers who did that usually hack WebKit themself for the release.
The WebKit on the device is rarely updated anyway.

I agree with the argument already mentioned, this is not something that
needs to be actively supported. The needs for most of those devices can be
supported by the existing flag or by a branch.

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

Re: [webkit-dev] WebKit-WinCE finally merged

[Eric Seidel]

Currently EWS bots do not run tests, so it shouldn't require any more
power, just another machine. [1]

But I certainly can understand having limited hardware. :)

Thanks.

-eric

1.  You certainly can run more than one bot on a single machine, but
you need plenty of RAM to make sure multiple copies of WebKit linking
at once doesn't send your machine thrashing its page file for 2
months. :)

On Tue, Jan 4, 2011 at 4:50 PM, Patrick Gansterer  wrote:
> Basically yes, but EWS needs more CPU power than build slave and I want to 
> see how the machine performs for a while. ;-)
>
> Eric Seidel:
>
>> Cool!  Interest in setting up an EWS bot?
>>
>> You would just need to add a "wince-ews" to this file:
>> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py
>>
>> And then run:
>> ./Tools/EWSTools/start-queue.sh wince-ews paroga-ews
>>
>> -eric
>>
>> On Tue, Jan 4, 2011 at 4:27 PM, Patrick Gansterer  wrote:
>>> Hi all,
>>>
>>> I'm glad to say that WebKit-WinCE is finally merged and got a working build 
>>> slave [1] today.
>>>
>>> Many, many thanks to the people from TorchMobile who did the original WinCE 
>>> port and all the friends that reviewed my patches to make this possible. 
>>> Thanks!
>>>
>>> It would be nice if we can try to keep it green when doing changes which 
>>> affect WinCE ;-).
>>>
>>> [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)
>>>
>>> - Patrick
>>> ___
>>> 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] WebKit-WinCE finally merged

[Patrick Gansterer]

Basically yes, but EWS needs more CPU power than build slave and I want to see 
how the machine performs for a while. ;-)

Eric Seidel:

> Cool!  Interest in setting up an EWS bot?
> 
> You would just need to add a "wince-ews" to this file:
> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py
> 
> And then run:
> ./Tools/EWSTools/start-queue.sh wince-ews paroga-ews
> 
> -eric
> 
> On Tue, Jan 4, 2011 at 4:27 PM, Patrick Gansterer  wrote:
>> Hi all,
>> 
>> I'm glad to say that WebKit-WinCE is finally merged and got a working build 
>> slave [1] today.
>> 
>> Many, many thanks to the people from TorchMobile who did the original WinCE 
>> port and all the friends that reviewed my patches to make this possible. 
>> Thanks!
>> 
>> It would be nice if we can try to keep it green when doing changes which 
>> affect WinCE ;-).
>> 
>> [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)
>> 
>> - Patrick
>> ___
>> 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] WebKit-WinCE finally merged

[Eric Seidel]

Sadly, you need to modify this list as well:
http://trac.webkit.org/browser/trunk/Tools/QueueStatusServer/model/queues.py#L39

-eric

On Tue, Jan 4, 2011 at 4:34 PM, Eric Seidel  wrote:
> Cool!  Interest in setting up an EWS bot?
>
> You would just need to add a "wince-ews" to this file:
> http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py
>
> And then run:
> ./Tools/EWSTools/start-queue.sh wince-ews paroga-ews
>
> -eric
>
> On Tue, Jan 4, 2011 at 4:27 PM, Patrick Gansterer  wrote:
>> Hi all,
>>
>> I'm glad to say that WebKit-WinCE is finally merged and got a working build 
>> slave [1] today.
>>
>> Many, many thanks to the people from TorchMobile who did the original WinCE 
>> port and all the friends that reviewed my patches to make this possible. 
>> Thanks!
>>
>> It would be nice if we can try to keep it green when doing changes which 
>> affect WinCE ;-).
>>
>> [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)
>>
>> - Patrick
>> ___
>> 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] WebKit-WinCE finally merged

[Eric Seidel]

Cool!  Interest in setting up an EWS bot?

You would just need to add a "wince-ews" to this file:
http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py

And then run:
./Tools/EWSTools/start-queue.sh wince-ews paroga-ews

-eric

On Tue, Jan 4, 2011 at 4:27 PM, Patrick Gansterer  wrote:
> Hi all,
>
> I'm glad to say that WebKit-WinCE is finally merged and got a working build 
> slave [1] today.
>
> Many, many thanks to the people from TorchMobile who did the original WinCE 
> port and all the friends that reviewed my patches to make this possible. 
> Thanks!
>
> It would be nice if we can try to keep it green when doing changes which 
> affect WinCE ;-).
>
> [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)
>
> - Patrick
> ___
> 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] WebKit-WinCE finally merged

[Kenneth Rohde Christiansen]

Nice! Congratulation!

Keep the patches coming ;-)

Cheers,
Kenneth

On Wed, Jan 5, 2011 at 1:27 AM, Patrick Gansterer  wrote:
> Hi all,
>
> I'm glad to say that WebKit-WinCE is finally merged and got a working build 
> slave [1] today.
>
> Many, many thanks to the people from TorchMobile who did the original WinCE 
> port and all the friends that reviewed my patches to make this possible. 
> Thanks!
>
> It would be nice if we can try to keep it green when doing changes which 
> affect WinCE ;-).
>
> [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)
>
> - Patrick
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
Kenneth Rohde Christiansen
Senior Engineer
Application and Service Frameworks, Nokia Danmark A/S
Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com

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

[webkit-dev] WebKit-WinCE finally merged

[Patrick Gansterer]

Hi all,

I'm glad to say that WebKit-WinCE is finally merged and got a working build 
slave [1] today.

Many, many thanks to the people from TorchMobile who did the original WinCE 
port and all the friends that reviewed my patches to make this possible. Thanks!

It would be nice if we can try to keep it green when doing changes which affect 
WinCE ;-).

[1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build)

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

Re: [webkit-dev] Handling of feature dependencies

[Jake]

I agree - disabling features per platform is a bad precedence to set for
webkit.

Just my 2 cents.

-Jake

On Tue, Jan 4, 2011 at 4:48 PM, Patrick Gansterer  wrote:

>
> Eric Seidel:
>
> > The more you turn off, the less the binary you create is "WebKit".  It
> > tells servers its "WebKit" via its useragent, but then it doesn't have
> > the features that pages have come to expect from WebKit -- this is bad
> > for WebKit and bad for your users.
>
> Feature detection by user agent is bad (but common) and can be done in a
> better way.
> I don't think this is a reason to remove feature switches.
>
> > A better course of action is to study the memory usage and reduce
> > memory usage for all ports of WebKit, instead of just hacking off
> > lumps.  I think you'll find that things like the "console" don't use
> > much memory at all.
>
> Example from WinCE5: There's a limit of 32MB per process, so every byte is
> important. IMHO "console" isn't a "big player", but XSLT as an example also
> needs libxslt as additional dependency. SQLite for "database" is the same.
> Maybe the WebKit code does not need so much memory, but we don't need the
> third party libs (they are not system libraries on every platform :)).
>
> > Obviously many "devices" have already shipped with "full" copies of
> > WebKit.  If you have a very low-memory/low-power device (more than a
> > cell phone or a TV or a car or something that would run Qt -- all of
> > these have numerous shipping example devices using WebKit), then
> > WebKit is probably not what you want anyway. :)
>
> Sometimes WebKit is exactly the correct solution! If you want to maintain
> only _one_ version of your application I don't see a better way than using a
> standard compliant browser engine.
> A small HTML page works perfectly on a small device and on the high end
> computer.
>
> - Patrick
> ___
> 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] Handling of feature dependencies

[Patrick Gansterer]

Eric Seidel:

> The more you turn off, the less the binary you create is "WebKit".  It
> tells servers its "WebKit" via its useragent, but then it doesn't have
> the features that pages have come to expect from WebKit -- this is bad
> for WebKit and bad for your users.

Feature detection by user agent is bad (but common) and can be done in a better 
way.
I don't think this is a reason to remove feature switches.

> A better course of action is to study the memory usage and reduce
> memory usage for all ports of WebKit, instead of just hacking off
> lumps.  I think you'll find that things like the "console" don't use
> much memory at all.

Example from WinCE5: There's a limit of 32MB per process, so every byte is 
important. IMHO "console" isn't a "big player", but XSLT as an example also 
needs libxslt as additional dependency. SQLite for "database" is the same. 
Maybe the WebKit code does not need so much memory, but we don't need the third 
party libs (they are not system libraries on every platform :)).

> Obviously many "devices" have already shipped with "full" copies of
> WebKit.  If you have a very low-memory/low-power device (more than a
> cell phone or a TV or a car or something that would run Qt -- all of
> these have numerous shipping example devices using WebKit), then
> WebKit is probably not what you want anyway. :)

Sometimes WebKit is exactly the correct solution! If you want to maintain only 
_one_ version of your application I don't see a better way than using a 
standard compliant browser engine.
A small HTML page works perfectly on a small device and on the high end 
computer.

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

Re: [webkit-dev] Best way to track feature evolution from release-to-release

[Darin Adler]

On Jan 4, 2011, at 1:47 PM, Tom Bahnck wrote:

> We are looking for the best way to identify the supported syntactical 
> elements in each release, such as HTML/CSS tags/properties/values. Eric 
> Seidel's excellent lecture on the Google code channel points out that the 
> /WebCore/dom/*.idl /WebCore/html/*.in files list standard page-level tokens, 
> which are used to build a string cache.  This is a very useful start; 
> however, is there a way to correlate the supported attributes to elements?  
> E.g., considering "src", to know that "src" is supported for  and 
> , or  and not , etc.?

I can’t think of a simple way to find the complete list of what attributes are 
supported for each element. Much of the code would be in the elements’ 
parseMappedAttribute functions, but not all.

A project to create a table that tracks this could give us a head start. I’m 
sure we can keep such a thing up to date if it’s checked in alongside the 
sources to the classes themselves.

> A related question is, what qualifies a given build for a Safari-### tag?

Those tags just reflect what WebKit Apple chose to ship with versions of 
Safari. The Safari tags are our way of precisely stating after the fact to the 
rest of the WebKit community exactly what we chose to ship with a given version 
of Safari.

But what goes into each is Apple-internal decision. Apple, like others who put 
out WebKit releases, does our own branching and release management and makes up 
our own mind about what does and does not go into each release.

We don’t have a shared release process for the team overall.

> Understanding how frequently tags are made public would inform us (roughly) 
> of how many release candidates we need to evaluate, when for example, 
> upgrading our embedded WebKit release from X to Y, in search of support for a 
> new feature.

We put out tags for releases whenever we have the chance. It’s not a part of a 
release process; just something we do later on to make things clearer for the 
record.

As I said, the Safari tags are an Apple thing, not really something intended 
for use by all the others working on the WebKit project. That’s why it’s in the 
releases/Apple directory in the Subversion repository. I encourage others 
producing WebKit releases to make similar tags, as the WebKitGTK folks have 
done.

-- Darin

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

Re: [webkit-dev] MathML renderer

[Maciej Stachowiak]

On Jan 4, 2011, at 11:03 AM, Dirk Schulze wrote:

> Hi webkit-dev,
> 
> I was looking at the MathML code recently and I wonder, that all files are 
> located at WebCore/mathml, even the renderer. Shouldn't the rendering code be 
> moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?

Yes, the rendering code would be better placed in the rendering/ directory.

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

[webkit-dev] Best way to track feature evolution from release-to-release

[Tom Bahnck]

I work on set-top box and PC-based media player stacks which integrate
WebKit to render a UI (e.g. guide and storefront) for viewers.  We are
looking for the best way to identify the supported syntactical elements in
each release, such as HTML/CSS tags/properties/values.  Eric Seidel's
excellent lecture on the Google code channel points out that the
/WebCore/dom/*.idl /WebCore/html/*.in files list standard page-level tokens,
which are used to build a string cache.  This is a very useful start;
however, is there a way to correlate the supported attributes to elements?
E.g., considering "src", to know that "src" is supported for  and
, or  and not , etc.?

A related question is, what qualifies a given build for a Safari-### tag?
Understanding how frequently tags are made public would inform us (roughly)
of how many release candidates we need to evaluate, when for example,
upgrading our embedded WebKit release from X to Y, in search of support for
a new feature.

Thank you very much for the support you provide.

-- 
Tom Bahnck
Motorola Mobility, Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Handling of feature dependencies

[Eric Seidel]

Konstantin:

The more you turn off, the less the binary you create is "WebKit".  It
tells servers its "WebKit" via its useragent, but then it doesn't have
the features that pages have come to expect from WebKit -- this is bad
for WebKit and bad for your users.

A better course of action is to study the memory usage and reduce
memory usage for all ports of WebKit, instead of just hacking off
lumps.  I think you'll find that things like the "console" don't use
much memory at all.

Obviously many "devices" have already shipped with "full" copies of
WebKit.  If you have a very low-memory/low-power device (more than a
cell phone or a TV or a car or something that would run Qt -- all of
these have numerous shipping example devices using WebKit), then
WebKit is probably not what you want anyway. :)

-eric

On Tue, Jan 4, 2011 at 11:17 AM, Darin Adler  wrote:
> On Jan 4, 2011, at 2:59 AM, Konstantin Tokarev wrote:
>
>> 03.01.2011, 23:58, "Darin Adler" :
>>> On Jan 3, 2011, at 12:53 PM, Konstantin Tokarev wrote:
>>>
  I'd like to get WebKit running on device with very limited resources. 
 Basically, it would be quite enough if resulting "browser" just properly 
 displayed HTML 4 + CSS 2.1, and it would be highly desired to reduce size 
 of binaries and memory usage as it's possible
>>>
>>> This is a non-goal for the WebKit project. Please look at 
>>> .
>>>
>>> I understand that you might want that, but the project doesn’t accommodate 
>>> everything that everyone wants, especially someone who has not yet 
>>> contributed something else.
>>
>> OK, but don't you think that some extra shrinking options may be useful for 
>> everyone using WebKit in embedded environments?
>
> I don’t.
>
> But maybe you could convince me with specific examples.
>
>    -- Darin
>
> ___
> 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] Handling of feature dependencies

[Darin Adler]

On Jan 4, 2011, at 2:59 AM, Konstantin Tokarev wrote:

> 03.01.2011, 23:58, "Darin Adler" :
>> On Jan 3, 2011, at 12:53 PM, Konstantin Tokarev wrote:
>> 
>>>  I'd like to get WebKit running on device with very limited resources. 
>>> Basically, it would be quite enough if resulting "browser" just properly 
>>> displayed HTML 4 + CSS 2.1, and it would be highly desired to reduce size 
>>> of binaries and memory usage as it's possible
>> 
>> This is a non-goal for the WebKit project. Please look at 
>> .
>> 
>> I understand that you might want that, but the project doesn’t accommodate 
>> everything that everyone wants, especially someone who has not yet 
>> contributed something else.
> 
> OK, but don't you think that some extra shrinking options may be useful for 
> everyone using WebKit in embedded environments?

I don’t.

But maybe you could convince me with specific examples.

-- Darin

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

[webkit-dev] MathML renderer

[Dirk Schulze]

Hi webkit-dev,

I was looking at the MathML code recently and I wonder, that all files are 
located at WebCore/mathml, even the renderer. Shouldn't the rendering code be 
moved to WebCore/rendering/? Or better WebCore/rendering/mathml/?

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

Re: [webkit-dev] git history and the moving to Source

[Evan Martin]

git-svn appears to use -C (which implies -M) by default.
See "sub generate_diff" in .../libexec/git-core/git-svn.

On Tue, Jan 4, 2011 at 2:50 AM, Balazs Kelemen  wrote:
> That works, thank you guys!
> By the way, don't you think the -M switch for git diff should be used by
> webkit-patch?
> It's much easier to review a patch with rename and changes with the rename
> detection.
>
> On 01/04/2011 07:26 AM, Evan Martin wrote:
>>
>> Adam is correct.
>>
>> To elaborate, there are two rename-related flags of interest:
>>
>> 1) When you git log -- foo/bar.cc, you're saying "only show me logs
>> that apply to the path foo/bar.cc".  This excludes renames implicitly.
>>  The --follow flag indicates that the filename filter should be
>> broadened to include renames.
>>
>> 2) If you are viewing diffs (like with -p), you must pass -M etc. just
>> as you would to git diff for it to find renames.
>>
>> Here's an interesting thread from Linus on the subject:
>>   http://kerneltrap.org/mailarchive/git/2009/1/30/4856404/thread
>> As usual, his opinions on renames are ...interesting.
>>
>> On Mon, Jan 3, 2011 at 5:56 PM, Adam Barth  wrote:
>>>
>>> There's a git option to follow renames.  I think it's --follow, but
>>> some git experts might know better.
>>>
>>> Adam
>>>
>>>
>>> On Mon, Jan 3, 2011 at 5:53 PM, Balazs Kelemen
>>>  wrote:

 I have just realized that git log -- filename does not output the
 history before the file had been moved to Source. It seems like the
 whole git history will be lost after the move. Did we take this into
 consideration when we decided to switch to the new directory  structure?
 Can we do something to save the history? Or should I just
 do something locally to fix this?

 Balazs


 ___
 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

Re: [webkit-dev] git history and the moving to Source

[Adam Barth]

I don't really know enough about that to have an opinion, but you
should feel free to write a patch and we'll get the right folks to
review it.

Adam


On Tue, Jan 4, 2011 at 2:50 AM, Balazs Kelemen  wrote:
> That works, thank you guys!
> By the way, don't you think the -M switch for git diff should be used by
> webkit-patch?
> It's much easier to review a patch with rename and changes with the rename
> detection.
>
> On 01/04/2011 07:26 AM, Evan Martin wrote:
>>
>> Adam is correct.
>>
>> To elaborate, there are two rename-related flags of interest:
>>
>> 1) When you git log -- foo/bar.cc, you're saying "only show me logs
>> that apply to the path foo/bar.cc".  This excludes renames implicitly.
>>  The --follow flag indicates that the filename filter should be
>> broadened to include renames.
>>
>> 2) If you are viewing diffs (like with -p), you must pass -M etc. just
>> as you would to git diff for it to find renames.
>>
>> Here's an interesting thread from Linus on the subject:
>>   http://kerneltrap.org/mailarchive/git/2009/1/30/4856404/thread
>> As usual, his opinions on renames are ...interesting.
>>
>> On Mon, Jan 3, 2011 at 5:56 PM, Adam Barth  wrote:
>>>
>>> There's a git option to follow renames.  I think it's --follow, but
>>> some git experts might know better.
>>>
>>> Adam
>>>
>>>
>>> On Mon, Jan 3, 2011 at 5:53 PM, Balazs Kelemen
>>>  wrote:

 I have just realized that git log -- filename does not output the
 history before the file had been moved to Source. It seems like the
 whole git history will be lost after the move. Did we take this into
 consideration when we decided to switch to the new directory  structure?
 Can we do something to save the history? Or should I just
 do something locally to fix this?

 Balazs


 ___
 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

Re: [webkit-dev] [chromium] using WEBKIT_API properly

[Darin Fisher]

Correction:  you meant "pure virtual" functions.

(I'm adding a note to the README file about these rules by the way.)

-Darin


On Fri, Dec 3, 2010 at 8:55 AM, Darin Fisher  wrote:

> Yes, indeed.  Thanks Jeremy!
>
>
> On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow  wrote:
>
>> You forgot to mention virtual functions, which is another case where you
>> do _not_ use WEBKIT_API.
>>
>> J
>>
>> On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher  wrote:
>>
>>> If you do not work on the Chromium port of WebKit, you can stop reading
>>> now.
>>>
>>> I've noticed that there is some confusion about how to use WEBKIT_API
>>> properly.
>>> WEBKIT_API causes a function to be exported from WebKit when it is built
>>> as a DLL,
>>> allowing Chromium to call the function.
>>>
>>> The rule is actually quite simple:
>>>
>>>WEBKIT_API should be affixed to any public, non-inline function that
>>> is intended
>>>for the embedder (Chromium) to call.
>>>
>>> Put another way:
>>> -- Do not apply WEBKIT_API to inline functions.
>>> -- Do not apply WEBKIT_API to private functions.
>>> -- Do not apply WEBKIT_API to public functions within a #if
>>> WEBKIT_IMPLEMENTATION block.
>>>
>>> (Of related note, we never put WEBKIT_API on public constructors and
>>> destructors.
>>> Instead, we have constructors call an initialize method and destructors
>>> call a reset
>>> method.  Those then end up having the WEBKIT_API prefix applied.)
>>>
>>> Thanks!
>>> -Darin
>>>
>>>
>>> ___
>>> 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] Apple-Mac-Pro-6 is misconfigured

[William Siegrist]

On Jan 3, 2011, at 10:31 PM, Eric Seidel wrote:

> Can we make the master config run something which aborts the slave if
> the umask is wrong?
> 

I don't know of an easy way to do that, but hopefully Lucas will fix it soon so 
it won't matter. 

-Bill



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

Re: [webkit-dev] Handling of feature dependencies

[Konstantin Tokarev]

03.01.2011, 23:58, "Darin Adler" :
> On Jan 3, 2011, at 12:53 PM, Konstantin Tokarev wrote:
>
>>  I'd like to get WebKit running on device with very limited resources. 
>> Basically, it would be quite enough if resulting "browser" just properly 
>> displayed HTML 4 + CSS 2.1, and it would be highly desired to reduce size of 
>> binaries and memory usage as it's possible
>
> This is a non-goal for the WebKit project. Please look at 
> .
>
> I understand that you might want that, but the project doesn’t accommodate 
> everything that everyone wants, especially someone who has not yet 
> contributed something else.

OK, but don't you think that some extra shrinking options may be useful for 
everyone using WebKit in embedded environments?

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

Re: [webkit-dev] git history and the moving to Source

[Balazs Kelemen]

That works, thank you guys!
By the way, don't you think the -M switch for git diff should be used by 
webkit-patch?
It's much easier to review a patch with rename and changes with the 
rename detection.


On 01/04/2011 07:26 AM, Evan Martin wrote:

Adam is correct.

To elaborate, there are two rename-related flags of interest:

1) When you git log -- foo/bar.cc, you're saying "only show me logs
that apply to the path foo/bar.cc".  This excludes renames implicitly.
  The --follow flag indicates that the filename filter should be
broadened to include renames.

2) If you are viewing diffs (like with -p), you must pass -M etc. just
as you would to git diff for it to find renames.

Here's an interesting thread from Linus on the subject:
   http://kerneltrap.org/mailarchive/git/2009/1/30/4856404/thread
As usual, his opinions on renames are ...interesting.

On Mon, Jan 3, 2011 at 5:56 PM, Adam Barth  wrote:

There's a git option to follow renames.  I think it's --follow, but
some git experts might know better.

Adam


On Mon, Jan 3, 2011 at 5:53 PM, Balazs Kelemen  wrote:

I have just realized that git log -- filename does not output the
history before the file had been moved to Source. It seems like the
whole git history will be lost after the move. Did we take this into
consideration when we decided to switch to the new directory  structure?
Can we do something to save the history? Or should I just
do something locally to fix this?

Balazs


___
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