|resources:||Home RoadMap Installation Mailing List Source Code Bugs Screenshots Contributors|
|subprojects:||XUL Schema and XPath Evaluator|
The following is the general roadmap of upcoming releases (See ToDo for how this relates to identified enhancements.)
- 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)
- 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
- Build non-window XUL files - overlay, wizard, dialog
- Element Explorer becomes DOM Inspector
- focus on developer efficiency
- Generating UI Parts from Templates
- Design menus
- Design broadcasters and observers
- Design tree elements
- Sizing and Flexing
- Print capability
- production release
- remote application launch
- editable source code view, colour coded (integration of
- simultaneous views - design view, source code view
- Designers (integration of Cascades, ScriptEditor, mozcvs, xpimaker)
- Define Dynamic Content with XBL
- XSLT Transformation of XUL to HTML
- Spoof IE
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.
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 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.
Views should be stand-alone. They should have a titlebar and perhaps their own controller UI - menubars and toolbars.
file and its containing
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
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.
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
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
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.
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")
Versioning using CVS could also be added by integrating "mozcvs".
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
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 (
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 Overlay document (serialized text) (
- XBL document (serialized text) (
- CSS stylesheet(s) (
- XSLT stylesheet(s) (
- script file(s) (
- XULMaker settings file (
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
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
(I developed it particularly to support tabpanels.) If you are ready to continue this
effort contact me (Franklin de Graaf - email@example.com).
Be able to see how a XUL file looks in IE and in other non-mozilla browsers. (See XUL Planet's "Preferences Tool".)