mozdev.org

resources:
subprojects:

The following is the general roadmap of upcoming releases (See ToDo for how this relates to identified enhancements.)

v0.50
Current (beta) release
Fix more of the known bugs
Editable Text View
use of XML Schema as XUL Specification to fully define all XUL elements and attributes
View Preferences
Move Elements
Clipboard (cut, copy, and paste)
Whitespace
v0.60
Floating/Container Views
populate menulists from XBL which is built from XUL Schema
Context Popup Window for Properties
Tooltips and/or Statusbar Display of Element
Move Elements (Drag and Drop)
Add Elements (Drag and Drop from palette)
Replace ID usage with XPath
Insert (assign) CSS Stylesheet, Overlays, JavaScript file
Build non-window XUL files - overlay, wizard, dialog
Events
v0.70
Element Explorer becomes DOM Inspector
v0.80
focus on developer efficiency
Generating UI Parts from Templates
Design menus
Design broadcasters and observers
Design tree elements
Sizing and Flexing
v0.90
Print capability
v1.0
production release
v1.10
remote application launch
v1.20
editable source code view, colour coded (integration of view-source: and <editor>
simultaneous views - design view, source code view
v1.30
Designers (integration of Cascades, ScriptEditor, mozcvs, xpimaker)
Define Dynamic Content with XBL
XSLT Transformation of XUL to HTML
Spoof IE

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.

See http://www.mozilla.org/docs/dom/technote/whitespace/ for comments on whitespace in XUL. Also look at "prettifier.js" (as referenced in version 0.20 of XULMaker) which defines DOMPrettifier. It supposedly used by the XMLSerializer.

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:

<label value="hello"/>

Element Explorer becomes DOM Inspector

We would like all the functionality of the DOM Inspector for the Element Explorer. This could possibly be accomplished by replacing the Element Explorer view with some of the major components of the DOM Inspector. (These components would be referenced as chrome: files rather than be packaged as part of XULMaker. Hopefully the DOM Inspector offers us a generic enough interface.)

Generating UI Parts from Templates

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:

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:

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:

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:

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.

I have developed just such a xul2html.xslt stylesheet and corresponding JavaScript. It is but an initial effort, but works for basic elements and tabpanels. (I developed it particularly to support tabpanels.) If you are ready to continue this effort contact me (Franklin de Graaf - franklin@xpower.com).

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".)

The xulmaker project can be contacted through the mailing list or the member list.
Copyright © 2000-2017. All rights reserved. Terms of Use & Privacy Policy.