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