July 2005 - webkit-dev - lists.webkit.org

XCode 2.1 Migration
by Geoffrey Garen 25 Jul '05

25 Jul '05

Greetings opensource developers. Tomorrow, Thursday 7/21, between 12:00 noon and 1:00 PM PST, the Webkit source tree will upgrade to XCode 2.1 project files. Since most of you are already using XCode 2.1, this shouldn't affect you. However, if you are still using XCode 2.0, you will need to upgrade to 2.1 before then. Once this upgrade takes place, you should remove your old build products directory and your old project file directories. A quick way to remove your old project file directories is: find . -name \*.pbproj | xargs rm -rf; find . -name \*.xcode | xargs rm -rf. Cheers, Geoff Garen

4 7

sharing code between kjs and khtml
by Maciej Stachowiak 25 Jul '05

25 Jul '05

Hello WebKit and KHTML hackers, I have some code I'd like to share between JavaScriptCore and WebCore (and in the KDE version it should probably be shared between kjs and khtml). In particular, I am thinking of the following: * New hashtable template code (HashMap/HashSet). This is more flexible than most other hashtables because it lets you use different hash/equal functions with the same type in different tables, and it is highly tuned for performance. In any case, there are four different hand-rolled hashtable implementations in the JavaScriptCore version of kjs that should really be replaced with this code, and in kjs it's not an option to use stuff like QDict or QHash, even if it were desireable to do so. * Better assert macros. So far we've mostly avoided using our ASSERT macros in JavaScriptCore and in the WebCore khtml directory, however, they are better in a few ways than stock assert(). Most notably, they are set up to crash right in the stack frame where the assertion fails, instead of several frames worth of function calls down. This makes for much better stack traces and saves a lot of time when running under gdb. I can think of three basic options for code sharing: 1) Cut and paste the relevant files, use in both places. This sucks because any fixes or improvements would have to be made in two places, and history shows that people will usually forget to update other copies of the code. 2) Dump in kjs and export for use in khtml, even though this stuff has basically nothing to do with a JavaScript API. 3) Make a new module that both kjs and khtml depend on ("kxmlcore"? "kxmlbase"? something like that...). For WebKit purposes 2 and 3 are basically the same, since even with a new logical module we would dump it in JavaScriptCore along with kjs and pcre to avoid making additional shared libraries. Any thoughts? Regards, Maciej

2 1

HTML attributes and tags - slight tweak
by Maciej Stachowiak 25 Jul '05

25 Jul '05

Hi Everyone, Dave Hyatt's recent code QualifiedName changes were a much-needed code cleanup and structural improvement. However, as things stand, the symbolic names used for specific HTML tags and attributes in the code have gotten a bit wordy. Compare: Before: --------- ID_SPAN ID_A ATTR_SRC ATTR_CLASS After: ------ HTMLTags::span() HTMLTags::a() HTMLAttributes::src() HTMLAttributes::classAttr() When you have an if test checking for several of these I think it actually starts to hurt legibility a bit. Dave and I discussed ways to improve this a bit and here's what we came up with: * Change the various html name symbols from functions to global variables - currently they are just inline functions that return a global, which doesn't add much. * Combine HTMLTags and HTMLAttributes classes into a single HTMLNames namespace. * Suffix all tag names with Tag and all attribute names with Attr The net result would be that you import the HTMLNames namespace, and you can write: Proposed: ------------ spanTag aTag srcAttr classAttr Which compares favorably to the old names. In cases where you might care about more than one markup language's set of names you wouldn't import the HTML namespace, and could write them fully qualified, e.g. HTMLNames::spanTag. One possible variant is to just call the namespace HTML, so in the fully qualified case you could just write HTML::spanTag. The tradeoff is that people might expect the namespace to contain more than just the names in that case, they might expect it to contain the whole HTML DOM, which it wouldn't. Anyway, I wanted to send this out to see if anyone has comments before I make the change, so we can avoid too much thrashing back and forth on the names. Regards, Maciej

2 1

XCode 2.1 Migration
by Geoffrey Garen 22 Jul '05

22 Jul '05

XCode 2.1 migration is now complete. Cheers, Geoff

1 0

JavaScriptCore runs on Windows!
by Justin Haygood 21 Jul '05

21 Jul '05

w00t! it runs, works, and passes the regression suite with only 15 regressions over the MacOS X build.

2 1

