Highlights
Lowlights
Accomplishments
- Resolved 54 bugs in the last week (nearly half by Hyatt alone!),
see our Bug
List for details.
- Drag & Drop on Toolbars: added support for new elements
toolbars and frames, got item frames to initiate drags, process
drops and do drop feedback between toolbar items. Remaining work:
Test on all platforms once D&D is fully functioning on all
platforms. (rods, mcafee)
- Clipboard: Image support is done on Windows, and streams for
large data sets is done XP and works on Win32, just needs verification
and testing on other platforms before checkin. (rods)
- Removed all "kIxxxxIID" and replaced them with nsCOMTypeInfo<xxxx>::GetIID()"
for the xpwidgets and Windows directories (this needs to be done
for Mac and Linux src directories)
- Made sure all the interfaces in widget/public use the macro:
NS_DEFINE_STATIC_IID_ACCESSOR(xxx) NOTE: The two previous
bullets has required me to touch a lot of files in xpwidgets and
windows directories. I have appended a cvs update log to give
everyone an idea what has changed.
- Updated xul popup docs for tooltips: http://www.mozilla.org/xpfe/xptoolkit/popups.html.
(pinkerton)
- Added generic mechanism for easily adding tooltips to items.
(pinkerton)
- Added a way to cancel creation of xul popups and tooltips
from JS. (pinkerton)
- Menu accelerators on Win32 (saari)
- Fixed 14 interface classes that didn't supply |GetIID()|,
which causes bad type bugs almost everywhere they are used. Checked
in code that prevents us from making that mistake again. (scc)
- Checked in code that eliminates our `ambiguous |nsISupports::GetIID()|'
problem, which allows to eliminate instances of |NS_DEFINE_IID|,
saving 16 bytes per. (scc)
- Expanded debug tests in pointer assignments to catch missed
QIs. (scc)
- Documented the above items on xpcom newsgroup at <news://news.mozilla.org/scc-2906991925330001@scc-east.mcom.com>
<news://news.mozilla.org/scc-2906991932310001@scc-east.mcom.com>
and reminded everyone to use |CallQueryInterface| in the post
<news://news.mozilla.org/scc-2906991938070001@scc-east.mcom.com>
Priorities
- Handle effects of Necko landing (hyatt, mcafee, danm)
- Helping with testing of large dataset clipboard support on
Mac & Linux. (rods)
- Finish toolbar/toolbox D&D verification and testing, and
check it all in. (rods)
- Window OS borders and chrome. (danm)
- Help jud with Necko on Mac, need to hook up Internet Config
for MIME mapping. (sdagley)
- Carpool in appcore changes. (scc)
- Profile the app and identify the three biggest performance
problem areas; post the data and a plan to fix it. (scc)
- Work with Warren on rationalized service manager issues. (scc)
- Work with XP apps more on getting their dialogs working. (evaughan)
- Finish splitter. (evaughan)
- Work on making boxes very solid to support xpapps work. .
(evaughan)
- Possibly work on GFX rendered scrollbars in HTML. . (evaughan)
- Continue to work to make the app something to be proud of.
(hyatt)
- Help with the creation of XUL files and make everything look
good. (hyatt)
Decisions
Issues
- Embedding APIs: XPToolkit neither embeds Gecko, nor
is used by any apps that embed Gecko, nor is it itself embeddable.
However, we are somehow becoming the owners for a number of embedding
tasks and issues. We need to better understand where these fit
in priority, and how they will affect the XPToolkit work that
is our primary goal.
- Mac dynamic menus: Apple sez: "Unfortunately, we are not going
to export the new event functionality from the Sonata version
of CarbonLib because we're just not sufficiently done with the
design to freeze the APIs yet. This means that you will not be
able to use the new menu notifications on the shipping version
of Sonata. However, there will be a new CarbonLib released with
the Mac OS X final release (and pre-release builds) that has all
the new event system. That new version will also be installable
on Sonata and older systems." Since we can't depend on new
APIs that aren't scheduled to be there until close to beta, it
looks like we will have to write our own MDEF, increasing risk
and possibly time to implement.
People
- Scott Collins is now working onsite in Mountain View.
- Peter Trudelle will be on vacation from 7/17 through 8/1.
Suresh Duddi has our XPCOM update this week:
Startup performance improved greatly on all platforms. Areas
of improvement:
- xpcom interaction with registry (thanks to Dan Veditz)
- number of dlls being loaded (thanks to Bill Law and Cata)
- Factory caching by XPCOM
Christopher Blizzard updates us regarding his work on the XLib
port:
"I've made a lot of progress with the xlib port. Although
there's nothing in terms of new screenshot material, I did manage
to get native widget scrolling working. This means that when you
scroll, buttons, text areas and other related goodies will scroll
off the screen. This is actually a pretty big deal although it
sounds trivial. X is not good at doing this kind of thing.
Also, removing loud and numerous debugging messages has revealed
the fact that the xlib version is actually faster than the gtk
version now even though it doesn't compress expose events or use
shared pixmaps or shared images yet. It's going to spank when
performance becomes a priority."
Trow writes,
"Mostly bug fixing for M8. Some things worth noting:
- we're now using a hash table implementation for GetPrimaryFrameFor()
to speed up the mapping from content object to its associated
frame
- high on the list of problems to fix is the poor painting performance
when doing incremental reflow. Today what we do is we repaint
the entire visible area when processing a reflow command. The
plan going forward is to have each frame damage the dirty area
within its frame rect."
This week has been devoted primarily to fixing M8 bugs and to
tracking down regressions introduced by the free-for-all late last
week.
Cool feature of the week:
"Apply Style Sheet" lets you apply different styles to the
document being edited.
Recent checkins of particular interest:
- Progress on the ender gfx text control (including some workarounds
for netlib and event handling bugs which were holding up progress
on the gfx widget), and on autocompletion within it.
- Bug fixes to text and html output.
- Improvements to selection up/down arrows.
- Major progress on many editor dialogs, now that dialog sizing
finally works; most of the dialogs are now usable.
- Work on defining block vs. inline tags in a way which will
be usable from different parts of the product.
Mike McCabe has our Javascript update:
"Thanks go to Colin
Blake, who contributed more patches towards compiling JavaScript
on OpenVMS. Some porting issues remain with other aspects of Mozilla,
but it looks like JavaScript is in the clear. kherron@sgum.mci.com also contributed
some warning fixes to jscpucfg.h.
Thanks - every bit helps.
From the standardization front, Waldemar writes:
ECMAScript Edition 3 is almost wrapped up and on track to becoming
a standard in December. This brings the ECMA standard up to date
with de facto JavaScript and adds some important
features such as the ability to catch errors and better support
for regular expressions.
We're having an ECMA meeting next week. I am preparing to lead
a discussion on the interaction of COM with JavaScript 2.0's (which comes
*after* Edition 3) package, class, and versioning mechanism."
Mike McCabe has our XPConnect update, with news from John Bandhauer
as well:
"Mike Ang's line-number
tracking fixes for the xpidl
compiler are in. Writing and debugging IDL should now be a little
easier.
In related news, representatives from Sun's 'Blackwood' Java/Mozilla
integration project met with Mozillans to create Mozilla modules
for some of the cool stuff they're working on, including an XPConnect-like layer for manipulating and
implementing XPCOM interfaces in Java. Expect to hear more soon.
John Bandhauer reports:
I'm been rooting every vestige of JS_ReportError out of XPConnect. JS exceptions
are the one true way.
I have the "stack of JSContexts per thread" service working.
After the tree reopens vidur
will insert the magic calls for the DOM. This allows us to always
know what the current JSContext is - even for functions that don't
pass it around. Very exciting stuff :) I've been starting to write
code that depends on that...
I've extended xpconnect to provide a service that will give
a linked list of xpcom objects representing the JS stack on the
current JSContext on the current thread. This will be useful for
debugging purposes and for exceptions. Currently (in my tree)
it is exposed to JS too as 'Components.stack'. This will likely
need security protection in web scripts.
I'm working on making JS and xpconnect easier and more transparent
to use. This includes tools to more quickly and easily find errors.
Ideas, suggestions, and help are welcome.
We still need xptcall ports for many platforms.
Duncan Wilcox fixed 'this'
adjustment problems for BeOS that will also benefit other Unixish
x86 xptcall ports that use gcc.
Glen Nakamura contributed
an Alpha Linux xptcall port. This is a good starting point for
other Alpha platforms.
Bert Driehuis
contributed some cool code to help dynamically figure out vtbl
layouts for this fun xptcall stuff.
All of this is waiting on the tree to reopen before it gets
checked in."
Previous Updates
|