• Thursday August 28th 2008
• Do you want fries with that project?

Skip to Content

xulapp

resources:	Home Mailing List Installation Source Code Members Screenshots

Requirements/Design Discussion

These requirements and discussions represent a brain dump and need editing. The requirements are not closely divided into requirements and possible solutions. None are set in stone and deserve much discussion. They are divided into functional areas:

General

Items not covered by other areas:

• Usability: Having used a number of IDE's I find them to be very hard to learn/use. Can we do better?

IDE Framework

Matters relating to the IDE framework level.

• Features should (eventually) be exposed using XPCOM interfaces. This allows scriptable access to IDE features. and permits other languages to contribute to the project and/or use its features. Interfaces do not need to be globally exposed. we could have xulapp.Components.interfaces.. as well as xulapp.mytool.Components.inerfaces.. etc. Failing that interfaces should at least be documented as independent items.
• Method to discover and install tools or other extensions into the IDE.
  This might just be the Firefox extension mechanism.
• Need API to discover which tools are installed. Note: an API might just return an XUL element We don't need to slavishly emulate other IDE's with a massive API for getting setting properties. Let us
play to our strengths.
• API to integrate with Version Control Systems.
• Project creation features.
  The project prototype currently can create a project description file and register the chrome. This needs rework to be Firefox profile specific, current projects are global.
• Is nested project creation is required.
• Project options feature.
  Access to all project/tool options.
• Hooks for project creation wizards.
  Different types of project should be differentiated and wizards developed to help set them up.
  e.g. An XBL project or a project to create an XPCOM component, or a project to package a number of other projects for distribution.
• An interface for managing files within the project. The current prototype uses a File Explorer type interface with hooks to editing and viewing tools. The current prototype uses a multiple window approach. Personally, I find this simpler to comprehend than the monolithic approach adopted by the other IDE's. It also lessens the requirements for interoperability between components. No need for toolbar/menubar merging etc. (Though some will still be required.) It does require that we be able to manage these multiple windows in useful ways which extend beyond mere cascade/tile if the screen is not to become cluttered and unusable.
• Remote project files.
  After all, we are on the web.
• Utility functions.
  The bare XPCOM interfaces are fine, but a set of wrappers is desirable. The JSLib comes to mind here. The current project has its own variant of JSLib (3 years old) which handles chrome URL's and handles errors using the exception mechanism. We will probably need to stay forked to maintain these features - but liaison with the JSLib project is indicated.
• Utility functions should be dynamically loadable using an import statement so that XUL does not become cluttered with script tags. Javascript 2.0 should offer some help here.

Editors (General)

Matters relating to source code editors in general. Editor of one sort or another will form an important part of the XulApp environment. It is worthwhile trying to get a consistent approach rather than an ad-hoc one.

One possible framework has these components:

The editor is based on one (or more) source documents (usually xml) which act as the Model for the editor. The Editor then presents (one or more) Views of the Model to the user. The user then can edit the View directly with effect on the View only, or additionally on the structure and content of the Model.

Martijn Schrage's thesis on the Proxima editor: gathers these ideas into a coherent framework. We are in the position of having his presentation layer provided by the Firefox browser and CSS also takes care of some of the transformations between his other layers. In the Mozilla world a generalized editor framework could consist of:

