Module Updates XPToolkit December 13th Submitted byPeter Trudelle <trudelle@netscape.com> Here's an excellent status update on the XPToolkit from Peter Trudelle. Accomplishments: We hit our M0 and M1 milestones, having hired a manager and posted an initial plan. We still have a lot of open issues, dependencies and risks to resolve, but we are ready to start implementing this plan while we continue to tweak it in in the background. Hooked the tree widget to the DOM and got it to display bookmarks. Wrote "How to Write a Widget" document. Posted a preliminary Data Model Widget spec. (Internal-only for now) Determined the basic tree content model structure. Wrote a spec on how each can/widget should be implemented. Reconsidered XUL spec.  It wants some real world experience to flesh it out, but we plan to stick with the basic plan.  Beginning to work with capabilities of CSS and our style system so we can get the basic question of whither lie display semantics. Lots more meetings among the group where we have begun to get a picture on our event model, command system and widget framework.  None of these things are finalized, but the focus is getting better. Priorities Resolve QA Partner issues for automated/whitebox testing. Resolve Il8N requirements. Write code to read XUL and store it in the DOM sink Get treeview talking to DOM Get toolbar talking to DOM Complete the event model, command dispatch design. Decisions: We killed our first large snake, or rather turned it into an opportunity.  We had no time to produce the complete set of native widgets that some people were assuming we'd do in addition to a set of web  widgets for forms.  Since the native widgets weren't listed as a requirement for this project, we made a widget plan 10 days ago to do a complete set of web widgets, but provide a cascading architecture for adding in native widgets as time and resources permitted. We've been 'discussing' it ever since on Mozilla and elsewhere, but got final internal go-ahead in a Big Pit meeting Friday. Issues: Will the JS event handling/dispatching mechanism be fast enough for our needs? We'll have to do a proof of concept soon. Need to resolve threading model issues (re-entrancy, blocking, etc.). Need to resolve what I18N work needs to be done, and who will do it. Do we need to support MacOS 8.1? This greatly affects I18N on Mac. Will Ender be slimmed down to serve as the text widget? Huge effect on I18N. Who is responsible for getting core functionality to work on all platforms?  XPToolkit has been spending a lot of time getting things to work on Mac and Unix, rather than building the things we are supposed to supply on top. RDF and HT (HyperTree) December 18th Submitted by David Hyatt <hyatt@netscape.com> David Hyatt writes in with this RDF update: The tree view can now display bookmarks (copy the bookmarks file into your viewer directory and rename it to bookmarks.html). Nodes can now expand and collapse.   Editor December 18th Submitted by Akkana Peck <akkana@netscape.com> Here's Akkana's update on the status of the editor (composer): Selection is making progress. nsRange is mostly done, and we're now working on methods of testing it. Selection and RangeList have been hooked to the Frame code, so on Windows some of the new selection code is being called on mouse drag; on non-Windows platforms this is waiting on the mouse event handling code. Progress continues on the transaction manager; lots of stress/performance tests are in place. The transaction manager engineers will probably move over to help with selection for the next few weeks. We'll be spending some of our time over the next few weeks helping other groups with platform parity; since 2/3 of the editor team is on non-windows platforms we're eager to see working viewers on Mac and Linux, so we can get editor and selection functionality working everywhere.   NGLayout December 18th Submitted by Troy Chevalier <troy@netscape.com> Troy writes in with this update: Tables: more work on the CSS2 collapsing border model, and more work on getting tables to paginate CSS Rendering: we now correctly implement the CSS rendering model, where the border and background render at the bottom layer, then floaters, then content Javascript December 18th Submitted by Scott Furman <fur@netscape.com> This update comes from Scott Furman: We're concentrating our JavaScript C-engine efforts on XPCOMConnect (a terrible name that we plan to change soon): Scott Furman wrote an initial spec for a binary typelib format which captures the interface description of an XPCOM object.  Chris Cooper and Mike Shaver are working on the XPIDL compiler so that it generates these typelibs.   John Bandauer is working on the heart of XPCOMConnect, the actual glue code that makes XPCOM objects visible to JavaScript and vice-versa given their typelib descriptions. Previous Updates