Re: [webkit-dev] git history and the moving to Source
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 Barthaba...@webkit.org 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 Kelemenkbal...@webkit.org 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
Re: [webkit-dev] Apple-Mac-Pro-6 is misconfigured
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] [chromium] using WEBKIT_API properly
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 da...@chromium.org wrote: Yes, indeed. Thanks Jeremy! On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow jor...@chromium.org 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 da...@chromium.org 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] git history and the moving to Source
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 kbal...@webkit.org 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 Barthaba...@webkit.org 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 Kelemenkbal...@webkit.org 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
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 kbal...@webkit.org 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 Barthaba...@webkit.org 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 Kelemenkbal...@webkit.org 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
[webkit-dev] MathML renderer
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] Handling of feature dependencies
On Jan 4, 2011, at 2:59 AM, Konstantin Tokarev wrote: 03.01.2011, 23:58, Darin Adler da...@apple.com: 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 http://webkit.org/projects/goals.html. 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
Re: [webkit-dev] Handling of feature dependencies
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 da...@apple.com wrote: On Jan 4, 2011, at 2:59 AM, Konstantin Tokarev wrote: 03.01.2011, 23:58, Darin Adler da...@apple.com: 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 http://webkit.org/projects/goals.html. 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
[webkit-dev] Best way to track feature evolution from release-to-release
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 img and video, or img and not video, 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] Best way to track feature evolution from release-to-release
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 img and video, or img and not video, 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] Handling of feature dependencies
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] Handling of feature dependencies
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 par...@paroga.com 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
[webkit-dev] WebKit-WinCE finally merged
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] WebKit-WinCE finally merged
Nice! Congratulation! Keep the patches coming ;-) Cheers, Kenneth On Wed, Jan 5, 2011 at 1:27 AM, Patrick Gansterer par...@paroga.com 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
Re: [webkit-dev] WebKit-WinCE finally merged
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 par...@paroga.com 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
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 e...@webkit.org 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 par...@paroga.com 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
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 par...@paroga.com 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 par...@paroga.com 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] Handling of feature dependencies
On Tue, Jan 4, 2011 at 8:47 PM, Eric Seidel e...@webkit.org 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
[webkit-dev] Accessibility in WK2 update
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
[webkit-dev] libxml2 override encoding support
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 ?xml version=1.0 encoding=encoding name? blocks
// and switch encodings, causing the parse to fail.
const UChar BOM = 0xFEFF;
const unsigned char BOMHighByte = *reinterpret_castconst unsigned
char*(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
Re: [webkit-dev] libxml2 override encoding support
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: http://mail.gnome.org/archives/xml/2006-February/msg00052.html, https://bugzilla.gnome.org/show_bug.cgi?id=614333. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MathML renderer
On Tue, Jan 4, 2011 at 1:50 PM, Maciej Stachowiak m...@apple.com 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
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 a...@webkit.org 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: http://mail.gnome.org/archives/xml/2006-February/msg00052.html, https://bugzilla.gnome.org/show_bug.cgi?id=614333. - 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] libxml2 override encoding support
On Tue, Jan 4, 2011 at 7:05 PM, Alexey Proskuryakov a...@webkit.org 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: http://mail.gnome.org/archives/xml/2006-February/msg00052.html, https://bugzilla.gnome.org/show_bug.cgi?id=614333. 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] MathML renderer
On Jan 4, 2011, at 7:09 PM, Alex Milowski wrote: On Tue, Jan 4, 2011 at 1:50 PM, Maciej Stachowiak m...@apple.com 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
