concerning the reoccuring demands for native GUI-elements in vvvv, let’s discuss!
my take on it:
a native GUI in vvvv (meaning, at the most basic level, some sort of input mechanism that does not freeze the rendering when changing values) might speed up the patching process a lot and, in this regard, fit rather nicely into the disposition of rapid prototyping. i would argue, though, that a polished gui is not part of a prototype; and the existing methods of controlling patches by means of ioboxes etc. are more than sufficient for building functional structures.
on the other hand, the demand for ‘nonfreezing ioboxes’ implies that this input mechanism would then be used to control the patch exclusively, without any further need to build an own, special gui for that specific patch. this implies the demand for a very versatile input mechanism that is able to handle all types and all amounts of data in any way desirable - so that it can be fit to any patch and use.
any input mechanism that is both tied down in the structure of a patch as nodes and customisable to such great extend is also prone to become rather static, which would have to be avoided to keep the power and flexibility of dynamic and spreadable structures.
considering the above, i believe that the complexity of such an input mechanic would either become over-the-top or require the introduction of a different model than the one of the iobox. as it is right now, my preference would lie with selfmade guis custom-fit to specific applications.
in the meantime, i’m counting at least 5 different approaches to build a modular gui in the wiki; as most of them are rather complex (newbie-hostile) and sometimes resource-intensive, i recommend setting up a ‘Custom GUI Method Collection’ with a set of reoccuring modules needed to build an own gui (e.g. rendering text, different input methods etc.) as an alternative to the ‘sealed solutions’. in fact, i’m going to start right now ;)