I must disagree. QSA does not provide the application framework. QT provides the application framework. QSA is a scripting language very like JavaScript (based on the same ECMAScript standard that JScript and JavaScript are based on) or Python. The QSA interpreter can be embedded in a C++ QT-based application just like the Python interpreter can be embedded in a C++ application. QSA happens to provide bindings to the QT objects and their methods, so you can create QT-based UI from within scripts. PoserPython is slightly different in that it exposes the Tk UI toolkit instead of Poser's underlying UI framework (except in Poser 5 for the Mac, where some of the underlying UI framework is exposed because of the problems getting Tk working with Poser on OS X). Check out http://www.trolltech.com/products/qsa/index.html for more on QSA and embedding it in a QT-based app. I think it is possible to run QSA through a standalone interpreter and build simple applications that use QT for UI by linking with the QT libs, as you can do with Python and a number of UI toolkits (TK, wxPython, etc.) I'm sure DAZ has not done that, however. The mesh deformations required for posing cannot be done by the graphics card alone through OpenGL. Although you can offload some of the matrix math to the GPU, the CPU still has to do a lot and a scripting language is just not going to be fast enough. D|S is a pretty complex app, and writing and maintaining such a thing in a language as unstructured as QSA would be a development nightmare. Finally, D|S will have a C++ plugin architecture, which is not something you want to try to build into an app written in a scripting language. Not a big deal -- I just think you have misinterpreted what Rob said in the thread over at DAZ. I am not a DAZ cheerleader, just an interested engineer. -Jeremy