XUL Talk:Priority List

• (a specialized form of grid which looks like a spreadsheet view) would be very nice, but it would have to be extensible and customizable. There are many flavors of grid-like objects in fat client applications, from spreadsheets like Excel to database-centric windows like the ones in Access... it's going to be a challenge to provide a grid control that is flexible enough that developers will use it and not resort to "rolling their own". We're prototyping something right now that is horrendously complicated already, and it's not even anywhere close to being functional yet... it would be very nice to have a built-in widget that could at least give us a leg up.
• spreadsheet view. This is an awesome idea. the spreadsheet got pcs where they are today. XUL is well suited to business applications. a spreadsheet view is an extremely logical step.
• resizing handles. I can't see it being too hard to implement, but it would be a dream come true. It would make it trivial to develop graphics apps, and a xul ide. a onresize handler would be great too if there isn't one already.
• making notification popup alerts. Yes! this would be great. Also somewhat attached to this is I'd love the ability to minimise an app to the system tray area (on windows). This functionality would make it a lot more like konfabulator in that you could write small quick apps that can be accessed easily.
• floating palettes. This would be to bonus of the year! fixed palettes are so < 1995. we're a decade older!
• make xul work properly in xml is another great one.
• If I could vote (which might be an interesting concept for the moz dev team to determine what developers want), there's the top 3 from my particular business perspective:
• spreadsheet-like control (like a StringGrid in Delphi/C++ or a data grid in C#)
  • printing, absolutely!
  • extend the template-thing much, much further, beyond the concept of RDF-controlled content generation. Dynamic, editable forms with plain-XML datasources would be great - maybe a bit like InfoPath. All the basics are there, it can be done!
  • A easy way to do confirmation boxes, and other simple dialog boxes without lots of workarounds due to security restrictions would be _very_ helpful. In my last project using XUL a lot of effort was needed to workaround what would have easily been accomplished in small, simple dialog boxes on a local fat client.
• Spreadsheet-like grids and more versatile (ie editable) treecells would be very useful.

Toiletduck> A good test of functionality is we need to be able to implement an iTunes clone in XUL. I'm not talking about the backend playing(decoding) of songs but everything else. We especially need a tree where you can double (or single) click in a cell to edit the content. An event should be triggered at _least_ when you hit enter/tab. I want to make a scripting language editor. When i click on the class, I want an attributes editor like visual c/basic. when i click on the value of the attribute I should be able to edit it! at the moment there are no editboxes allowed in treeviews. Neil (www.xulplanet.com) provided a hack but it makes the cursor disappear! This is 1995 functionality. about:config would be so much nicer with this functionality. IMHO it should be in priority 1.

1. Priority 3/item 12 Dockable widgets. Venkman already does this. Robert has a fairly generalized XBL implementation of Docking Container and Dockable Element.

From Benjamin Smedberg:

• Restructuring XUL Document ForwardReference resolution etc such that it could be done after the fact (i.e. dynamic overlay loading) would be very useful - e.g. for extension installation without requiring a restart. Probably not all that hard either, other than devising an API for doing so.
• Also, fixing NativeTheme rendering on Windows at least for tabs, groupboxes/captions, menus etc should be priority item.

From Nigel McFarlane:

We see that, as Mozilla technology matures, it collects more high-level constraints that make promises to the technology user. Performance and download size are well established as important constraints. The Firefox 1.0 project has now added the useability constraint "best feature subset", and recently we see that Firefox 1.1 has accessibility in its sights. Some of this excellent logic should be applied to XUL & platform offerings, where the audience is application developers.

In my view (and experience) 99% of this target audience for XUL has a mindset well separate from that of core Mozilla developers. A goal of XUL improvement should be some basic useability / feature performance support as it is defined for that audience. Currently XUL is performing very poorly against app developer expectations, despite its great potential.

At minimum the path that app developers must tread to engage with XUL should be less bumpy and painful. More properly, a better picture needs to be drawn of what performance expectations developers have of XUL while they learn, and while they do development. That would lead to a better understanding of what are acceptable directions for XUL and what are not.

• It's a process or a conversation that's required here. We need to collect an understanding of the context and mindset of the majority of XUL use, not just list a grab-bag of features (although features are important too). We need to consider what attributes make for successful application development and application delivery environments. We need to grasp what the other needs, since that is the audience for XUL.

• Specifically, but only as a first suggestion, we need to break down the assumption that all XUL developers will have the talent of top-tier programmers. That is not at all true and we do not assume that in the web development space. We should pro-actively be inclusive of the majority of XUL developers, not just the talented few.

Although an XUL IDE is an obvious impulse, I don't believe that tarting up existing XUL technology in new clothes is the right way to ensure that XUL will work for the people that use it. Silk purses made out of sows ears is no solution. Better to have those people's interests addressed closer to the fundamentals in the first place, where greater leverage is possible.

- N.

XUL:IOMapping

[Peter Wilson]Mozilla currently has no mapping process for converting from template variables into widget values. (unless you count reams of C++ and JS code). With the proposed changes to the template mechanism it is possible to investigate a mechanism for binding small amounts of code to perform:

• mapping of internal data values to presentation values
• the inverse mapping, including validation of input.
• collation of datasource values dependent on datatype or other criteria.

It occurs to me that xbl already contains most of the features you would need. The following example syntax relies on the fact that template variables are changed to be similar to Javascript variables and not just strings.

<template xmlns:prop="http://mozilla.org/xbl/property#" ..>

  <textbox class="date" value="prop:mappedvalue" prop:intenalvalue="?datemailsent"../>

</template> Where the prop: namespace maps values to properties of bound xbl.

with a css binding of

textbox.date = mapout { url(chrome://.....#dateOut)}

textbox.date = mapin { url(chrome://.....#dateIn)}

textbox.date = collate { url(chrome://.....#dateCollate)}

and xbl <bindings>

 <mapout name="dateOut">
    <property name="intenalvalue>
      onset = "this.date = this.internalvalue;"
    </property>
    <property name="mappedvalue>
      onget = "return this.date.toLocaleString();"
    </property>
 </mapout>
 <mapin name="dateIn">
    <property name="intenalvalue>
      onget = "return this.date;"
    </property>
    <property name="mappedvalue>
      onset = "try
      {
         this.date = new Date(Date.parse(this.mappedValue))
      }
      catch (e) {error response}"
    </property>
 </mapin>
 <collate name="dateCollate">
     <method name="compare">
     <parameter name="a"/>
     <parameter name="b"/>
     <body>
          if (a.valueOf > b.valueOf) return 1;
          if (a.valueOf < b.valueOf) return -1;
           etc.
     </body>
 </collate>

The sort service could call the compare function when sorting data to obtain the correct collating sequence for that column data type.

Error handling needs to address: widget focus, widget decoration, and locale dependent error messaging. The .net ErrorProvider is along the right lines. There also needs to be a way to suppress error checking for certain actions - Cancel button, for example, so that the user is not locked into a form.

Using xbl would have the distinct advantage that all widgets presenting a given data type could be bound with just one xbl definition.

This also has other uses for template use as xbl properties could be used a part of content selection/generation.

General Considerations

• 1. Allow multiple bindings per widget? Problems start to arise with dependency between values computed by one binding being consumed by another. Also two bindings could not target the same result property.
• 2.This scheme must also work for tree and other widgets which don't allow general widget content. A binding for <treecell class="date"/> should also work.
• 3.Template variables used in widget attributes, as at present, would be subject to an implicit toString() conversion.