Some thoughts and proposals
by Justin Haygood 20 Jul '05

20 Jul '05

This could possibly greatly improve portability, I don't know, but here's an idea: Drawing System (QRect, QPainter, etc..): Implement using the Cairo Graphics library, which is cross-platform. This provides the benefits of hardware acceleration on all supported operating systems (Apple MacOS X, Microsoft Windows, Systems with X11 support). Of course, systems that are used that aren't supported by Cairo Graphics, or don't want to be supported using Cairo, can of course not use the Cairo implementation Networking Library: Use a cross-platform networking (HTTP/FTP, etc..) library that can be used by all operating systems. I think http://webkit.opendarwin.org/projects/portability/index.html mentions this Image Library Same as above. ********************** * Justin Haygood * * jhaygood(a)spsu.edu * **********************

1 0

Re: [webkit-dev] Documentation project
by David Storey 20 Jul '05

20 Jul '05

In the absence of any opinions, I'll list a few ideas of my own. If there is any pressing need for any documentation, or anyone has any ideas, then give me a shout. Developer Documentation: I think for each technology that WebKit supports (HTML, XHTML, XML, CSS etc.), there should be a page that mentions: What the technology is What problems it solves/it's reason for being Each tag in the standard (for tag based technologies) Each attribute for the tag For each tag and attribute it should: Describe what it does Show an example of it used correctly Mention if it has been depreciated (for example tags that can't be used in strict mode for html) Say if WebKit either implements it, implements it with known bugs (link to bugzilla bugs?), doesn't support it, or wont support it, possibly for each version of WebKit. As well as the W3C standards, other none standards could be listed in their own sections such as IE, Mozilla and WhatWG extensions. Project Documentation I'm not too sure about API docs and tutorials, as I don't program in C or obj-c, but I'm sure there are plenty of Apple api documents that can be linked to. I've seen a number of one line of code browser tutorials on the likes of MacDevCenter that could also be linked too. Some more documentation could be written to cover common tasks that developers would use WebKit for, for example, to display a web feedback or registration form in an application. There could be a document giving an overview of the differences between KHTML/KJS and WebKIt as well as a family tree of what WebKit is based on, and what projects are based on WebKit (GTK+ WebCore, GNUStep WebCore etc.). It would be nice if there were pages for each sub project -- as exists now -- that mentions what the aims of them projects are. The pages should have some way to add discussion about how it is planned to move them forward, and what will be implemented and how. Maybe the talkback feature of the wiki could be used for this. It would be a good way to find out what features people really want to see in WebKit. Perhaps a roadmap could be produced. For standards that are not supported by safari (PICS, P3P?), there could be a page assessing them and whether they may be supported in the future. If a standard is still in the review stage, any points that are unclear or need refining could be mentioned, so that they could be discussed. HeaderDoc could possibly be used for creating API documentation from the source code. Coming from a Java background, I've always found JavaDoc useful, and if WebCore and JavaScriptCore used it then i might make it easier for coders, that don't know the code well, to find the part of the code that they want to work on, and help spotlight index the source better. This would make big changes between the WebKit source and the KHTML/KJS however unless they rolled in the comments too. Maybe a list of frequently asked questions and frequently submitted bugs/none-bugs would be nice. Links to all the test suits and what each test is for would be nice, along with whether the current version of WebKit passes or fails the test, so that it is easy to find ones that fail. Website: Probably not a priority, but the site could maybe get it's own style instead of the safari rss theme that it has at the moment. A logo would be nice, as the current image shows the Safari icon, even though WebKit is used outside of Safari (it may also be a copyright issue if a developer wants to show a badge to say their app is webkit enabled?). I'm not sure if Apple has logos for the Kits, but don't the Core frameworks have them funny gem sphere things? It can't harm having our own Hexley mascot in Bermuda shorts and on a surfboard too ;) On the wiki I added a page for apps that currently used WebKit. I'm not sure what Apple apps use WebKit, so maybe someone could add the ones I've missed and any others they know of. I filled in the Team members page too, but I took the information from bugzilla, so there are members missing. If you are missing or any info is wrong then you can add yourself or change it. I think that's all for now, thanks, David On 7 Jul 2005, at 19:19, John Sullivan wrote: I think using Bugzilla to submit proposed changes to the main site seems sensible. There are a few of us with opendarwin commit privileges who can do the actual website changes. The reviewer for the proposed changes would depend on the topic, to ensure technical accuracy. I don't have any opinion on how the documentation should be improved, but I know others do, so hopefully they will chime in. John