1. An XML document (or several) which serve as the model (a.k.a. the source code).
2. An XSLT transform which transforms this model into one or more presentations. Being Turing Complete, XSLT has considerable power to rearrange, collate, and summarize the model document. This can involve the creation of new elements/attributes which are only present in the view.
3. The browser presents the presentation view.
4. The use of the CSS3 user-input feature permits only specified areas of the view to be editable. The CSS3 User Input specification is unlikely to be accepted, but it lives on in the equivalent -moz-user-* CSS properties. This is a powerful feature as the editor is able to keep control (and validity) of the gross structure of the document whilst allowing freeform input in other areas.. The editor must, of course, provide features for creating and transforming the gross structure which is otherwise inaccessible.
5. The program records user keystrokes and records them into the view content at that point. (The user-input feature provides no interpretation for user input - the program must provide this).
6. Optionally, the user input is parsed and used to update the view/model. Parsing may vary from a simple regex, to the full use of a language parser. There is a point of diminishing returns for any structured editor where imposing the structure of low level constructs become onerous for the user. For a source code editor this is probably reached at the expression level.
7. Other user gestures (drag & drop) (cut & paste) (mouse gestures) (menu or context menu selection) etc. are used to transform the view and optionally the model.
8. If the model has not been synchronized with the view a reverse XSLT transform may be applied to the view before the model is saved.

Editor layering and its consequences

Source documents are increasingly becoming compound documents (see xjsEditor below). An xjs document can contain xhtml documentation which can contain SVG which can contain MathML etc. It looks like document layering is a fact we will have to live with.

It also looks like we will need something akin to Microsoft OLE (Object Linking and Embedding). Editing can be either in-place or via opening a new window to edit a fragment of a document. Editors will need a framework to modify the menu, toolbar, and context menus whilst they are in control. This also implies that the use of the XUL commndset/command/keyset/key features will need to be added to the editor form dynamically. If I install a new MathML editor, I should not have to modify the xjsEditor XUL definitions to make it operate.

It will probably be a good idea to develop a set of editors in tandem so that commonalities can be identified and moved into an editing framework.

Parsing Framework

There is no getting away from the requirement for a good parser. The following requirements are a start:

1. Context Free Grammars. This gives composability/reusability of grammar modules.
2. CFG's also allow simpler grammars as ambiguity is not an issue.
3. CFG Parsers don't require the degree of hand crafting that LALR(1) grammars require.
4. Speed is nice, but: The editors need to parse single expressions or statements. OR The parser is importing some existing code into the framework, so speed is not essential. (Just as well we are not going to get it!)

This indicates that an Earely or Tomita parser should be the target. A number of each (written in C) are available in open source format.

In the interim, text can remain un parsed (or manually parsed) and the JS system can bletch about it - which is what happens now anyway.

Editors (XJS)

Observation: Javascript execution is way too slow to hold Javascript in source form and then process it in an editor. A simple tokenizer, written in Javascript, can take from five to ten seconds to process a 1000 line source file. Another approach is needed. If the Javascript is held in an XML format then scanning and parsing are handed over to the XML parser which operates ten to twenty times faster. It turns out that this offers some unique opportunities.

1. Documentation and other items may be added to the source document.
2. Embedded Links between documents is possible.
3. We can add features which make editing easier (code folding, transformations etc.)
4. We can support features of a language which has not become available yet - Javascript 2.0.
5. This enables other feature such as type checking, code completion, syntax checking etc.
6. We don't have to present the XML to the programmer. The "Enough pointy brackets already" crowd have a point.

The current implementation of the xjsEditor fall into this category. A simple mockup can be found here. In the current implementation, the model is transformed into the view and then retransfomed on saving. The model is not maintained during editing. This will probably have to change.

A set of templates is used to create new structure (if and else so far). The template is transformed using the XSLT model/view transform and inserted into the view (currently at no particular point). Structure transforms should also be performed using this mechanism.

Editors (XUL)

The current implementation of the xulEditor falls into the ad-hoc category and should be re-written. It currently maintains a model and several views which are synchronized during editing. This requires that a map associating the view and model elements need to be maintained. The same technique can be reused by the editor framework above.

The current editor uses widget templates to add new items to the design using Javascript code and also to identity insertion points. Recent changes to the XUL for tree, listbox and tab components require multiple changes to the target document to maintain consistency. This is also required for row and col elements to maintain a correct number of children. The use of XSLT to transform a template depending on the current document state is probably required.

This editor is also complicated by the fact that multiple input documents need to be maintained simultaneously: XUL, CSS, DTD, Javascript.