XUL:Wishlist

There are a number of features that are lacking from XUL that are hindering development for me. This is a place to collect these ideas and discuss them.

• The editor should support xhtml. I have been pulling hair out for quite a while now trying to get XUL inside the mozilla editor. What it would basically ammount to is XUL's version of OLE or Opendoc. We should be able to embed XUL in documents we are editing! OLE has been around since windows 3.x at least! If mozilla wants to be an application platform of any creditability, we need this feature.

(XUL:Axel Hecht) This has nothing to do with the development of XUL. This is an editor request, please help Daniel Glazman on this, I think it's part of his plans.

• Better intergration with the host OS's shell. If i'm on windows, I'd love to be able to minimise my XUL window to the system tray. There are reasons for and against this, but if XUL is going to be a real application platform, we should be able to do all the appropriate window tricks.

(AxelHecht) Not sure if this is stricktly XUL, sounds more like something you want to put into GeckoDev.

• Better remote XUL permissions support. This has been discussed numerous times, but is really a pressing issue. Neil Deakin from Xulplanet has some excellent ideas on this http://www.xulplanet.com/ndeakin/archive/2004/6/22/

• Complete and accurate documentation for the developer point of view.

(AxelHecht) This is going to be devmo, which is work in progress.

Suggestions from BenjaminSmedberg

• Similar to the shell-integration above, I would like the ability to customize the context menu that appears on the titlebar of the window.

Comments from RobertOCallahan

I don't do much XUL hacking but one thing I noticed is that there are three ways of touching XUL elements:

• setAttribute(element, "blah");
• element.property = "blah";
• element.boxObject.property("blah");

Why can't we have all boxObject methods be methods on the DOM element, and insist that all meaningful attributes are reflected as DOM properties?

Actually I wonder why Hyatt did boxObjects in the first place.

Comments from Tennessee Leeuwenburg

My application needs to interact with a web service, and I can't see a way to do that.

edit -- maybe AJAX. E4X functionality and all. Are they okay to use? I mean, are they stable, browsers will be backwards-compatible for a long time, functional in firefox and other gecko offshoots etc?

Comments from Roland Tepp

• Currently popup elements can't contain arbitary input widgets (e.g. textboxes, etc.). That needs to go away or at least it should not crash the entire runtime.
• Having a CanvasTag would be great.

Comments AxelHecht

Hixie: i think all Documents should implement all the Document interfaces

Hixie: it makes no sense, in a compound document world, to be able to do document.someHTMLFeature from an SVG fragment but not document.someSVGFeature, just because the root element / MIME type / DOCTYPE / whatever, happened to be XHTML and not SVG.

Comments NeilDeakin

I've put together a list of items to consider for future versions of XUL at XUL:Priority List

Comments VladVukicevic

• Merge .properties and .dtd's into just dtd's -- let the property handler know how to parse dtd's, eliminating the need to often specify and translate two strings, and manage to separate formats.
• Allow the ability for locales to be overlaid on top of the base en-US locale, thus letting not-100%-translated locales still work as new english strings, etc. are updated.

Comment Callek

Extending Vlad's last comment:

• Allow the ability for locales to be overlaid on a specified base locale.
• Allow Themes to be overlaid on a specified base theme (this would only find some missing files, rather than missing lines)

The second point would allow a theme author to syntactically create new themes without much effort, another idea could be to allow @import of the default theme through a /theme_base/somefile.css which would map to theme/somefile.css which would of course expand to the default themes "somefile.css"....or perhaps the concept of this all would be too confusing.

Comment Tomgermeau

• Add a way to create custom shaped windows. Probably defined by a vector. Windows with rounded corners and without titlebar should be very easy to create. This is usefull to create some sort of Konfabulator/Dashboad tools. XAML also has a way to create little cool looking tools. XUL in combination with SVG and this could create a very goodlooking application.

Comment HaraldLapp

more widgets would be nice:

• a datagrid - tree with editable cells
• colspan for grid is imo important; colspan also would be nice to have for other widgets, too - eg for a tree / datagrid widget
• a slider widget. i've seen that neil deakin made a nice one
• maybe a datepicker would also be a nice addition

Suggestion Christophe Dehlinger

• add a property similar to svg's pointer-events in order to have some widgets be ignored while finding out the target of a mouse event. Rationale is here. I tried but couldn't find any workaround. Besides, it doesn't feel like it would take much work, would it ?

Suggestion from AndrewDouglas

svg widgetry extending the xul base components I think is the better long term solution to competing against XAML than strictly using canvas. A write up I did a little while ago here. Hope this helps.

Suggestions from DarrenBall

• Listbox functionality changes:
  • The ability to sort columns (via header interaction)
  • The ability to hide columns (similar to tree widgets)

Suggestions from Renedx

• Thread Manager DOM safe
• Better documentation about the Thread Manager
• Security reason why the Thread Manager can't (NOT_SAFE) access the DOM or either create the thread manager from the JS object (that is on default DOM)