2 1

NOTICE: anoncvs downtime
by Kevin Van Vechten 20 Jul '05

20 Jul '05

The anoncvs.opensource.apple.com server will be offline shortly after 13:00 PDT tomorrow, Tuesday 7/19/05, for a system upgrade. The upgrade is expected to take less than two hours. - Kevin

2 1

Clean Build Required after 2005-07-18 checkin
by Kevin T. Broderick 19 Jul '05

19 Jul '05

Please note that a clean build is required, per the ChangeLog note in WebCore/ChangeLog: "2005-07-18 David Hyatt <hyatt(a)apple.com> Add support for -khtml-appearance in preparation for the addition of RenderTheme to the tree for form controls. Make clean is required after this check-in, since there is some sort of bizarre bug with XCode dependencies on the property generation script." (thanks to Mitz on #webkit for pointing this out to me) Kevin Broderick / kbroderick(a)smcvt.edu

1 0

mathml support in webkit / khtml
by Andy Somogyi 18 Jul '05

18 Jul '05

Hello all I'm working on a new mathml component that will be part of kdom / khtml2. I have just commited my first set of imports to the new kmathml component. Currently, most of the mathml dom objects are stubbed out, but there is nothing in the way of rendering yet. I'm looking for some input as to what is the best way to intgrate mathml support into kthml. In my previous mathml application, a windows mathml display and editing control http://numerator.sourceforge.net I use a fairly complex logic to layout and display mathml, so I wanted to discuss the layout logic I use, and get some discussion going on whether or not this is the best layout logic to use in a kdom component, how well would this approach integrate with khtml and so forth. So, here is a quick overview of the mathml layout logic I use (note, same logic used in gtkmathview): They layout and rendering is performed in several phases: 1: parsing / mathml dom tree building 2: generate an 'area' tree from the dom tree 3: fit the 'area' tree to a given size and re-organize the are tree 4: draw to a surface The first phase is parsing the document and loading it into dom. This phase is not really interesting, essentialy, the existing XmlReader (sax parser) just calls the MathMLDocument class for each xml element encountered, and the MathMLDocument creates mathml elements that are then stuffed in the dom tree. This phase just builds a straight dom representation of the mathml source, there is no layout information yet. Then the first intresting bit happens, create an Area tree from the dom tree An 'Area' is a node in a single rooted a-cyclic graph. An area can have numerous child elements, however each child element is not aware of its parent element. An area represents a rectangular region, it maintains a state of width, height and depth, but does not keep the x-y location of this area. The location of the area is computed each time the tree is drawn. Areas are fairly simple, there are terminal areas such as glyph areas, and container areas such as horizontal and vertical areas, these contain either a horizontal or vertical stack of child areas. An area tree is generated from the dom tree. Each source mathml dom element recursivly generates a collection of areas. A good example is the mathml row element. This element represents a horizontal row of elements. In this case, lest assume each child dom element of the row element is either a glyph or a identifier / operator such as '+', '1', 'xyz', etc. So, the mrow dom element would be visited, a horizontal area would be created, then each child dom element of the 'mrow' would be visited, each one would return a area, then each child area would then be inserted into the horizontal area element, and this element would then be returned. Now, between each child area that is inserted into the horizontal area, a 'Filler Area' is inserted. This is an area that can stretch to fill an empty region. This is used when the area tree is fitted into a given region. So at now we have a tree if areas and filler areas, we then ask it to 'fit' to a given size. We call the 'Fit' method with a bounding box of the size we want to fit to. at this point, each filler area returns a space area that coresponds to this size it is asked to fit to. Now we have a layed out area tree and are ready to render it. We call the render method with a rendering context (QPainter type thing to draw to) and a x / y coordinates representing the origin of that area where it should draw to. Each container area calls each child area with an updated set of origin coordinates where it should draw itself. I have been looking into the khtml::RenderObject, this is the base object of the kthml rendering tree. My current thought is that one way of integrating mathml support into khtml is to create a collection of mathml specific RenderObject derived classes to create a mathml rendering tree. This approach would I think seemlessly intgrate mathml into khtml. I however am not very familier with the code base, and I'm not sure of what kind of issues this approach might present. If anybody thinks this approach is good, is stupid, etc... please let my know and we can work out a better approach.

1 0