|
Highlights
-
A big cooperative effort involving a dozen people appears to have removed
all of our immediate blocks in resolving architectural and design issues
such as how to extend frames and use the widget interface. We seem
to have a plan and green light, at least for the short term. Special thanks
go to Rick Gessner and his amazing Gecko team for helping to blaze a trail
for us, and to David Hyatt, for being our lead scout on the trail.
Lowlights
-
None, this was really a super week!
Accomplishments
-
Got Solaris to build.
-
Extended the object frame so that it could support the instantiation of
arbitrary widgets.
-
Figured out how menus are actually going to get
events and work.
-
Posted a public update of the XPToolkit
Architecture doc.
-
Resolved widget vs frame issue.
-
Resolved tree widget vs. tree-as-table issue.
-
Met with Gecko team to resolve issues over how to proceed on platform parity
work. We now have the bugs identified, triaged, and the owners and
platform helpers identified and working closely together.
-
Fixed a few platform parity Bugs.
-
Overhauled the Unix build
pages and status
page.
Decisions
-
The big architectural issue that had blocked so many engineers last week
was on the use of frame vs widget interfaces, and how to extend frames.
The short story of what unblocks us is that some widgets will be new frame
types, and some widgets will be actual widgets. The distinction being
that the new frames will (to some degree) live in the layout DLL, and the
new widgets will be much more independent. The mechanism we
have agreed upon is that we need to live in the HTML frames construction
code, add several new frame types, and get at them from XML.
-
Based on detailed analysis following the latest architecural/design decisions,
we have reversed an earlier decision and now plan to implement Treeviews
using tables. This will take about a third longer than the
equivalent widget implementation, so we have eliminated some minor features
to keep the schedule impact roughly the same, and allow us to still hit
our planned milestones.
Issues
-
Rod Spears is waiting on Tom Pixley's event propagation fix for
views, so he can check in ListBox and ComboBox.
-
Rod is also waiting on Tom's focus model in the event state manager so
he can get key events to his widgets.
People
-
Ramiro Estrugo is leaving XPToolkit, having accepted a position on the
Gecko team. We'll miss him, but it is clearly the right thing for the project,
so we wish him all the best. Thanks for giving us all Linux boxes
before you left!
-
Rod Spears has joined the XPToolkit team, coming from the Gecko team. Rod
did a lot of the early architectural work for the XPFE, and also brings
extensive knowledge of Gecko. We are looking forward to the boost this
will give our team.
-
Scott Collins is onsite at least through Feb 2.
Here's the latest on Grendel from
Jeff Galyan and the Grendel page:
Right now, we're using the Swing built-in JEditorPane/HTMLEditorKit
combo, which is doing an okay job for fairly simple layouts, but really
isn't so hot on real complex layouts (like the Netscape DevEdge newsletter,
for example). But it's a start. We do plan to do our own HTML, probably
either a direct port of nglayout, or by building Java hooks to XPCOM so
we can use nglayout without porting it. We haven't decided which yet.
So, we can open and parse local mail folders now, which is 1000% better
than where we were before (nice interface, but no message display
functionality to go with it). Next thing for me is to get the folder
tree to display, then get the ability to send/receive mail via a server
(both POP and IMAP), then I'm going to do some work with the addressbook
stuff.
furball is real close to having the xml menu building working as well,
after which, he's planning to move on to the xml dialog building. He
will probably do the majority of the HTML parser/displayer work, and
I'll jump in as needed, unless we decide to do a port of nglayout - that
will probably require both of us pretty much full-time. Again, we
haven't yet decided which option we're going to go with for that.
From the Grendel page:
Grendel has been cleaned up significantly from its original release state. These are the things that are currently working and
fully tested:
- The classic three-pane view of folders, message threads, and message body with message body display. The message
display needs work.
- A composition window.
- Reads local Berkely mbox style mail folders.
- Converts mail into formated HTML.
- A working MIME parser.
Keep an eye out for Grendel screenshots coming soon to mozillaZine.
Dan Veditz has this libreg update for us
There's been discussion about the need for a generic XP registry service
(which is what libreg provides), but as an XPCOM layer to break the link
dependencies. After discussions yesterday the tide seems to be leaning
toward implementing it using RDF rather than libreg. This would have
several advantages, such as interoperability with other parts of the
product that already grok RDF and the ease with which RDF can aggregate
multiple datastores.
This leaves the fate of libreg unknown. Possibly it will become another
data store that RDF knows about, and the two can be merged. For
compatibility with previous versions (and to forestall additional work)
I'd like SmartUpdate to continue using libreg.
Bill Law <law@netscape.com> is the stuckee for implementing nsIRegistry
(**moz**IRegistry?), though dp expressed some interest in it.
Dan Veditz also has the "software update" update for us:
We've given up on the MozillaSourceClassic branch. The services we
relied on were there, but the architecture is so different that it was
pretty pointless trying to get the Java-less softupdate working there
and then have to redo most of it anyway. The softupdt branch code has
been merged, but it's not part of the build and doesn't work at the
moment.
"libjar" porting has started -- that's the service that knows how to
read .JAR files and parse the manifest and signature files (uses zlib to
deal with the archive format). Up to now it hasn't been in the Mozilla
tree because of its use of security calls to validate the signatures.
For now we're leaving the signature-checking stuff out, and talking with
the security folks about how to provide that service in a way that won't
get us in legal trouble. libjar will also be required for signed
JavaScript, so this is a shared service.
At the same time we're changing SmartUpdate to accept unsigned installs
(with a BIG user warning) so it'll work in the security-less Mozilla
world. When the JS folks figure out how signed scripts will work in
Mozilla we can add signatures back in, but we'll keep the unsigned
option (with a way to turn them off, probably).
Vidur Apparao has the DOM update this week:
- I'm going through a pass to complete the Level 1 Core DOM - Attributes as
Nodes, the Node::CloneNode() method, Document:: and
Element::GetElementsByTagName(), etc. The hope is to get it complete by early
next week, so I can do a similar pass with the Level 1 HTML spec.
- Tom Pixley is slowly getting our JavaScript security story together,
interfacing with the capabilities library and putting in support for per-method
and per-property security checks.
Troy writes in with this update:
- Chris is working on scrolling table row group frames (tbody element).
- Kipp changed the flow of control for reflow commands. Now the style
system notifies the frame of inserted/removed/changed changes by
invoking a nsIFrame member function. Then the frame generates a reflow
command.
- I added support for CSS2 box 'offsets' (left/top/right/bottom). It's not
finished yet.
Daniel Nunes has this update for us from the Build/Release group:
- Build automation for nightlies on linux running more regularly
- Working to get builds contributed from outside for the non-linux,
win32, mac platforms.
A new mail/news overview page is online, with lots of info on where the project came from, and where it's headed.
Thanks to John Bandauer, the XPConnect runtime work is progressing. Reflection of methods and constants into JavaScript is now working. Simple calls from both
native code to JS and vice-versa are working. Hardcoded interface description information is being used until the typelib code is ready. The required
platform-specific code is only implemented for Win32 at this point and only some method parameter types are supported. Further information on XPConnect
technology can be found here.
Volodya has done a bunch of work on the JavaScript File I/O object, and has posted an
update of the File object spec.
Volodya is also an official owner of 'PerlConnect', a technology that allows JavaScript to directly interact with Perl objects.
Previous Updates
|