On Thu, Sep 27, 2007 at 12:06:59PM +0200, Tim Blechmann wrote: > hi all, > > i know, that it is a common practice to use the language for > configuration, and i think for most projects it really does make sense. > programs in the nova language have two different representations, > though, the xml representation of the saved patch and the graphical > representation of the loaded patch. > from my point of view, using nova patches as configuration files, lacks > the expressive power of a simple text file (asynchronous, indirection, > text-file readability).
Well, I think it's safe to assume the GUI will always be able to load and save patches, and reasonable to expect that should the format change, it will either be backwards compatible or there will be an upgrade path. Regarding text file editability and such, I already addressed this in the last mail. If there are some objects that read text files and spew messages, than the configuration patch might be as simple as [messagespewer] connected to [guiconfiguration]. I also pointed out that with this approach you can also use messagespewer for other things, like sequencing data, or 5000 presets for some nifty instrument you made. As just the simplest suggestion of how such a messagespewer object might work, what about an object that expects a filename parameter or message on it's inlets, and when it gets a bang on its first inlet, it reads each line of that file and parses it like a message (just as a message box would) and sends it to its outlet. The GUI configuration file might look something like: connectionLineColor 1.0 0.6 0.3 connectionLineStyle straight objectAlpha 1 But, [messagespewer] and [guiconfiguration] are mutually independent, so really this is maybe just the way it works by default. No one is under any obligation to use either of these objects in just this way, and since the interface between them is just messages, which many other things can input or output, there are nearly uncountable ways to use either of these objects. It would have been really handy if I could have rigged up some number boxes in a patch to twiddle the colors without restarting the GUI each time. I suspect users that don't like the colors I picked will appreciate this ability, too. Also, I guarantee that users will think of ways of using [messagespewer] and [guiconfiguration] in ways that none of us can imagine now. This wouldn't be possible if the GUI dictated an XML file as the only channel for configuration. So, can I try implementing it yet? :) > there were some opinions about "fancy" or "pretty" gui features. i think > we have to (try to) differentiate between "personal style" and > "readability/usability". > the personal style differs, but there are some points in terms of > readability, that can definitely be used to evaluate certain features: > - the bezier-curved connections for example increases the readability of > patches. http://klingt.org/~tim/readability.png shows an example, > showing two functionally equivalent patches ... the curved connections > are way more readable ... using straight lines, one connection would be > hidden > - highlighting hovered connections, is also a very handy feature, as it > provides an immediate visual feedback > - i am not sure, how the round xlets increase the patch readability, > though. http://klingt.org/~tim/xlets.png shows one of the help patches > in both versions. they look definitely more fancy than my ugly xlet > boxes, but the boxes are visually more discrete than the circles. in one > case (bang -> list resize 4410), the circles even have a worse > readability than the boxes, as the connection is not visible, when > objects are placed too close together. > > in general, i prefer to have a clean and readable interface. "clean" and > "fancy" are not mutual exclusive, though especially when "fancy" > increases the expressive power. we should also think about, which > features should be customizable. we should have some discussions about > use cases and evaluate the expressive power of different proposals. if > one approach can be judged as more powerful, why making it > customizable :) I totally agree. I think there is some conditioning among users of software that looked good but didn't do much that causes a negative reaction to all software that looks good. Just to make sure the record is clear, I dislike nice looking crappy software just as much as everyone else. I intend to make some changes of more substance later; I just picked something easy and superficial because it's my first time poking at the nova code. I tried to make changes that improved readability, but indeed a lot of it also involved personal tastes, and I really value accommodating other personal tastes through configuration. I agree on the round xlets. I'd venture a guess that you didn't create that patch with the round xlets, but if you had, the objects would be spaced so the connection is visible. However, I don't like them for a different reason. If you look at <http://unununium.org/~indigo/prettieried_nova_boxes.png>, look at the outlets on the top row of [osc~]s. On the rightmost two, there are some connections that go very close to those outlets, but look at first glance like they could be connected to the outlets. I thought they looked good and readable when they connections are drawn over the xlets (like the highlighted teal connections in that picture), but I wanted the connection lines to go under the object boxes. Unfortunately, there is no way to make all connection lines drawn over the xlets to which they are connected, but under the one where they are not. I'll experiment with some other shapes. A thought I just had: if the configuration is done through a sufficiently able programming language and not XML, it could use some heuristics to determine if the user is a pd user. Is pd installed? what's the atime on the executable? how many patches are in the home directory, and how old are they? If it decides the user is a pd user, it can make the interface uglier so that they aren't offended. Maybe it could even gradually make it prettier over the time of a year so they never even notice, until they go back to pd and realize, "hey! this is ugly!" :) _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
