Hi guys, If we're talking about serialization, the bigger issue here is the fact that we don't really do it properly in Mixxx at all. 99% of the classes inside Mixxx are not able to serialize themselves. What format you serialize into and what you do with the data after serialization doesn't matter very much.
If you're talking about replacing our ConfigObject framework, then yes, something like this would make sense. If you're talking about having Mixxx's classes being able to serialize themselves, that's just a lot of coding we'd have to do ourselves, what you use to save your data doesn't change anything. So there's a couple of things on my mind about this: 1) What are the advantages of replacing ConfigObject with something similar? An easier API? Slightly more flexibility in the types of data that can be saved? Is that really a shortcoming? 2) Ideally you don't actually want to have anything like ConfigObject. If every class could serialize itself properly, then "saving the preferences" would just be serializing the SoundManager and SoundDevice objects, serializing the EngineBuffers, etc. If you wanted to save a session, you'd serialize the (non-existant in trunk) Player objects, and the (non-existant) Mixer object which would have all the mixing parameters in it, etc etc. 3) This isn't worth dragging in an extra dependency over. If you want to replace the same crappy settings saving capability, use the QSettings class or something stupidly simple like this: http://pastebin.ca/1320952 4) Doing serialization of classes inside Mixxx correctly after it hasn't been done at all is going to be very very difficult. This is the sort of thing I'd hope we'd do correctly if we were to start over. I'm not saying I know how to do it correctly myself, but I've done basic DIY implementations in applications and the good results make it definitely something that I'd want to investigate more. (The Boost serialization docs are an interested read, and point out some use cases I had never thought about before.) Thanks, Albert On 28-Jan-09, at 10:34 AM, Nick Guenther wrote: > On Wed, Jan 28, 2009 at 12:58 PM, Garth Dahlstrom <[email protected]> > wrote: >> >> On 28/01/2009, Ben Wheeler <[email protected]> wrote: >>> On Wed, Jan 28, 2009 at 08:18:48AM -0800, Mark Glines wrote: >>>>> serializing data structures as `eval'able code (something that's >>>>> quite >>>>> in vogue in the Perl world, and I regard as Pure Evil.) >>>> >>>> Actually, I think YAML is more popular in the Perl world these >>>> days. >>> >>> YAML is what I tell people they should be using instead of >>> Data::Dumper >>> and eval. >>> >>>> For a simple list of config items, its about as easy to read/edit >>>> as an >>>> .ini file would be. More complex data structures are also >>>> possible, and >>>> they look a heck of a lot nicer than XML does (in my opinion). >>> >>> Agreed. It's about as intuitive and self-documenting as any >>> comprehensive format I've seen. >>> >>> Ben >> >> Hrm... Just reading up on wikipedia about YAML, I quite like what I >> see so far. >> >> In a way it reminds me more of wiki mark-up then anything else and I >> could see the relational ability to do value referencing and >> inhertience could prove quite useful in some situations. > > > I would not be opposed to YAML. Anything less crufty than XML... > -Nick > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
