Contents

Comments NeilDeakin

Chrome

The term

People have difficult time understanding chrome. For instance, it is common to
assume that files placed in the chrome directory have added privileges. Or,
that the 'navigator/content' part refers to an actual directory. The problem,
I think, is partially caused by overuse of the word chrome. Consider:

chrome

the browser UI around the web page

chrome URLs

the chrome protocol which is the only way to get privileges

chrome directory

the directory where the apps put their UI files

chrome command line argument

start and open a file in a top level window

chrome argument to window.open

opens a new window top level

chrome.rdf

the chrome registry, in install directory and in profile

It seems to me that at least some of these uses could be changed, or
deprecated.

Chrome registration

In addition, there's the fact that there is no way of knowing whether your
newly created chrome application is set up right and you haven't messed up
your RDF somewhere.

This problem is of concern since registering a chrome application is the first
thing developers need to do. If this is too hard, they become discouraged.

This has become much better after bsmedberg's changes to chrome registration, and for example getting started with writing extensions should be quite easy because there are quick-start guides and downloads: [1]. We should provide such stubs for xulrunner apps too. --Nickolay 11:09, 11 Feb 2006 (PST)

Trees

Some common issues about trees:

an assumption that there are always DOM nodes for the tree rows. For instance, I've seen people implement their own nsITreeView and then wonder where the DOM nodes are.

developers try to use the style attribute.

desire to put arbitrary content into trees.

Trees are one of the parts of XUL that has been improved recently.

I am of the opinion that trees don't really need to support any kind of
content, apart from text and a few other things that it already supports
(images, checkboxes, progressmeters). The only thing missing is UI to edit
the tree cells. I had created a demo of this, but a
view issue with the
caret rendering prevented it from working perfectly. For editing, it just
needs to be able to support placing a textbox or menulist in a cell
temporarily.

Some people have tried to use the tree to create a spreadsheet like UI. For
this, I think the real answer is to use a grid instead. One could imagine
creating a more specialized widget for this.

List Boxes

Some Common Issues about List Boxes:

List box headers should have the same functionality as Tree (Column controls, sortability).

After a list box is loaded, users should have the ability to sort any column (asc/desc) and hide columns. This would be similar to the functionality of Trees.

Code wise, attributes should be settable to allow these types of functionality. This should be generic - regardless of the datasource (i.e. RDF, Javascript, XML etc...)

Templates

XUL:Xul Templates are difficult to understand, but I think everyone knows that
already. Mainly since they don't offer any guidance when the user went wrong.
Some of this can be solved, for instance, by detecting template syntax errors
or reporting RDF parse errors. But many problems are logic errors which would
only be detectable by producing some kind of log of what was happening.

I've managed to convince myself that templates do work, and they do a lot more
than most people realize. Maybe I should finally get around to writing that
How Templates Work guide I've been meaning to write for a while now.

Element Interfaces

One issue I had when creating the element reference was that a number of
elements claim to support some interface in their XBL implementation but then
don't implement all of its methods. These are just bugs, but we should fix
them.