XUL:Common Problems
Here are some things that many XUL developers tend to have a difficult time understanding. These are the kinds of things that documentation doesn't seem to solve.
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.
