Steve Caron was key to the pyQt Soft efforts though, you could write him an e-mail asking if he wouldn't mind writing JScript bindings maybe.
On Tue, Jun 18, 2013 at 12:57 PM, Christopher < christop...@thecreativesheep.ca> wrote: > Is there anything like pyQT for JavaScript peoples :-) > > ::Christopher:: > > using pyqt would be another solution, you could create a custom .ui and > just import it for every asset. > > I am having to do something similar at work and debating which way to go, > I would prefer softimage native of course.. > > > On 14 June 2013 16:45, Michael Heberlein <micheberl...@gmail.com> wrote: > >> Last week I also stumbled upon Daniele's "persistent layouts" blog post. >> To do exactly the "quick and dirty end-user stuff" and store PPG layouts >> per scene or per model, to me it looks like a good solution to use just one >> self-installed "GenericProperty" instead of many. >> >> Michael >> >> >> On Thu, Jun 13, 2013 at 10:47 PM, Matt Lind <ml...@carbinestudios.com>wrote: >> >>> If you store the PPGLogic externally in a file, you can dynamically call >>> different logic files depending on what you want to display. The callbacks >>> can then be married to what is displayed. This is useful for one-to-many >>> relationships like this or in cases where the data gets embedded into >>> assets and you don’t want to have to run a batch process to update them >>> each time the custom property is revised. Modify the external logic file >>> and the next time the asset is loaded and viewing content, it’ll use the >>> latest version of the logic file to display the information. >>> >>> >>> >>> The code to choose what to display can be provided as a >>> function/callback embedded in the external logic file and called from >>> _OnInit(). Just make sure to call PPG.Refresh() at the end. >>> >>> >>> >>> >>> >>> Matt >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Alan Fregtman >>> *Sent:* Thursday, June 13, 2013 12:09 PM >>> >>> *To:* XSI Mailing List >>> *Subject:* Re: Anyone got a tip to convert a customproperty to a >>> regular customparamset? >>> >>> >>> >>> In retrospect, I worded my thread wrong. I meant converting one >>> customproperty to another. I guess it's too much to ask of the software. >>> >>> >>> >>> I don't need Logic. I just want a way to make logic-free ppgs with >>> infinitely different persistent layouts. The SI Blog post is what I'm after >>> (unless there's some trick I've overlooked.) >>> >>> >>> >>> >>> >>> On Thu, Jun 13, 2013 at 2:38 PM, Matt Lind <ml...@carbinestudios.com> >>> wrote: >>> >>> In that case you definitely don’t want to migrate to a customparamset. >>> You want to convert to a more intelligently designed custom property. >>> >>> >>> >>> I don’t see the need for storing the PPGLayout code as a string as >>> _DefineLayout() or _OnInit() could house that code. You can also load >>> PPGLogic from an external file, so really no need to go the generic >>> property route in terms of implementation. >>> >>> >>> >>> Matt >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Alan Fregtman >>> *Sent:* Thursday, June 13, 2013 11:24 AM >>> *To:* XSI Mailing List >>> *Subject:* Re: Anyone got a tip to convert a customproperty to a >>> regular customparamset? >>> >>> >>> >>> Well, *somebody* thought it was a *brilliant* idea to be making whole >>> new plugins for character-specific rig properties, just because they wanted >>> a ppglayout. (None of these properties had any logic whatsoever.) >>> >>> >>> >>> I'm looking to migrate those to a GenericProperty property like: >>> >>> http://www.softimageblog.com/archives/172 >>> >>> so it only relies on 1 plugin instead of 6 or 7. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jun 13, 2013 at 2:07 PM, Matt Lind <ml...@carbinestudios.com> >>> wrote: >>> >>> Once you’ve deployed the custom property, it needs to be supported until >>> you’ve removed it from all content which uses it. >>> >>> >>> >>> The primary difference between a custom property and a customparamset is >>> structure. Customparamsets are a generic custom property for end users to >>> do quick and dirty stuff. They have very little support for PPGLayouts and >>> cannot be identified from script code as all CustomParamSets have the same >>> ‘type’ (customparamset). The only way you can identify them is by name or >>> by comparing parameters. That is why the self installing CustomProperty >>> was invented. >>> >>> >>> >>> I’ve never heard of wanting to migrate from CustomProperty to >>> CustomParamSet, so this is a bit odd. >>> >>> >>> >>> >>> >>> Matt >>> >>> >>> >>> >>> >>> >>> >>> *From:* softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Alan Fregtman >>> *Sent:* Thursday, June 13, 2013 11:00 AM >>> *To:* XSI Mailing List >>> *Subject:* Anyone got a tip to convert a customproperty to a regular >>> customparamset? >>> >>> >>> >>> Hey guys, >>> >>> >>> >>> I have a customproperty defined in a plugin and it is used in a few >>> assets, but I no longer care for the plugin and just want it to be a >>> regular customparamset, however, Softimage complains that the plugin >>> doesn't exist. >>> >>> >>> >>> Is there a trick to converting a customproperty to a paramset without >>> having to recreate parameters one by one? >>> >>> >>> >>> Any help appreciated. >>> >>> Cheers, >>> >>> >>> >>> -- Alan >>> >>> >>> >>> >>> >>> >>> >> >> > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
