This is a summary of where we think we are today. This will change. This will probably be wrong in a few days. As we flesh things out, this should turn into an overview document, but for now this is what you get.

Please direct all comments to the xpfe newsgroup.

XML-UI

We want to allow clients (browser, composer, bookmarks, etc) to build user interfaces by providing an XML file that specifies the content. While we realize we can't do everything in 5.0, we want to make sure we don't make any major mistakes in this language that prevent us from doing the right thing in the future.

The XML will be sucked into the layout engine and stored in a content model similar to that used by the layout engine for HTML content.
The API to traverse this "UI Content Model" is the DOM.
Look and Feel differences for various platforms, as well as the exact widgets that will be used to display that information on the various platforms will be separated into CSS-based style sheets.
We would like to use XSL to do "transformations" on this "UI content".
- For example, the XML-UI specifies a "confirm" dialog style via a style sheet. This would transform the content tree to add the appropriate buttons (in the appropriate places) for a given platform.
API's should be reflected into JavaScript as well as C++

Configurable Chrome

MozillaClassic had this great downloadable/configurable chrome setup based on top of RDF API's and HT. We believe we may be able to achieve the same effect by using the DOM as the way to access the chrome content.

We have no idea what is the right way to do things, but having two API's to access chrome content is bad, so is having two content models.

Question: If the content model in layout is on a document-by-document basis, how can the DOM handle content that must be shared and updated across browser windows (toolbar content, for example).

Answer: Implement a new type of DOM object that acts as a Proxy for objects stored in a central "toolbar content model." When things change in the central version, the proxy is notified. The client (the toolbar, for example) still thinks it's just iterating over the DOM. Attributes that change on a document basis (such as if a particular toolbar is collapsed) can be stored in the proxy as their effect is local to the document, not global to all toolbars.

Widgets

Question: Who owns the widgets now?

Answer: For the most part, the XPToolkit team owns what is in the mozilla/widget folder. Widgets that are required for a majority of applications (toolbars, color picker, buttons) will probably be implemented by us. Widgets that are needed for particular applications will probably be implemented by that applications group.

For a list of widgets we think we need, visit our Widget page.

Open Issues For Now

These are things that we haven't had a chance to think much about yet, but know are big problems that we should worry about. For the platform to succeed, we know we cannot forget about these issues.

Drag and Drop

We want to be able to specify drag and drop interactions in the XML-UI as well as provide a cross-platform mechanism for doing drag and drop correctly. This includes an infrastructure for things like multiple drag flavors and drawing appropriate drop feedback.

Context Menus

Tooltips

For both of these, we want to be able to specify them in the XML-UI. How we tie these into OS-specific mechanisms is still open for debate. Maybe the XP-apps groups can help here.

maintained by Mike Pinkerton (pinkerton@netscape.com)