|
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.
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.
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.
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
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
|