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 | +-------------------------------+ | | | +----------+ +---------+ | | | | | | | | | | |<| | | | | | | | | | | | | | | | | | | |>| | | | | | | | | | | | | | | | | +----------+ +---------+ | | | +-------------------------------+
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.)
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.
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.
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.
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"/>
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.)
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.
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:
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.
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".
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).
Create a designer for defining dynamic content with XBL
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
)*.xul
)*.xbl
)*.css
)*.xslt
)*.js
)*.xms
)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).
Be able to see how a XUL file looks in IE and in other non-mozilla browsers. (See XUL Planet's "Preferences Tool".)