I don't think SPDLs necessarily do what you think they do...
There is the part at the bottom, that is the layout for property pages.
What's happening here is that the data is read and put in the layout manager. You can poke layout and attributes in scripting in the same way that it does. We're using SPDL so that's human-editable file and there is no point in moving that to XML or anything else, as there is an API to create and modify property page layouts programmatically.
The SDK team doesn't really want people to continue to use SPDL for custom properties or scripted operator, if I'm not mistaken only the shader developers should still need to use them, to define the parameters (which are tied to the order of the parameters in the shader's 'struct'). Although I understand that some people are still on XSI 4.2
The part at the top is the definition of the parameters, and that behaves slightly differently between shaders, and custom property set/ scripted op, but in both cases it's used to build a data structure that is then saved in the preset. Whether you're able to add or change connection types, it's not a really limitation or function of the SPDL, but the eventual architecture working in conjunction with mental ray.
in both cases the SPDL is not a programming API but it's a script to poke things either in the layout manager, or the parameter definition dictionnary, a one-time thing.
btw, even though there are GUIDs for each parameters in the SPDL, the only part that that was relying on the windows registry is the code to make the link between the preset file and the SPDL. The parameter guids are things that XSI uses internally and were not going in the registry.
> -----Original Message-----
> From: Matt Lind
>
> I always found SPDL to be rather limiting - more trouble than
> it's worth.
[...]
(not quoting entier text because of difficulty with wrapping )
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
