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.

Songbird

From mig:

Well, we've managed to cook up your proposed iTunes clone as our proof of concept.

And, unfortunately, just about everything in above lists were things we've realized and had to work around to "roll our own." Apologies if proles like me shouldn't be typing here, but it would be nice to un-hack some of the things we've had to do in order to present basic, expected, bugfree functionality to our users.

As just a single example: to properly implement our own window dragging/docking/regioning/resizing functionality on Win32, we've managed to hack the HWNDs out of the accessibility interface and do our work at that level using WndProc twiddles. That's terribly unreusable and we'd like to see all the functionality empowered by such hacking make its way back into the main codebase. Somehow.  ?

Also, in addition to ensuring you folks aim your work at applications developers, you should equally reconcile yourselves with the fact that Win32 is the target plaform where you're going to have the most interest for public "skinned XULRunner applications" and jettison any basic assumptions regarding the lack of platform-specific bugs in a crossplatform world ("oh, weird, it's always been fine on linux" makes me grind my teeth).

Our basic XUL/UI needs (in addition to most of the above):

• Ability to specify extensions as generic "XULRunner" extensions that work on any xr application -- hacking things like DOMI and Venkman installers to now say they are "Songbird" extensions rather than "Firefox" extensions is frustrating (for us as well as our developers).
• Far better hidechrome="true" love on all platforms. It still really doesn't feel ready for primetime, today, and people were challenging us 5 years ago "why not XUL?" when we were writing Wasabi. Devs should be constantly testing their UI functionality both with and without the OS Chrome in play before committing changes.
• An xflex="<int>" attribute that lets you control the perpendicular axis to the current box parent for a specific element rather than requiring that functionality to be implementing by the pack/align attributes on the parent. Best example here is the fact that spacer flex="1" is 0 pixels tall when placed in a default hbox. I shouldn't have to change how the hbox handles all of its children, just to tell that one spacer to grow to its parent's vertical height.
• More intelligent handling of mouse capture in order to not lose mouse events when the mouse is outside of the application window. If I'm going to ever ever implement any kind of stateful mouse activity (ie, dragging things), I have to capture mouse events.
• Completely skip making us drag the app arround and add a dragwin="true" attribute somewhere in the element baseclass chain. If it's lit, any dragging on that element brings the window along with it.
• Make the automatic resizing widgets actually respect the minwidth and minheight of the Document being resized. And make this also just be a baseclass attribute rather than a standalone element.
• The ability to swap everything on the fly (skin, window, locale) without restarting the app.
• The ability to swap from one window to another an html:object that's loaded an NPAPI plugin and have that object survive intact.
• The ability to js instantiate our own NPAPI/html:object instances that survive intact.
• Ability to instantiate truly "hidden" top level windows that still run and function and appear and disappear as requested -- again, we have to hack it ourselves to "Cloak" a window from the OS UI. These windows should not in any way be tied to the existence (or lack thereof) the primary application window.
• A deeper understanding by the XULRunner core for the idea that "the" .xul file is not necessarily always "the" primary UI and that "advanced skinning" (or, perhaps, "skeletoning") involves swapping between XUL pages that implement the same functionality in different ways rather than swapping between CSS pages and leaving the functionality definitions entirely untouched.
• To this end, better (and simpler!) support for Model/View/Controller UI development would be highly useful, where the states of multiple disparate UI elements (in multiple windows) are mapped to a single internal data model and events on that data model are handled by a single internal controller set. The IOMapping idea below is yet another few stumbling steps in that direction but it again seems to be very single-.xul-page specific.

For Songbird, I've implemented a dead simple key-value-callback api (using the moz-prefs as the internal data Model) and added simple automatic attribute/property+eval binding to my api to cause any "bound" widgets in any instantiated .xul window (we might have lots!) to update their View when the Model changes.

This "binding" call currently has to be made through a script instantiated from inside the xul window, and the eval ability is critical to being more than just your own prefs attribute. Still, it shouldn't be impossible to setup a similar system with a more complex version of your attribute that's always available anywhere in the system, not just within prefs pages.

Our dev teams should stay in sync on such issues. Media players have significantly different UI and system resource needs than do browsers.

Lastly, you do need a graphical editor. I count myself very lucky that my own artist isn't scared of XUL, but the "design houses" that live wholly inside large corporations aren't going to be so magnanimous. Raise your hand if you ever had to work with the AOLStudio?

You're all very lucky that MS Sparkle (the XAML editor) is horrifically delayed, but it and the Vista presentation manager are a ticking timebomb under your feet against winning the hearts and minds of the developer war. It matters little that XUL is accessible to good html programmers when Sparkle will allow XAML to be easily accessible to good photoshop/illustrator artists. That's a trump card in the Rapid Application Development space, and complacency there is likely to leave you very spanked in a 24 month timeframe.

mig

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.