Hi Guys,
my name is Steven and in the course of my software process lecture at Free University of Berlin I have to work on a OSS project.
I searched your issue tracker and think issues 890 would be a good point to start. And it’s maybe also some fun 
Do you have any suggestions concerning that ticket?
Hi
start reading the documentation about Spark Development in the document section of the Spark Dev community.
Willkommen an Bord!
Walter
I just wonder what this ticket is about. Where should Spark show that information about the current playing song?
As it’s common with other IM clients the title and the interpret of the current song will be used as a status message.
Hi,
also, there’s usually an option (button, keystroke, etc) just to paste a “now playing: Madonna - Like a Virgin” right into the chat box.
Greetings,
-Hendrik-
I think this should be a plugin, and not installed by default maybe. Or at least disabled by default in the preferences. Bosses don’t like when they see songs in the status messages
Hi,
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,
-Hendrik-
Can’t answer all of your questions. But i agree about the plugin approach. At first you can just use spark.properties file and store settings in there. Next you can store controls in the Preferences menu. Adding buttons would be a more complex task for you, but if you have time, you can do this. You can attach your source code here (in diff format). I will try to test it Not sure about the JUnit stuff, but probably you will have to go by author’s liability. Not many developers here to test everything.
Hi, attached you will find our plugin as a jar and a zip containing the source code. It contains a README file that explains what to do to build the plugin. Basically it’s just simple ant. We used github while developing the plugin so you can also take a look at https://github.com/hendrikb/Spark-Mediaplayer-Plugin.
We decided to drop the “Current playing song as status message” feature as it was not request by the feature request and it’s very complicated to realize on Mac OS X if you are not using Objective C and Cocoa.
The plugin adds a button to the chat window edit bar which can be used to insert the current playing song in your chat input editor.
We are looking forward for your feedback! But we have also some questions about your process: What will happen to our plugin? What do we have to do to get our code in your repository?
Greetings,
Steven
hendrikb-Spark-Mediaplayer-Plugin-75fd9cc.zip (691983 Bytes)
mediaplayer.jar (674040 Bytes)
Hi Steven,
great work. Works great with mac os and windows 7 for me. I ran the test you added and recognized that they failed. Found one mistake where you used equals instead of contains to test the mac os and windows factory.
Maybe the test should not fail when we’re on a windows machine and try to test the mac os specific implementation and vice versa. (patch added, see below)
I guess we could add the source code to the trunk without adding the plugin to the default build for now.
In my opinion there are only 2 things that have to be done until we could commit it into the svn:
The button, currently labeled with "np: ", should show a small icon like a speaker or something like that.
Remove the sysout’s from the sourcecode. (or replace with log.d)
I’m looking forward to get those things done
THUMBSUP
mediaplayer-tests.patch.zip (1520 Bytes)
Hi Holger,
thanks for your comment and for the patch. We agree that it’s probably the best idea to provide the plugin in the default distribution, but let it be deactivated until someone decides to use it. We also agree on the necessity of an icon. As we said, this was basically a proof of concept and we’re polishing that stuff until this week’s end.
In case it looks like we debugged our code with sysout we only can say: Nope, we were… ehm… working a lot with the console. We gonna run over our code once again to get rid of things like that.
Thanks again for the feedback.
Grüße aus Berlin,
-Hendrik-