Possible GSOC ideas

[Matěj Laitl]

On 24. 2. 2013 todd rme wrote:
> I am not in a position to mentor GSOC projects, but I have some ideas
> about possible project suggestions for the wiki.

Hi, thanks for them!

> 1. Support for multi artist/album/genre/etc. tags.  My understanding
> is that taglib supports this, but Amarok does not.  See:
> https://bugs.kde.org/show_bug.cgi?id=119539

Too big/complex/touching everything to be a GSoC project. But we roughly plan 
to do this in future, by gradually evolving our Meta objects framework. (as 
agreed in Randa 2012)

> 2. Port the contextview widgets to QML.  This is currently a big push
> in Plasma, including GSOC last year and this year, so it might be good
> to follow suit.

Definitely. We ran the same GSoC project in 2012 that didn't end up in code 
merged to Amarok master, so +1 for repeating this again. Hopefully we'll find a 
mentor (Teo? Bart?); I also don't know whether the student should pick up last 
year's pieces or start from scratch.

> 3. Port the mtp backend to use kio-mtp.

As Myriam said, MTP collection rewrite is already planned, although without 
the use of kio-mtp. (unnecessary abstraction layer, Amarok collections 
framework doesn't need a concept of underlying filesystem)

> 4. Support ffmpeg functions with gstreamer.  A lot of distributions do
> not ship ffmpeg for legal reasons, but do ship gstreamer.  This means
> many users will never see the functionality implemented using ffmpeg.
> This project would involve implementing the same functionality ffmpeg
> provides in gstreamer, while maintaining ffmpeg support.  When built
> with both ffmpeg and gstreamer, Amarok should prefer ffmpeg.

We use phonon for playing, so the only thing that needs ffmpeg directly is 
transcoding support [correct me if I'm wrong]. Amarok also happily works with 
libav's ffmpeg command wrapper. I also don't know about distros not shiping 
ffmpeg/libav in at least their "extended" repositories (which are often needed 
for mp3 decoding). Making our transcoding more flexible by using more backends 
would be a nice project, but certainly not big/useful enough to form a GSoC 
project.

> 5. Implement more flexible playlist layout setup.  This would include,
> for example, elements for the cover and song list, allowing users to
> put the tags beside the song list (useful for widescreen displays) and
> resizing the album art.  See:
> http://forum.kde.org/viewtopic.php?f=83&t=62463  and
> http://forum.kde.org/viewtopic.php?f=83&t=62462   and
> http://forum.kde.org/viewtopic.php?f=83&t=89973

Not a bad idea, but "go and fix these outstanding $component bugs/wishes" 
doesn't seem self-contained enough to form a good GSoC project, plus it may be 
too small. "Rewrite playback queue in QML fixing outstanding wishes along the 
way" could be a much nicer project, dunno whether not too big. This largely 
depends on whether we'll be able to find someone to give this more thought 
mentor this.

	Matěj