From what I can tell (Beta 6), all its dynamic lists are generated when a form opens, and stay the same until it's dismissed. This doesn't work too well in practice - we need to generate lists based on what other field values have already been set.

This is vital for UI like this:

Code: Select all

Host: [menu of available host devices]
Device: [Menu of devices available on that host]


where the device list must be generated for the host actually chosen, which we won't know until the user hits the device menu. (Well, until after he finishes with the host menu; but you don't want to track those dependencies, do you?)

Generate lists when their fields gain focus, passing a valueDict that presents the current value of all the fields at that moment. Let us worry about efficiency; we can always cache on the Python side if there's a lot of work involved.

Cheers
-- perry

Most likely not going to happen in this release - round-trip synchronous communication from an open dialog to the plugin and back isn't as easy as one might think since we're talking about 3 different processes.

We have added the ability for a list to be regenerated whenever a button is clicked (the round-trip was already in place) - so for instance you can have an add button which could take the selected item in a popup and, say, add it to another list.

Code: Select all

<Field id="sourceDeviceMenu" type="menu">
   <Label>Select a device to add to list</Label>
   <List class="self" method="sourceDevices" dynamicReload="yes"/>
</Field>
<Field id="memberDeviceList" type="list">
   <Label>Devices in scene:</Label>
   <List class="self" method="memberDevices" dynamicReload="yes"/>
</Field>

While it would take another user click, you can use this to workaround. Have the user select the host then click a button to generate (and show?) the device list for that host.

Unless there's a show stopper in the plugin UI stuff it's pretty much set for this release.

Most likely not going to happen in this release - round-trip synchronous communication from an open dialog to the plugin and back isn't as easy as one might think since we're talking about 3 different processes.

Pity. The next thing I was going to whine about is incremental UI validation. It's virtually impossible to dynamically coordinate a dialog without running code when focus changes.

I guess my UI for this release will consist of text fields and dire warnings to fill them out right.

Cheers
-- perry

P.S.: I don't suppose you can give us a hack to just load our own nib?

Well, text fields and good validation when the user clicks "Save". While you can't validate field-by-field, you can validate the whole thing and indicate where they've messed up.

One major design goal was to make the developer-facing API platform agnostic. The first thought was to allow people to build their own UI using XIBs in the bundle but upon further reflection that lead us back to the design goal above.

Another thing that we're going to get to is adding the IWS plugin into the new plugin bundle (and switching it to use the IOM). This will enable developers who need much more complex UIs to develop them in HTML and deliver them as part of the plugin. We didn't get that done for this release but it's high on the list for the next one.