On Thu, Sep 27, 2007 at 12:30:54AM +0200, Roman Haefeli wrote: > On Wed, 2007-09-26 at 18:30 +0200, Tim Blechmann wrote: > > . i am curious, what other people think about these features ... > > hi tim, hi phil and others > > since i am running a quite outdated system (ubuntu dapper), i won't be > able to test nova myself, until i update my system (which probably > doesn't happen before summer 2008, when i'll have finished my diploma). > > yo, i first i have to make clear, that tastes can differ heavily. what > you, phil, describe as 'pretty' or 'prettiered' is for me just the worst > case scenario. personally i love much pd's beatutiful plainness. since > it's something, that i am probably looking at everyday for some hours, > it cannot be plain enough for me. what i would like to have in nova is > definitely not a 'prettiered' gui, but rather some cool gui stuff > already built-in (envelope generators and stuff like this). i also > think, that i would have troubles reading a patch with all the curvy > cables all over the place. > for me, the appearance of pd reflects the fact, that it is quite a 'low > level' language, that can be used to program, not only just putting some > highlevel pieces together (unlike 'native instrument's reaktor), a patch > is for me a program, not just a set of modules put together (as a > reaktor patch). so for me a simple appearance is much more suitable in > the nova context, which i would wish to be a programming environment for > me. the cables in the 'prettiered' gui remind me much of the backside of > reasons racks and the whole appearance make me think of something like > 'reaktor' rather than pd or max. and i also believe, that i am part of > majority, otherwise max/msp would look much more like 'prettiered gui', > i think. > my two cents: let's have a simple and clean gui. > > > a few thoughts on the ideas: > > > > - gui objects should definitely provide some message handlers, that > > change their appearance in the patch ... maybe in a similar way, than it > > is done in pd (not sure how max handles this) > > yeah, i think for the gui-objects, it would be cool to have all > propierties adjustable from nova itself (as in pd's iemguis). i also > think, that having a label for each guiclass, that can be adjusted from > nova itself is quite essential. pd does have it, but with some > restrictions: you cannot set labelnames, that have a whitespace in it. > > > - however, non-gui objects (normal object boxes, connections) should > > follow one style, maybe the appearance can be changed from a property > > dialog, but it is not accessible from the dataflow language, which > > should basically be independent from the gui ... > > agreed > > > - i also don't really like the idea of having a nova patch, setting the > > preferences. i know, that some systems use this approach, but it is a > > bit contrary to the approach of having the nova language and the nova > > gui separated from each other. in terms of readability i would somehow > > prefer to use a configuration file (possibly xml) to store the gui > > preferences. > > without beeing an expert at all, i think the same. i can only speak for > myself, but when working on projects, that require an interface, i > usually create a separate gui-patch, where you don't see any code at > all. since at the end only gui objects are visible anyway, because the > rest code is hidden in other subpatches, there would be no point in > having a settable appearance pd. so what nova tries to do with the > separation of language and the gui, is something, that i usually do as > well in my patches. following this idea, it wouldn't make sense to have > the appearance customizable from within nova. for me, the only reason to > adjust nova's appearance would be to improve patch readability, but > definitely not to design a patch, since in my opinion guiclasses should > be used for that. > > yo, i hope i didn't talk bullshit here....
I don't see why there is so much oposition to the idea of twiddling gui preferences from the nova lanuage. Yeah, usually you write patches to make music and not care about gui settings, but nothing is forcing you to set gui preferences in any of the patches you author. Indeed in practice no patches would probably do this, and there are good reasons why. However, I see no reason at all to go out of one's way to make such things impossible. If you look at projects in the past, again and again it has been demonstrated that having general purpose programming constructs in configuration files is a good idea. Just thinking of programs I have used in recent memory: - vim: propritary programming language - scons: python - ion: lua - emacs: lisp Just picking out scons as an example since it's used by nova, what makes it better than make? Well, probably the biggest difference is that it's "makefiles" aren't some horribly limited custom language, but instead are PYTHON. You don't have to look far to find a project that has used this power to use in creative ways that the scons authors never imagined. Sure, it doesn't hurt that without any special treatment that scons just sucks less than make, but the big win is that when you want to do something that the authors didn't think of for you, you can probably do it if you can do it in python, which is to say, scons is almost infinitely extensible. As I mentioned before, plenty of projects have ignored this point at the start, and as they mature, they do one of two things: - embed an existing programming language - become a programming language (albiet usually not a very good one) Case in point, exim: http://www.exim.org/exim-html-current/doc/html/spec_html/ch12.html You'd think something as complex as an MTA would have realized extensible is cool from the start. But, they didn't. So, they added all sorts of extra syntax to their configuration file. It's probably turing complete, but still it's a pain in the ass to use and has limited I/O, so now you can embed perl in the configuration file by way of *string* *expansion*. What an unelegant hack! Then, many programs end up exposing ways to extend them at runtime. If you use Postfix, you might use this: http://www.postfix.org/SMTPD_POLICY_README.html If you expose enough things at runtime, you get to the point where the configuration can be a program in whatever language you used to expose your runtime that just gets executed at start. Postfix isn't at this stage, but ion is: http://www.postfix.org/SMTPD_POLICY_README.html Especially important to note is that ion wasn't always this way, but rather, because at some point the author realized he can't anticipate everything the users might want to do. As it turns out, if you expose your program like this, you get a lot of contributions from users of little programs that make your program more useful. Check out <http://www.vim.org/scripts/index.php>. Also, users are happier with the software because they can integrate with their other stuff. Obviously you understand the value of being able to connect things in a multitude of ways, or you would not be considering nova! One thing I read in your arguments (and tim's) is, "yeah, it makes sense to make some things extensible, but I can't think of a reason to make these other things extensible now so we should make it impossible in the future." Well, if already it's possible to change the color of something things from nova, it's not really any harder to be able to change the color of other things. To the contrary, you are suggesting that another syntax be developed, along with code to parse it and do something with it. This is *more* work, not less. This is advocating a more complex solution to obtain a less capable result. I just don't see the point. Also, you mention that the interface is too fancy. I think I can agree partially. Personally, I think this interface is more readable. I think the connections are easier to follow when they cross because they are not monochromatic, and I think it's less confusing when the outlet is lower than the inlet because the shape of the line (always going down initially from an outlet) gives my brain a good cue that this connection is going backwards from normal. I think the slightly transparent boxes make it easier to follow the connections when they are covered, while simultaneously not obscuring the box. Still, I'd prefer to have a responsive and readable interface to a good looking but useless one. I intend on making the interface quite configurable to accomadate personal tastes and hardware resources, which is why I've been mentioning the configuration issues. I'll be sure to implement a pd theme for people that somehow like ugly interfaces :) _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
