mozdev.org

ToDo (Enhancements)

View Preferences

The make-up of the various toolbars should be customizeable. The Palette Toolbar, in particular, is impractically large if it includes all XUL elements. The user should be able to select a set that is particular to his/her use.

This could be implemented as a dialog window which is launched from the Options menu and/or from the View | Toolbars menuitem.

+-------------------------------+
| View Preferences              |
+-------------------------------+
|                               |
| +----------+      +---------+ |
| |          |      |         | |
| |          |  |<| |         | |
| |          |      |         | |
| |          |      |         | |
| |          |  |>| |         | |
| |          |      |         | |
| |          |      |         | |
| +----------+      +---------+ |
|                               |
+-------------------------------+

Replace ID usage with XPath

At the moment XULMaker insists that every, and I mean every element must have an ID. This is because the tree code as well as other parts of the program use IDs to keep track of what's going on, and while there is nothing intrinsically wrong with this (XULMaker generates unique IDs for you) it isn't great for readability or just general elegance. The proposal is to move the internal code over to using XPaths instead of IDs. (This depends on the working of XPath - part of Mozilla's XML Extras project, as does XML Schema.)

Move Elements (including Drag and Drop)

Using Drag and Drop, one should be able to move elements around - within the design document, in the Element Explorer (tree) and from the Palette Toolbar.

Events

We need to separate events that are part of the deliverable XUL (design) document and what are events that are put into the design document for the purpose of operating XULMaker. As a minimum the xm: events need to be stripped off for serialization and saving and put back on when loading and parsing. A simple strategy would be to use right-click events for XULMaker operations.

(Michael Hearn started with this in version 0.20, which exists in the CVS repository, but was never completed as a release.

Whitespace

Whitespace is not properly generated in the XUL document and reflected in the serialized XUL document. Whitespace should be preserved going round-robin between these two representations of the XUL document. (This may in part be a Mozilla issue.) We should be able to set/unset a "pretty-print" flag to control the whitespace generation.

Floating/Container Views

The application views - Element Explorer, Attribute Explorer, Document View and Support View should be consistently defined as "floating views" a la the javascript debugger - venkman, which allows for views to be moved around within the application view and even made floating.

Views should be stand-alone. They should have a titlebar and perhaps their own controller UI - menubars and toolbars.

venkman uses <floatingview> and <viewcontainer> tags within the XUL definitions and some javascript files. See the venkman.jar file and its containing venkman.xul, venkman-views.xul and venkman-views.js files.

Context Popup Window for Properties - Attributes Inspector

A right-click on the "active" element should result in the popup of the Attributes Inspector view (as a floating view). The context version of the Attributes Inspector should probably be labelled for the particular element and not change content as a different "active" element is selected.

Tooltips and/or Statusbar Display of Element

The XML text of an element and it's attributes could be displayed in a tooltip and/or in the statusbar when hovering over an element in the design view

Example:

Element Explorer becomes DOM Inspector

We can provide various samples for a XUL user to leverage from, but we should be able to do better. We should be able to define and use templates for entire application documents and document fragments. In particular, we should be able to provide assistance in building hierarchical trees, lists, grids, tabpanels (tabbox), menus, toolbars and some more sophisticated UI such as views a la venkman.

Some of these UI parts could possibly be generated from parameters collected in a dialog.

Sizing and Flexing

The user should be able to select a "Sizing and Flexing" pattern to be applied to subsequent construction/element generation. When changing this only elements that are subsequently constructed are to be affected. Flexing policy should chose between "packed" (the usual default) and "expanded to fill the page". We should be able to "size" a box using drag gestures - which results in giving an element width and height attributes. We should also be able to remove them very simply, i.e. with the minimum keystroke and mouse action.

Print

Add some print capability. Be able to print the following:

• XUL Document DOM tree (Element Explorer)
• XUL Document design view
• XUL Document browser view
• XUL Document code view

Remote Application

XULMaker should be able to run as a remote application.

In particular, this means setting some security to access the chrome, e.g. components, preferences, etc. This involves the use of security certificates.

chrome: protocol would be replaced by file: and http: protocol in some places. We should also be able to deal with URL's instead of local files for data, i.e. add a File | Open resource by URL menuitem.

Designers (Integration)

To evolve XULMaker into a full blown XUL IDE we need to add or integrate various other designers. The following designers are suggested:

• CSS Designer (integrate "Cascades")
• Theme Designer (integrate "Chameleon")
• JavaScript Designer (integrate "ScriptEditor")

Versioning using CVS could also be added by integrating "mozcvs".

Save with...

The saved file may be more than just a straight forward XUL file identified as an XML file. It could include link references as follows:

• CSS stylesheet
• XSLT stylesheet

In order for these link references to be included in the saved XML/XUL file the user may select the Save with... menuitem to give the required information (or this may be given in some user preference definition).

Define Dynamic Content with XBL

Create a designer for defining dynamic content with XBL

XULMaker Project File

We might add a Project menu where we could open/save a project file (*.xmk) which would be a zipped bundle of various XULMaker files which make up a project. The project bundle (zipped file) would contain anyone or all of the following:

• XUL document (serialized text) (*.xul)
• XUL Overlay document (serialized text) (*.xul)
• XBL document (serialized text) (*.xbl)
• CSS stylesheet(s) (*.css)
• XSLT stylesheet(s) (*.xslt)
• script file(s) (*.js)
• XULMaker settings file (*.xms)

XSLT Transformation of XUL to HTML

Develop an XSLT transformation stylesheet that transforms XUL to HTML. XUL files could then be delivered as XML files with a xul2html.xslt stylesheet reference and a reference to the applicable JavaScript. These could then be viewed in non-mozilla browsers such as Internet Explorer and even old Netscape browsers.

Spoof IE

Be able to see how a XUL file looks in IE and in other non-mozilla browsers. (See XUL Planet's "Preferences Tool".)