previous status updates
by Chris Nelson <chrisn@statecollege.com>
Last Updated Saturday, November 7th, 1998
Mike Pinkerton writes in with this update: "Trying to get up to speed on NGLayout and (ugh) COM. Fixing bugs in mac viewer and trying to make mac nglayout not suck."
Chris McAfee writes: XFE/Unix team is wrestling with the following issues:
Ramiro Estrugo writes:
Akkana Peck writes, "The Composer team is in design meetings, figuring out what work needs to be done to make a fully-fledged Composer in the NGLayout world. We will post our preliminary design documents for public comment, when they're ready (in a few weeks)."
Pam Nunn writes in with this update: Image Lib, while used in NGLayout branch, does not take advantage of all the new goodies. I'm focusing on changing the interface to PNG, so we can have some true alpha channel support via access to the new compositer. I'm betting many functions can be radically simplified. Several patches have been submitted that are on hold until the build environment is stable.
Troy writes:
Development continues on the JavaScript development branch (CVS tag: SpiderMonkey140_BRANCH). We are hoping to land a stable snapshot of this branch on the trunk early next week.
See all the recent check-ins to JavaScript.
Chris writes: On Monday, everyone who needs the old code (referred to hereafter as MozillaClassic) to finish feature work will be on a seperate code branch. On Tuesday, Raptor and "the new thing that will be Mozilla 5.0" will own the tip of the mozilla source tree. So on Tuesday I will be landing the XPCOM_BRANCH in mozilla/modules/libpref into the main trunk, simplifying the source pulls.
Tables: First cut at incremental table layout is done. We can append/insert/remove captions, colgroups, columns, rowgroups, rows, and cells. Not yet 100% optimized, but pretty efficient. Still some work to do to ensure that internal table state is always consistent. General:
JavaScript development continues on SpiderMonkey140_BRANCH. We hope to drop a stable release of this branch onto the tip in the first week of November.
See all the recent check-ins to the JavaScript interpreter.
Chris writes:
Brian writes:
Chuck writes, "The ldap sdk for C has been completely updated. Currently, all of the work is being done on a branch, LDAPCSDK_19981015_BRANCH. This branch has more 100 bug fixes, and several new features. The merge to the trunk should be in a couple days, new tar files will be produced once this happens. Any questions on this work should be sent to or to the newsgroup netscape.public.mozilla.directory
Steve Dagley writes in with this update:
Ramiro Estrugo has this update for us: ramiro:
slamm:
radha:
mcafee:
Srinivas writes:
Chris Blizzard writes, "Michael O'Reilly and Frank Visser have been working hard and there has been some progress. Fonts are working and pages look a lot better. Images are mostly rendering although there are still problems with transparent images we're still trying to nail down. Have a look at the updated screen shot."
Mike Shaver writes, "Perignon: more architectural work in place, now working on additional attribute support." What's "Perignon"? Read on... From Nisheeth Ranjan, we get this update: Layout:
If anybody reading this status report has feedback on this issue please post to the mozilla.general newsgroup. Mariner (page reflow) To Do List:
The big NGLayout items we'll be working on for the next few weeks include:
Some bug fixing over the past week includes:
Nisheeth writes, "The localization folk are working on making changes to HTML dialogs that will make them very simple to localize. Contact Rick Elliot <relliot@netscape.com> for more information.
Akkana Peck writes in with this Composer module update: "Ender multipart mime code has been checked in, under the ifdef MOZ_ENDER_MIME. Development continues on Ender and its associated mime routines. In other parts of Composer, bug fixing continues; in particular, we're working on getting table editing more solid and in changes to the publishing procedure to work with the single signon system."
Akkana Peck also has this update on the Mail Compose module: "SmartMail has been enabled by default in the builds. In the XFE, the MOZ_MAIL_COMPOSE AddressOutliner is the only class remaining which still uses the Outliner.cpp class. If the addressing area were rewritten, we could get rid of this class. Anyone interested in taking this on, writing an addressing system which uses shack widgets?"
Edwin has this update for us: " Over in libpref land we're beginning the process of putting the XPCOM interfaces into libpref, and porting the profile manager changes that went into 4.5 to the Mozilla codebase. You probably won't hear a lot from us for the next week or two, but your opinions on what we did right -- and wrong -- in 4.5 are always useful and welcome."
Mike writes, "Progress continues on libmocha; Steve Morse is using the multithreaded libmocha to do HTML permission dialogs, and there are bugs to be worked out there. Soon the 4.x bug merges will begin filtering in as well. I'm also doing work on stopping memory leakage in libmocha, which has been pervasive for far too long."
After two weeks of drum rolls, we've finally landed the merged JavaScript ref/src code. We're continuing primary development on the SpiderMonkey140_BRANCH and we'll try to make drops of known-stable JS engine code from the branch to the trunk as often as feasible.
-Scott
Frederick Roeber writes in with an update on the status of the Berkeley DB module. "The initial CVS import of Berkeley DB 2.4.14.1 from Sleepycat was done Wednesday evening. The repository directory is mozilla/db; though no module pulls it yet, it's there. It's been imported on the vendor branch; vendor tag SLEEPYCAT, release tag DB_2_4_14_1. Technically Sleepycat is module owner, but since they're still getting their CVS access going, I did the import for them. The next step will be integrating it with the build. I'd like to set it up so that one can either use an already-compiled version, or (if this is wanted) pull and build it as part of the mozilla build. After that, the mozilla-specific code (hooking in NSPR underneath, doing the initialisation, etc.) will be added elsewhere, probably mozilla/modules/db. I'll probably end up module owner of that for now."
Chris writes:
Warren Harris writes in with this lengthy update to the status of Open JVM Integration: Open JVM Integration (OJI)General OJI Development
LiveConnect (Java/JavaScript integration)
Java Security Architecture
Apple MRJ JVM Plugin Development
Microsoft JVM Plugin Development
Steve Dagley writes in with this update:
Chris writes:
Chris Blizzard writes, "I cleaned up a lot of the pixmap rendering code that Michael did originally so it was a bit more sane. Can people take a look at it and see if it works for them? It's a lot less code than it used to be. The Region* code that's in there is very hackish and needs to be cleaned up. I'm still not fully aware of all of the issues involved so I'm going to do some more research on it." Chris wanted me to mention that Michael O'Reilly <michael@metal.iinet.net.au> had done most of the work on this code, and his work was mostly just cleanup.
Before any of the technical updates, the big news on the NGLayout front is the advent of nightly builds available at ftp.mozilla.org! Go to the binaries section to access all the mozilla.org builds - just be sure to read the warnings! Rick Gessner has the first of two updates for NGLayout:
Troy Chevalier sent a note with some updates on the work of specific programmers: Steve is working on table incremental reflow: Incremental Reflow for nsTableOuterFrame. This supports optimized incremental reflow for these cases:
Kipp has been doing various things, including fixing floaters bugs and more top/bottom margin work. I finished up separating the reflow protocol out of nsIFrame, and now I'm working on reviving the scroll frame code.
Akkana Peck writes in with this Composer module update: " We have been continuing to work primarily on bugs, making Composer more useable, friendly, and better at 'good HTML'. In Windows, we implemented improvements in Publishing (including remembering your username and password as part of the app-wide 'Single Signon' system); this will follow shortly on other platforms."
Akkana Peck has this update on the Mail Compose module: "Multipart mime is being rewritten to make it usable by Ender (the embedded composer). We hope to have some demos in a week or two. SmartMail has been turned on by default and is making progress on Unix."
Last week I wrote about the numerous changes that we were making to the directory structure of the JavaScript interpreter source. We had planned to "land" these changes on the trunk this week. Our testing indicated that we were not quite stable enough to drop the latest JavaScript engine into mozilla yet. (Our goal is absolutely no regressions!) Look for these changes to appear early in the week of October 12th.
Two updates, one from Sarah Broadwell, and one from Chris Yeh. Sarah writes, "Chris Yeh deleted a bunch more NSPR20 ifdefs getting closer and closer to having it be unnecessary to have it defined. He did successfully delete the LIBMOCHA ifdefs, so defining that is no longer necessary. (these have both been defined on for at least a year, the were never going to be turn-off-able, so no need to keep them around.) We had some excitement in gromit land with a NSPR3.0/security incompatibility, but that doesn't appear to have affected mozilla. NSPR30 has been in Mozilla for almost 2 weeks now with no ill effect to Mozilla." Chris writes, " Removed old MOCHA #ifdefs from the Mozilla tree. For a sense of history, the MOCHA #ifdefs were placed into the client back when Brendan Eich was developing JavaScript over two years ago. Since the odds of going back to a JavaScript-less browser were somewhere near zero, I took the liberty of cleaning out old unused code. The same thing is occurring with the NSPR20 and NSPR #ifdefs. I'm in the process of removing all of these from the mozilla tree. They should all be gone in a week or so. The reason why I'm doing this is to give me something to do in my spare time, and make the build configuration a little easier."
From Chris Waterson:
The big news on the WinFE front is the configurable chrome spec, which was placed on mozilla.org this week. The configurable chrome spec is an impressive feat that I encourage you all to take a look at. You can find a summary of the news at mozillaZine, as well as some screenshots and a sample chrome layout created by Jason Kersey <kerz@en.com>, the MozBin admin.
Mike Pinkerton writes in with this update: "On Mac, Pro4 landed across mozilla and NGLayout. We're working feverishly on the configurable toolbars and we hope to land ColorSync in the next week or so."
Chris McAfee writes: XFE status:
Gagan Saksena writes in with the NetLib update: "I have been working off late on a new cache (NuCache) architecture that I plan on enabling for the rest of the developers on mozilla next week. This new architecture is modular and allows for dynamic addition of "cache modules" or mini-caches. I will also be publishing out a document that describes in detail the architecture, the changes and the API for using the new cache. There will also be a mini-FAQ on the NuCache. How will it affect users? Well, they should see better performance, there are changes which should make the general performance go up. For example, the older architecture cleaned the cache to make space for a new object when the user would click on a link. In the new architecture, the cache gets cleaned in a background thread and hence the user doesn't see maintenance work on the primary thread. There are other miscellaneous improvements too."
Pam Nunn writes in with this update:
Warwick writes in to say, "The qtfe module should appear real soon now."
Adam writes in with this update on the status of the ActiveX wrapper for Mozilla's layout engine, which will allow it to be plugged into situations where IE's ActiveX layout control is currently pluggable. "Currently it's working quite well, implementing most of the functionality of the IE control. I have outgoing events working as well and have written some test apps in VB and VC++. Due to CVS check in/out problems, the most recent changes are still here: http://www.iol.ie/~locka/mozilla/mozilla.htm "
Troy Chevalier sent a note with some updates on the work of specific programmers: Kipp:
Steve:
Troy:
A huge JavaScript update from Scott Furman! We're making some significant changes in the organization of the directories containing the JavaScript engine and the JavaScript code itself. If you're not actually working on the JS engine code, you don't need to do anything new - just download and build mozilla as usual. Let me say that again, a little louder: YOU CAN IGNORE THIS MESSAGE UNLESS YOU WANT TO WORK ON DEVELOPING THE JAVASCRIPT INTERPRETER CODE. Here's a summary of the changes we're making:
We expect to "land" the merged source around October 6th, so you should be prepared to pull new source then. Merging of js/ref and js/src For historical reasons, there were two variants of the JavaScript engine code, one in the mozilla/js/ref directory and the other in mozilla/js/src. The code in ref was only used to build the standalone JavaScript engine, aka "JSRef". The code in src, which was automatically generated from ref, was used to build the JS engine in the browser. (Internally, we also use this engine in Netscape server products.) The differences between the ref and src engines were limited to simple changes in the naming of types, functions and header files. (For the curious, the reason that we ended up with two JS directories is that the older ref directory was designed to build with an earlier version of NSPR, whereas the newer src directory was designed to link with NSPR2.) It had become something of a chore to keep the ref and src directories in sync. There was always someone checking into one directory but not the other. So, we decided to make it possible to build both the standalone JS engine and the browser JS engine from the identical sources. The resulting code now lives in the mozilla/js/src directory. (The mozilla/js/ref directory is no longer needed and will be removed shortly.) NSPR dependency removed At the same time that we performed the transformation to merge the JavaScript ref and src directories, we eliminated most of the dependencies that the JS engine had on NSPR. This decision complicated the merge somewhat, but the change allowed us to build a minimal standalone JS engine without sucking in numerous unnecessary libraries and it will also help to shield us from future incompatible NSPR changes. The less fortunate result of this decision is that numerous types, macros and function names had to be changed to avoid colliding with their NSPR counterparts, i.e. to handle the case when NSPR header files and JS header files are mixed. This resulted in large deltas to the source code. The only remaining dependencies that JS has on NSPR are for threading-related primitives, e.g. PR_Lock(), PR_Unlock(), etc. The single-threaded JS engine has no dependency on NSPR at all. Primary development of JavaScript engine moves to a branch Try as we might to avoid it, those of us working on the JavaScript engine sometimes break the mozilla build or introduce insidious regressions in JavaScript behavior. We're at the beginning stages of an ambitious plan to insulate most mozilla developers from the bleeding-edge JavaScript engine changes, but still allow them to be exposed to relatively fresh code. The basic idea is to isolate primary development on a CVS branch and then periodically "drop" the branch onto the trunk. (See this FAQ if you're not familiar with CVS branches.) The drops will only be done after we develop some degree of confidence in the code, i.e. by doing test builds and by running automated tests on the standalone JS engine.. Initially, we hope to perform drops at least once a week, so the code in the browser will never be more than a week behind the code that's being developed. Our first drop will probably take place around October 6th. If you aren't going to be working on JavaScript engine development, you don't need to change anything about the way that you check out and build mozilla code. However, if you want to develop with the very latest code, you need to check out the JavaScript development branch: If you would like to use the JS engine, but only with comparitively stable versions of JavaScript, don't use the development branch; use the trunk version, i.e. cvs co -A mozilla/js/src However, if you want to develop with the very latest JS engine, you'll need to check out the JavaScript development branch: cvs co -rSpiderMonkey140_BRANCH mozilla/js/src or if you already have a JS tree checked out cd mozilla/js/src; cvs up -rSpiderMonkey140_BRANCH (For the curious, SpiderMonkey is the internal code name that we use for the JavaScript engine written in C.)
From Bill Law:
From David Hyatt: "Several bugs in Aurora were fixed this week. The HTML pane that can be embedded in Aurora tree views has been fully implemented. Improvements and fixes were also made to the configurable toolbars."
Mike Pinkerton writes in with this update: "On MacFE we have both mozilla and NGLayout building and running with CodeWarrior Pro4. These changes should land Tuesday. Kudos go to the MacNGLayout team, as they now have it up and running to the point where it lays out web pages (still problems, but hey, it's coming along fast!) " Steve Dagley writes, "MacFE conversion to build under CodeWarrior Pro4 almost complete - should land next week."
Chris McAfee writes: XFE status:
Ramiro writes in with some good news on the Qt front: "Yes, it's true...Finally, QtMozilla is in the mozilla.org cvs repository. It builds, links and runs. It makes my x server bomb, but thats a minor detail at this point. There are a 'few' problems, mostly because of hacks in the XFE. We can now begin to find XP solutions that work with all 3 unix FEs."
Akkana Peck writes in with this Composer module update: "Embedded editors in Unix now have attached toolbars, and some bugs relating to toolbars have been fixed. Mac Ender pretty much works now, and pretty much looks like it's going to look. We're making progress adding multipart mime handing to embedded composer areas. Bug fixes in the new table editing continue as we try to make the new functionality more solid; look for lots of bug fixes soon, especially in the backend and the XFE." To read more about the state of Composer, check out mozillaZine.
Akkana Peck also has another module update for us: "We tried to turn on MOZ_MAIL_COMPOSE by default, but there were some glitches involving files used in the internal build. Most of those have been fixed; expect to see mail compose turned on by default for Unix any day now. Win32 work on multipart MIME in the embedded editor is progressing nicely, and should appear soon, which will also mean turning on MOZ_MAIL_COMPOSE on Windows. No one has signed up to write a mail compose window, though, so the embedded editor will be the only UI unless someone volunteers. We are in great need of help getting this feature tested and implemented on the Mac -- please contact us if you're interested in helping."
From Rick Gessner, we have this info: A great deal has changed in NGLayout:
Troy Chevalier sent a note with some updates on the work of specific programmers: Kipp:
Troy:
Steve:
Here's more detail on the Mac NGLayout progress that Done Cone submitted to the checkin newsgroup: "You can now break out your macs and see Raptor -- LAYOUT Raptor Mac now builds(again) and lays out.
Mike writes, "The multithreaded libmocha changes are landing today at 1:00, which will be good. =) I will be gone next week, but after that I will be integrating 4.x bug fixes into the Mozilla code."
Robert Churchill writes in, "We're finishing up reflection of Shack objects (implementations of the HyperTree layer above RDF) into JavaScript. This will enable JavaScript to reference any Shack object embedded in a HTML page and obtain its contents and properties (such as whether a node is selected, enabled, etc)."
Dan Veditz writes in, "Looked into converting the Netscape registry into an RDF datasource. The changes required look too extensive to consider for 5.0, especially given how far behind we are on SmartUpdate. We'll merge over the changes from 4.5 and leave it at that until a later time."
Dan Veditz also writes in with the SmartUpdate update: "Progress on design of new UI flow. 4.5 still sucking up time from the team. Not much progress to show until we complete the conversion of all the Java code into C -- it's not usable until that part is finished."
Brian Ostrom writes, "Last weekend's builds (MOZ_LITE only) broke all over the place. I cleaned up what I could and checked in a few minor tweaks. MOZ_LITE builds should be better off now. Thanks to Zoltan Varga (zvarga@gw.cdk.bme.hu) for pointing me at a gcc 2.8.1 distribution (no source, unfortunately...) for QNX. It seems to be working properly, and that port is starting to look vaguely hopeful."
The WinFE is fixing bugs and wrapping up 5.0 features. We're working on configurable chrome and on the Aurora tree widget... improving the behavior of both and doing usability testing of different behaviors and looks for the toolbars and trees.
Mike Pinkerton writes in with this update: "We are in the process of upgrading the mac to build with CodeWarrior Pro4 (available next week) and getting more appearance manager support (and MacOS8 support) into MacMozilla. We also rebuilt the strings library so that we get rid of N-thousand 'STR ' resources."
Nisheeth writes in with a quick update: "Eric Pollmann is working with Mike Shaver to make layout get style information from the new DOM tree and solve a bunch of style inheritance bugs."
Mike writes, "Checkin of multithreaded libmocha was delayed by Mac issues, which are still being resolved... also, the JavaScript console may also be getting merged in from 4.x soon."
Eric Bina and JG posted some info about HTTP compression at http://www.mozilla.org/projects/apache/gzip. They are urging people to get the latest version of Apache and start playing around with Mozilla's HTTP compression stuff. Internally, we've seen some monster improvement over low-bandwidth lines: it'd be cool if we could confirm this in the real world. There is a first cut at a "smooth progress bar" implementation on PROGRESS_19980909_BRANCH if people want to pull it, build it, and check it out (or just take a look at the source and code review it). I hope to land this in the trunk next week or so. I pushed some information about "runtime performance tracing" in Mozilla at http://www.mozilla.org/performance/runtime-tracing.html. Talks about how to gather statistics about what Mozilla spends it's time doing (at the "application level" rather than like what a profiler might collect).
Pam Nunn writes in with this update:
Warren writes, "The project is nearing completion. We're continuing to work closely with folks from JavaSoft and Apple to resolve the remaining issues involving the integration of JavaScript security with the Java security architecture. We're also negotiating with several Unix vendors to integrate their JVM implementations with the browser via OJI."
Edwin writes in, " On the libpref front, we've been doing a lot of planning to bring the 4.5 preference and profile manager features to the 5.0 world. We're not done with that planning yet, but we should know more in the next week or so."
Brian Ostrom writes, "I'll be doing the first complete set of UNIX mozilla builds this weekend, so I'll be able to address current build/config problems very soon. Added support for OpenBSD, ARM Linux, and initial/incomplete support for QNX (_really_ need to get gcc for QNX; if anybody has info wrt this, please have them let me know)."
The localization team is figuring out how to make HTML dialogs more localizable. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The code behind the mysterious new "Desktop" preferences pane will be checked in any moment now and should be there by the time your readers will see this. This feature should give users much better control over how Mozilla integrates with the Windows desktop, including: - Selectively choosing what protocols/filetypes Mozilla handles. - Ability to turn off "integration" features via Edit->Preferences. - Integration of desktop features (e.g., Typing in the "Address Toolbar" will utilize internet keyword lookup). - Some features even work with Internet Explorer.
Akkana Peck from the XFE team writes, "I checked in mail compose code for Mozilla a few days ago (posted an announcement to n.p.m.mail-news). The front end is only implemented on X (based on a subset of the old Messenger code, as is the backend); I'm hoping that developers on other platforms will be inspired to resurrect their mail compose front ends as well, or hook it up to SmartMail. setenv MOZ_MAIL_COMPOSE 1 to turn it on in the build."
From the "nglayout: what's new" page, some summarized bits:
Mike writes, "Libmocha is going to get multithreading sometime within the next week or two; the changes are on a branch waiting to land. There's a brief description at http://www.mozilla.org/classic/libmdesc.html and I intend to publish a more involved description soon."
From the Netscape for Rhapsody Project page: Where we are now:
|
||||||||||||||||||||||||||||||