2007/10/4, Phil Frost <[EMAIL PROTECTED]>: > The problem is that gui objects have semantics that must be define. For > example, a number box is pretty much (or exactly?) the same as [f], only > it is drawn differently. As long as the number of gui objects are > finite, this isn't a big deal, since the semantics can be defined in > every nova executable.
That's funny you mention it, i'm getting dirty with numberboxes in nova at this moment... when you take pd numberboxes and [f]s they are not exactly the same... you can send them a message [set ...] which is equivalent to [f]s right input or you can send them a number which is equivalent to banging [f] at the left with right input, so in a way it is a semantically altered version of [f] to suit certain gui needs/concepts... but here end the similarities: you can, for instance define the width of a numberbox which again alters it's semantics not only the way to draw them (width=1 for instance, is a toggle).This behaviour is not carved in stone, i'm glad to get input from all potential users, especially on the semantics of the number object. > However, what if I want to implement some new complex object for nova, > and I want to make a GUI for it that isn't some amalgam of existing GUI > objects? Let's say for example, it is some sort of fancy sequencer. I > decide it is adventagous to implement a custom GUI instead of using a > combination of existing GUI boxes because this sequencer is quite > complex, and a custom GUI allows me to make it more usable. > > In order to maintain the GUI separation goal previously mentioned, I > have to somewhere define what this sequencer does (the semantics) > separately from how one interfaces to it (graphically, in this case; the > GUI). This isn't really possible if the sequencer is one "gui object". yes it is possible... you have to think of the gui object in both ways: a gui object in the nova language (or as an extension) simply defines the semantics of this object (in the nova sense) and the interfaces needed for kernel<->gui communication. After that any gui object (in the qt/gtk/... sense) can define a visual interface to this nova object. If that isn't separation enough, you could (or should, tim?) define a non-gui object (again in the nova sense) that handles most of the semantics and the corresponding gui object (nova) just deals with with the kernel/gui-interface part... actually a gui_bang is doing exactly that. I think this approach is quite flexible already. > This has other implications as well. For example, sliders can be > switched to number boxes in a patch without deleting and recreating the > box. GUIs can be disabled when they are not needed to save space or > reduce CPU load. i don't know if got exactly what you mean but i guess it could be implemented, that gui_objects revert to their non_gui counter parts... but even better: with the implementation of nova gui_objects, disabling the gui_components is left to the gui implementation because their semantics still work correctly in the kernel... > Another point is that non-gui objects like [f] have state, but that > state isn't reflected in the interface. For example, I find a simple > thing like <http://unununium.org/~indigo/counterpatch.png> confusing > because it says "[f 1]" but depending on how many bangs it has had, it > could be something other than 1. If a number box and [f] are one and the > same, then whether or not the current state is displayed or not is a > matter of choice of interface, which can be adjusted without modifying > any connections. but thats exactly why number_boxes are used, so you can see the state of an [f] in the user interface (and alter it directly with the mouse of course)... as mentioned above, they are not the same. Mischan _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
