sure thing. As Spark supports this superb sparkplug idea this whole thing should be implemented as a plugin and not be built directly into the core. I see that this is more of a ‘leisure feature’ therefor it should in no way be enabled by default.
BTW, my name is Hendrik and I’m Steven’s fellow in this matter. We both picked the mentioned issue for our software processes class at Freie Universität Berlin. This whole thing is about getting to know software development processes in open source projects… just in case you guys wonder why the two of us appeared straight out of nowhere and why we’re so actively reporting what we’re doing (that’s part of our weekly assignments).
We checked out the SVN tree and had a glance into the codes and found the sparkplugs dev guide to be extremely helpful. It’s pretty clear to us how we could extend Spark’s functionality by implementing the Plugin interface, dealing with configuration should be done by implementing the Preferences interface, right?
The whole Spark <-> $MediaPlayer interaction thingy should be handled by their respective libraries/bindings/APIs. We’re still looking for proper ways to deal with iTunes using Java on the various platforms. Google came up with some promising approaches [#1, #2], however, this could become the tricky part, because it looks like some of these things are basically hacks (means: any hints are welcome). As a part of a proper solution we’re planning to make the whole thing configurable and to support multiple media players (let’s say, we provide an interface for people to ideal with… we’re primarily caring about iTunes).
As far as the GUI is concerned, it’s probably a good idea to allow a global keystroke (configured in ‘Preferences’, not sure how keystrokes are meant to be implemented, yet. Any hints?) and maybe one or two buttons (“Insert ‘now playing:’ into the text box” and “set ‘now playing…’ as status”) in the EditorBar or in the ToolBar of a regular ChatFrame.
What do you guys think? Is this a reasonable approach? Do you see any problems?
We’re urged to provide test-classes for our code, JUnit-a-like basically, where can we put them? Is Spark using a standardized testing procedure in the context of plugins, or is it the plugin’s author’s liability to provide once-and-for-all tested code before releasing it into the wild? Most of the source code seems not to be covered by any kind of test code? What am I missing?
We’re looking forward to present some neat solutions soon.
Greetings from Berlin,