Mozilla

• Roadmap
• Projects
• Coding
  • Module Owners
  • Hacking
  • Get the Source
  • Build It
• Testing
  • Releases
  • Nightly Builds
  • Report A Problem
• Tools
  • Bugzilla
  • Tinderbox
  • Bonsai
  • LXR
• FAQs

Module Updates XPToolkit January 16th Submitted by Peter Trudelle <trudelle@netscape.com> 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. Grendel January 15th Submitted by Jeff Galyan <talisman@anamorphic.com> 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. Libreg January 15th Submitted by Dan Veditz <dveditz@netscape.com> 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.   Software Update January 15th Submitted by Dan Veditz <dveditz@netscape.com> 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).   DOM January 15th Submitted by Vidur Apparao <vidur@netscape.com> 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. NGLayout January 15th Submitted by Troy Chevalier <troy@netscape.com> 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.   Build/Release January 8th Submitted by Daniel Nunes <leaf@mozilla.org> 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. Mail/News January 15th Submitted by Phil Peterson <phil@netscape.com> A new mail/news overview page is online, with lots of info on where the project came from, and where it's headed.   Javascript January 15th Submitted by Scott Furman <fur@netscape.com> 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