Hi Garth, > My spidey sense tingles a little when I hear talk of dropping XML > configuration in favour of a scripting approach, particularly because > of the accessibility and maintainability aspects...
Yes, this worries me as well. Hence why I was thinking of providing some convenience methods which make life equivalent to writing xml files but I still see your concern. My worry with hybrid stuff is the amount of places you may want to hook between the xml and script, you may want a dedicated handler for a certain event, or you may want just to process a value or you may want to handle a whole class of events (which with the current xml layout would require loads of <control> blocks all pointing at the same functions) or you may want to do everything in script for really crazy controllers. So it seemed to me that most of the complexity in an XML+script scheme was involved in trying to keep the XML involved. This is just my thoughts anyway. > > I think a scripting only or scripting primarily approach would take us > in a direction away from being able to drive configuration through the > use of tooling (i.e. MIDI training or mapping controls through > diagramming). Yes. I forgot about this to be honest. It is a bit of a bugger. We could still work something like this in though. If we're careful about how we map objects onto each other on the c++ side and keep track of everything we could have a fairly object oriented/modular layout of things, you could run a config file and see what structure it creates and then be able to write that back. Perhaps this calls for some separation of the code and the actual connections. Perhaps now we're back to XML + script... > > I do however see merit in having scripting a part of the configuration > process particularly for handling mode changes in controller hardware, > where buttons are dynamically mapped from one set of functions to > another... Yes and also just generally for providing more complex behaviour, for example you could code one of those powermate one big wheel type devices to scratch on whatever player has most of the crossfader or something. If we bind in Qt, you could even create a dialog box allowing you to switch between multiple mappings for a controller or change sensitivity and things. > > Earlier this week I started reading up on some stuff that trolltech > put out about SCXML > (http://labs.trolltech.com/blogs/2008/11/08/entangling-the-signal-slot-spaghetti-with-scxml/). > Ok. I had a look at this stuff. My understanding was that although this provides the state machine itself you still need some code to interpret the state of it. I don't know, maybe I'm wrong. But I was inclined to agree that this could end up being more complicated. Also it would presumably be less general as well? But anyway the more I think about what you say above, maybe we can combine everything and make everyone happy. What if we basically translate my midiConnect idea back into the XML, so something like: <control> <midicodesource><code>0x80</code>... <functionprocessor>Steve()... ... and for backcompatibility a <simplecontrol> or something And then put the relevant code somewhere else, either embedded in some <code> tag or in a separate module. Then you run the code, let it register it's functions and so on and then use the xml to set up the static part of things. Then the static part is as well separated as possible and open to inspection and you can still do something like: <control> <sourceall/> <functiondestination>mymodule::handleeverything</... if you need to. ??? Adam ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
