I'm waiting for instructions!.. i'm new here... i want to help but I don't know where I can start.. doing what... if someone that know a lot about this project supervise me and tell me some tips i 'll do something..
I've got a lot on right now (my own little projects (but they are small, a weekend's work at most once I actually get time), sorting out everything for the start of the new uni year etc.) but in a couple of weeks I'll have a bit more time (Holidays are busier than term time for me, bizzare ) so I'll see if I can contribute at all. Songbird's always been my favourite player so once I get myself familiar with the code and issues I'll hopefully be in a position to get things done. Sad to see you go stevo, thanks for the hard work.
I've been hacking around on various bits and pieces, and have setup songbird to use as many of my local libraries as possible, but here's a general roadmap using the current songbird svn trunk. It HAS to go in this order for things to work, with some allowances being that if we get multiple developers, we can focus on #1 and #2 at the same time, or even all of them at the same time. I have a git tree, so it won't be as difficult to merge changes.
I need some freaking help! Coders ahoy! Also, if you can take any of the below ahead of time (such as skinning) feel free. Branding still will come at the very last in terms of renaming every instance of "songbird" in the source code to Nightingale.
convert all songbird code to use a modern gecko 2.0 based mozilla/xulrunner. I'm working using version 6.0.2 and have a working build environment to produce the xulrunner and mozilla songbird build dependencies.
work over the songbird code that includes xulrunner (and builds songbird) to use the distro provided xulrunner libs (and mozilla sdk? not sure about that one) usually found in /usr/lib/xulrunner-version
other linux libs - get songbird using those instead of it's own (easier than the above)
modify the source files and build system so that songbird doesn't copy all the libraries it uses to it's own directory, so we can just end up with the songbird binary, it's plugins, components, etc ...saving disk space and not redundantly (and stupidly) using statically linked libraries in the songbird directory
renaming and reskinning - this doesn't matter until we actually build and distribute our own builds...as long as the source remains source code, and that's all we share amongst ourselves, we aren't violating any licenses
Yes, I'm working on getting builds off of the trunk working - their libraries are so old I can't build the SB deps for x86_64 (crazy)...
I'm trying to decide if I should work on getting a working SB build with x86_64 or just keep plugging away on the trunk to get it working with modern libraries (seriously, the deps are WAY out of date, and the i686 builds don't work with my multilib setup anymore).
I am able t build nightengale 1.8 after some mods, but I'd prefer to jump ahead to the sb trunk.
If you need some specific help, feel free to PM (bugzilla entries?) me. I'll see what I can do, especially with Windows building, and JS (and plain C++ without all the Mozilla); I'm not sure about all the XPCOM/Mozilla stuff but I *might* be able to help out there as well, but the only thing I did there was implementing Playlist Folders .