On Wed, Sep 26, 2007 at 06:30:01PM +0200, Tim Blechmann wrote: > hi phil, > > > I've given some thought to a gui preferences mechanism and discussed it > > a bit with niklas on IRC. The idea is to make some gui objects that > > accept messages and respond by changing visual or other preferences of > > the gui. This has some advantages over a methods like a plain text file: > > > > - preferences can be changed at runtime by a patch. So, a particular > > patch might change colors of some connections or whatnot to indicate > > state. Or, the visual aspects of the interface might be changed in > > response to the music as part of a combined audio and visual live > > performance where the patching is visible to the audience. > > > > - saving the preferences is just the same as saving a patch. If the gui > > loads a patch in a standard location like ~/.novarc on starup, that > > patch can include some things rigged to a loadbang which set the desired > > preferences (and a lot of other things, too) > > 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) > > - 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 ... > > - 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. > > - the configuration file would be read by the gui to set up the gui, but > should be independent from the configuration file for the engine. so > ~/.novaguirc should set up the gui preferences, while ~/.novarc is used > to set up the engine and can be used by both the gui and the > command-line interpreter
Well, the "engine" is actually a "language interpreter". I don't think it makes much sense to have a configuration file for a language interpreter. This means the semantics of the language vary from site to site, which is a dangerous idea. PHP tried it, and you'd be crazy to say it's a good idea (magic quotes, anyone?). The Python lanugage itself has no configuration. The 'python' executable allows some configuration, such as setting environment variables like PYTHONPATH. Still, this isn't anything you couldn't do in the python language (sys.path), and in fact there are quite a few usages of python which do not include these configuration channels (most of them python interpreters embedded in other applications) The engine is completely useless without an interface. Without it, it's a concept or maybe a library implementing that concept, but not something that a computer can execute. What you may have are multiple interfaces to the same engine, and different configuration files for each. Some interfaces may provide a superset of the others, so it would make sense to be able to share configuration files. What do all interfaces have in common? The ability to evaluate the nova language. As an example, Vim has a terminal variant "vim" and a graphical variant "gvim". Gvim does everything of "vim", and more, so it reads ~/.gvimrc in addition to ~/.vimrc. I should note these configuration files are written in a programming language, and because of this, people can do damn clever things. For example, the vimrc shipped with debian conditionally sets vim's settings to conform to the debian code style when editing a file in filesystem paths likely to contain debian code. I don't think you can do that with XML. Hans Reiser put it this way: "The utility of an operating system is more proportional to the number of connections possible between its components than it is to the number of those components."[1] Of course the same applies to any system. XML doesn't connect with anything. It doesn't have file io, it can't read from a pipe, it can't do anything. The nova language on the other hand, connects with a hell of a lot of things. It is a language explictly made for allowing a nearly infinite number of possible connections between a small number of things. It seems you reject my idea because you are striving for some separation between the "engine" and the "gui", but I wonder what this really means. The engine is a definition of a state machine. The interface provides the knobs, levers, and lights to run it. The engine doesn't define what the knobs levels and lights look like or how they work; it just exposes its state and defines the ways the state can change. This is the "separation", i think. With that definition of separation, I don't see why the engine must exclude features just because they may be of use to the interface. Say the GUI decides what color something should be by reading some sort of variable which can be set through the engine. This doesn't mean that the GUI and the engine are no longer independant. It's really no different than the mechanism the GUI uses to decide that it should draw an object, or that some xlets should be connected. In all cases it's just reading state and representing it in an interface specific way. If the engine provides a general mechinism to store and retrieve numbers (variables, essentially), then I don't see why anyone should say the GUI must not use them for its configuration. Sure, any patch that depends on their existence is invalid outside the context of the GUI, but if this is just the GUI configuration patch, why does this matter? Furthermore, it opens the possibility of writing patches which do depend on these things. Yeah, they aren't portable, but how is this different than writing a program in C that requires libportaudio? Yeah, you could have implemented portaudio from standard C primitives, but why? If what you want is a program which displays your pd patch graphically, and changes the background to flashing teal and pink every time you enter the chorus of your song, why should you have to do it from scratch when there is already a program that does the hard part? > [...] [1] http://www.namesys.com/whitepaper.html _______________________________________________ nova-dev mailing list [email protected] http://klingt.org/cgi-bin/mailman/listinfo/nova-dev http://tim.klingt.org/nova
