|
There has been a lot of behind the scenes reshuffling at the Mozilla Project this week. Because of this, a number of the module names no longer apply; I used the old names this week. There should be new module names next week, and we should have more to report on the restructuring as the pieces fall into place.
RDF and HT (HyperTree)
|
November 6th
|
| Submitted by Robert Churchill <rjc@netscape.com> |
Robert Churchill has this RDF update for us, with some news about the restructuring:
- Chris Waterson has joined the RDF group! He's done some very
interesting work in the past such as Java prototypes, and building a
thin news client on top of RDF using the old Shack widget. We're
excited to have him working with us.
- We're looking at completing the XPCom work on RDF's APIs in short
order for Raptor. In parallel, we're currently having discussions
regarding RDF presentation in Raptor and the options available to us.
We hope to achieve consensus over the next few days on which of the
paths is the best to take; options include:
- removing the HyperTree layer, and putting a new, thin layer on top
of RDF that speaks XML+CSS to Raptor.
- keeping the HyperTree layer, and having raptor's toolbar and table
components use it
We're looking over our lists of tasks and prioritizing them. More
information next week when we know more.
"
Dave Hyatt writes, "Some people from the WinFE, MacFE, and XFE teams have become the XPFE
team. Others have moved to the XP Apps/OS Integration team. We just
found out the new organization recently, so that's about all there is to
report. :)"
And Bill Law writes, "We're in an awkward state right now. We've just reorganized to
implement the new product "roadmap" and the old module definitions don't
necessarily make sense any more. Specifically, there really isn't a
"WinFE" anymore.
Bear with us for another week or so. Then we should have a clearer idea
of where we're heading and what our status is."
My group has yet to really get down to the nitty gritty, but our
goal is to provide an infrastructure for people on the web to leverage
skills they know (XML, CSS, XSL, HTML, JavaScript) to build a Navigator,
both UI and logic.
We need the help of the net to fulfill our dream and once we get settled
with our new manager we will be opening up all our discussions to the
net. Expect to see a lot of traffic in the next few weeks as we start
work. It should be exciting (we're all very excited) and we hope we can
impart that upon net developers as well.
On a side note, xpviewer builds and runs on Mac, but drawing is messed
up because of the discrepancies between the parent/child window models
on mac and win/unix. This will be fixed shortly, but it does build and run!
Chris McAfee has a status update on the general Unix status of the transition:
- xpviewer links and runs for awhile on Linux, Solaris
is close behind.
- mozilla/client.mk checked in, this should now be an
easy way to pull the source code. Comments in this
file have usage examples.
- I heard that the GTK people got the viewer app to
bring up a window; GTK has bolted out of the gate
so far. Go GTK! (read below for more)
Mike Shaver writes in with a GTK specific update:
- viewer builds and links and pops up a window
- working on getting the rest of the widgets all happy, and then we'll
start working on the gfx layer
- hope to move to xpviewer stuff shortly, but for now we're using
widget/tests/viewer as our test vehicle
-
JavaScript 1.4 Release 1 is officially born. It is now built as part
of the browser (the SpiderMonkey140_BRANCH code was merged into the trunk).
JS 1.4 implements some proposed features of the upcoming
ECMA-2 standard, such as exceptions, and the 'in' and 'instanceof'
operators. JS 1.4 also features localizable error strings.
With the release of JS1.4, we've added a new CVS branch. Work on
JS1.5 has just begun on SpiderMonkeyDev_BRANCH. As before, JS 1.4
bug fixes will be made on the SpiderMonkey140_BRANCH (for future maintenance
releases of JS1.4)
-
Chris Cooper has done some final
tweaking
of LiveConnect exceptions in order to permit primitive values like
numbers and booleans to be thrown from JavaScript to Java.
-
Mike Shaver, Chris
Cooper and Bjorn Carlson are
beginning work on COMconnect, a technology that will allow JavaScript to
manipulate external software components that expose XPCOM interfaces.
(We expect more docs on
COMconnect to be available later in the week.)
See all
the recent checkins to JavaScript 1.4.
See all
the recent checkins to JavaScript 1.5.
Tables:
style changed incremental reflow, and a variety of layout bug fixes
Core Layout:
simple page sequence frame which we use when paginated. Print
preview window is starting to limp along
Neat New Stuff:
CSS first-line pseudo element support
Here's Akkana's update on the status of the editor (composer) through the transition:
Our current plan is to use the xpviewer as the basis for our editor
test bed. In between design meetings, we've been working on getting
the xpviewer built and running on our various platforms to test the
feasibility of this idea.
We have a new page on mozilla.org,
http://www.mozilla.org/editor/
where we will be posting our design spec documents as they become
available.
We also have a new mozilla newsgroup, netscape.public.mozilla.editor,
gatewayed to the mailing list mozilla-editor.
Dan Veditz writes in with the SmartUpdate update:
"4.5 shipping code merged into the Mozilla tree.
"For now SmartUpdate development will go onto the
MozillaSourceClassic_19981026_BRANCH since it relies on too much
infrastructure which is not yet available in the new world order.
Once we have it resurrected in the Java-less world we'll work on
COM-ifying it."
Pam Nunn writes in with this update:
NGLayout will let us simplify the ImageLib code
significantly. I am currently evaluating where I can
streamline the interface functions. Since gfx gives us
compositor access, true cross platform alpha channel
support is high on the list.
Previous Updates
|
