Despite a great deal of progress on several fronts, we still haven't quite
managed get enough infrastructure in place and documented to unblock most
application developers. We will continue with more brown bags and workshops
to get the how-to info out ASAP. Unblocking app developers so they
can make their dogfood milestones is our top priority. Please keep me updated
about your priorities for what we should be doing.
Implemented the XUL Content Sink.
Wrote XUL &
RDF: The Implementation of the AOM.
Implemented multiple selection and 50% of keyboard navigation in the tree
Got menu commands working on MacOS, couldn't actually get to turn them
on... (they are checked in now, but commented out)
Tested and checked in Progress meter widget.
Converted the form button to use a frame instead of a native widget and
got it to come up. Unfortunately it is completely black (Appears to be
some style problem).
Finished porting most of the unit tests to Unix.
Spent several person-days dousing flaming trees, few or none of which were
ignited by XPToolkit checkins.
Worked with the build team on Unix tests/tinderbox plan.
Got the initial AppCore infrastructure working.
Created a simple "mail" AppCore demo.
Prototyped Modal dialogs.
Prototyped Username/Password dialog displaying from a page load notification
from inside an AppCore.
Perhaps more of a realization, but the file picker widget is a misnomer.
The actual widget/frame is nsFileControlFrame which encloses a text field
and button. The latter will become an HTML 4 button while the former
will remain a native text widget for Gecko 1.0. The file picker widget
itself just is the interface to bring up a platform specific file browser.
Killed the Group Box widget in favor of just using the HTML 4 LEGEND tag.
Toolbars are still blocked on 2 things from layout:
frame-reflow and min/max width attributes.
XUL dialogs currently look like they will initially be slooowwwwww coming
up. It seems to take a while for Gecko to decide it's finished with
a window's layout. The window finalization code, for instance, doesn't
fire until the URL is finished loading. Apparently some timers are ticking
down, because this takes a couple of seconds even for an URL that references
nothing from the net. In summary, XUL dialogs and alerts will take
a couple of seconds to materialize. Needs looking into. Any ideas?
Several XPToolkit engineers are still spending way too much time
having to argue with people about certain issues that we thought were dead
snakes weeks ago. We need a 'statute of limitations' about how long after
a decision people can still raise objections, or a project wide architect
who can make final calls on these sensitive issues. We are trying to conduct
all of our business in full view of the world, so there is no excuse for
continued private objections or attempts to reverse decisions weeks after
Unix client keeps fading in-and-out of building, making it hard to
focus on XP work. Our lone Unix guru (the famous Chris McAfee) is still
spending nearly 100% of his time keeping things building and running properly.
We desperately need to free him up for new development.
Solaris/Purify doesn't understand egcs/dlopen(). Anyone have any
Hit the 'simple browsing' milestone with XUL loader functional on all platforms,
plus several bonuses: menus displaying, toolbars working (minus XUL buttons),
and the first appearance of XUL trees.
Fixed/implemented about half of the Unix unit tests all over the tree.
Sucessfully built a Solaris/purify build, although it crashes on startup.
Got the XULCommand infrastructure started, loading and installing commands.
Got the toolbox laying out toolbars.
Put toolbox and toolbars into apprunner.
Got grippies drawing and doing rollover feedback on toolbox.
Got grippies, toolbars, and toolbox to draw themselves using CSS so they
are totally custom.
Implemented the tree frame construction code and got it displaying.
Implemented indentation, icons, expanding/collapsing, and single selection
in the tree view.
Finished review of NSPR 2.0 time code and checked in the Mac build of the
NSPR 2.0 timetest test applet.
Posted final draft of the Architectural
Object Model spec.
Held three well-attended brown bags on XPToolkit architecture, XUL and
command/event model. This is a good way to keep everyone informed,
and the feedback/discussions help to solidify the content. I think we should
all be doing these regularly.
Held a Widget Workshop to help jumpstart engineers on XPToolkit, XPApps
and Ender who are or will be building XP Widgets. We'll have more
of these for a wider audience as the first set of widgets get built.
Like everyone else, we have a big issue with having only a single, non-reentrant
UI thread. This will be tackled in the coming week.
Stuart Parmenter has this to say about the GTK work:
"gtk mozilla is working pretty nicely and should be perfect by sometime next
Daniel Nunes has this update for us from the Build/Release group:
- nightly binaries for mac are more dependably produced now.
- a 'last-built' directory has been added to
to retain older builds on platforms we can't get builds for nightly,
or in case platforms fail on a given day.
Chris Yeh has news about an addition to CVS:
There is a new top-level directory in mozilla, and a new Mozilla partition!
The partition is the Mozilla Tools partition. This partition exists (and I
quote shaver) as the place in the mozilla tree for...
"Tools useful to people developing or compiling Mozilla, but which aren't
part of the build process or runtime."
Translated, this is where our tinderbox scripts, qa quick smoketests, build
scripts and environment batch files go. It's a repository of small tools
that people have developed along the way to help them hack on mozilla.
Checkin access is initially restricted, but anyone can join by offering up
a cool script, hack or tool.
The first directories there are:
If you're interested in contributing or maintaining a cool little tool,
just mail the owners of this partition, email@example.com and
First, Scott MacGregor has news regarding the networking aspect of the Mail client:
We've made some good progress this past week. We have successfully
rebuilt our POP3 and NNTP protocol modules in the mozilla world using
the new netlib model. They are now online. We've also written the
foundation for a text based test harness which allows you to test just
the protocol module without any dependencies on the rest of the mail
application. We are looking to integrate this test harness into the java
Next, from Phil Peterson, we have news on the Mail/News client itself:
As usual, design discussions are happening in the mail-news
newsgroup, and code is getting checked in to /mozilla/mailnews.
are running in a Windows/Linux command line testbed. This code is running
on the app thread, and using a proxied stream to communicate with the netlib
thread. Coming soon:
SMTP coming by Monday.
can be run from the JS consule inside the actual app. Hopefully using XPConnect.
We have a demo three pane UI up using an HTML frameset, which has as its
contents some XML documents with fake data for the folder pane and thread
pane, which are new tree widgets.
Starting work on mail composition. Porting back-end code from 4.x, met
with the Ender team
MORK implementation of MDB
expected to be running in a week
Progress on MsgDB,
the summary-file and address-book layer above the MDB API.
The RDF data sources are coming
along. Local mail folder list was built and shown in new tree control.
Design decision made on views and message threading: we're going to put
the smarts for Messenger views and message threading into RDF data sources,
and not build a query facility into RDF. Not the cleanest thing, but we
think it'll work.
Work begins this week on porting the old code for parsing Berkeley mail
folders and displaying messages.
UI spec for the sidebar is coming along, as are discussions on new features.
Since we're concentrating on the Dogfood release, new features are on the
Met with browser mgrs to confirm that browser without mail is a required
config, as is mail without browser, and hammer out some details on how
to do that.
We're worried about the threading
problem, just like everyone else. Execution threads, not message threads
|Warpzilla (OS/2 Port of Mozilla)
|Submitted by Henry Sobotka <firstname.lastname@example.org>
Henry Sobotka has news this week on the port of Mozilla to OS/2:
SuperJohn Fairhurst (email@example.com) got apprunner up and running on
OS/2 last weekend and posted a screenshot at
http://thor.cam.ac.uk/~mjf35/apprunner.gif. He also provided code ("a
first stab" in his words) for the os2 subdirectory in /intl, so
Warpzilla remains in sync with the tip.
Our plan is first to check in our build as a branch, then focus on
landing it. To keep things simple, we've frozen the cvs tree on joyce
that Joan Touzet (firstname.lastname@example.org) was kind enough to set up
for us while its diffs get folded into the mozilla-tagged working
directory we're using to create the branch.
The diffs include support for an autoconfed VAC++ build, which uses the
same compiler commandline format as MSVC's cl, so to cut down on
conditionals I'm setting up a shared path wherever possible. That means
progress towards the merger is intertwined with work on setting up an
autoconfed Win32 build.
The MSVC build with gmake, cygwin utilities and configure-generated
makefiles is well underway. The process runs smoothly off a vanilla DOS
prompt and what remains to be done is mostly routine, namely putting
MSVC blocks where necessary into the Makefile.ins, then rolling the
tweaks from the static configure.msvc and autoconf.mk I've been using up
into the .in files.
Free (gcc) Win32 build
Brian Ryner (email@example.com) took a stab at a cygwin build of NSPR.
While it built, the tests crashed and we soon concluded cygwin isn't
quite yet ready for primetime moz. He also tried a mingw32 build but
discovered "just compiling nsinstall is problematic".
Meanwhile I had somewhat better luck with rsxnt
Win32 offshoot of the emx+gcc toolkit we use for Warpzilla. Using it and
the cygwin tools, I got an NSPR build which also proved far cleaner
(more warning-free) than with cygwin. The dlls weren't initializing
properly, but eventually I hit a formula that works with a small test
app, and now has to be tried with NSPR.
As cygwin gcc sailed through autoconf and configure until hitting the
tests for NSPR, rsxnt should do equally well and, with a functioning
NSPR, spawn a makefile tree. But with a question mark still dangling
over the feasibility of this build, it's being treated as a separate
project with no bearing on wrapping up the MSVC autoconfiscation and
Pam Nunn writes in with this update:
The image lib is being COMitized. Each image file format will be a
and if the trick is done correctly we should be able to add new formats
quickly and easily. This is all in process. No code has checked in yet.
The api to the format decoders is still changing, but I will post it as
as it gels.
Folks who have PNG issues and are building on linux should take
a close look at which PNG library is actually used in the link. The
autoconf test makes the assumption you always want the latest and
greatest library, which may not be the case.
Chris Waterson writes in with this RDF update:
Got XUL-to-RDF-to-XUL working, modulo some issues with HTML tags embedded
inside the XUL. This will allow us to do the downloadable chrome stuff
that we were seeing in the "old" 5.0.
Started working on making RDF's core data sources thread safe.
Started working on simple sorting implementation.
Discussion about "RDF connect", an idea that Warren had about building
RDF data sources directly from XPCOM type libraries
Troy writes in with this update:
- Landed rewrite of inline frame code that uses anonymous blocks to
manage block children.
- Build improvements and misc bug fixes for linux.
- Working on automated regression testing.
Kipp's now a full-time Linux developer.
- added support for fixed positioning (see test 11 and test 12, in the
- implemented correct bahavior for IMG elements: now if we can't render
the image, then we display the alternate text inline
|Grendel (Java Mail/News client)
|Submitted by Giao Nguyen <firstname.lastname@example.org>
Giao has this update for us:
Testing was done for IMAP, POP3, and NNTP. IMAP, as demonstrated last
week, worked flawlessly. POP3 worked too but "slow" was the magic
word. NNTP is seeing some minor problems. Edwin is looking into it. We
haven't done anything with SMTP yet.
Addressbook code has been commited but not yet tested.
The dialog building code is moving along. Grendel will have dialogs
which means you can do settings without having to hack the preference
file. This moves us closer to that usable state.
We've commited to transitioning the code to be compilable and runnable
on Java 1.1 and Java 2 based systems.
We are so close I can almost taste it ...
|XPInstall (Software Update)
|Submitted by Dougt@netscape.com <email@example.com>
Doug Turner also has the "software update" update for us:
I have made the initial checkin of XPInstall into Seamonkey. It resides
in the source tree at mozilla/xpinstall. XPInstall is the new
engineering name for SoftUpdate/SmartUpdate.
Here's Akkana's update on the status of the editor (composer):
Work continues on selection (extending selections via the keyboard),
basic type-in (pretty much working now), transaction batching, specs
for editor dialogs, and a spec for the basic editor interface class.
See the editor web site (http://www.mozilla.org/editor/) or the editor
newsgroup/mailing list for more details.