Akademy: Let’s talk about music player and documentation
Hey,
I’ll be at QtCon and Akademy in Berlin, mostly as observer, I guess 🙂
I’ll have also two workshops/discussions on Tuesday 6th (see [1]).
Music player
For some time now, there were threads [2] about designing a new music player. The VDG people came up with a vision and some first design ideas [3] and I built a first specification page on the community wiki [4].
I’ll do a workshop which will deal about:
- what will make this player not just another player
- feature discussion
- architecture design
- use of the public libraries of plasma-mediacenter
- …what you want to add…
The first 3 points will be mostly a presentation of what I want to do, with discussions about how it can be done better.
I already wrote some code, but it was mostly to make some experimentation, the project was put on hold until this Akademy session, in order to start on the right basis.
Documentation and KApiDox
I also reserved a slot for KApiDox, the program that generates the api.kde.org website. The codebase changed a lot lately, and more and more projects are being generated. However, it’s still not very robust to errors (the whole process would break instead of just ditching the error source) and it appeared not to respond to every usercases.
If you think our API documentation is important and can/should be enhanced, please join the discussion so that I can know your needs (as API user or API writer) and enhance the whole thing in the future.
Links
[1] https://community.kde.org/Akademy/2016/Tuesday
[2] https://forum.kde.org/viewtopic.php?f=285&t=122273
[3] https://community.kde.org/KDE_Visual_Design_Group/Music_Player
[4] https://community.kde.org/Playground/MediaPlayer
11 comments
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
I used to *love* bangarang, an old music player from KDE. but the author disappeared, nobody started porting it to kde5, and puff.
now I use tomahawk mostly because it’s integration with online services (I don’t need gbs of space for my music if I have spotify or any other service) – but I’ll most probably setup a music box in the future to stream music at my house without relying on the internet.
What about talking about your music player a bit more? I’d be glad to hear (and help).
@Tomaz: Ok, I’ll write a post this week about what I have in head.
Sorry for dumb questions, is this gonna have the same functionality as amarok, plus the online integration you describe? If so, can’t wait!
And if so, why not hack on amarok?
The Amarok code base is quite old and I tried hacking on it, but needed help from the older contributors, which I didn’t get. In my very personal opinion, Amarok is a very nice project, which needs to be replaced by something newer. If someone still wants to take care of Amarok, he should prove me wrong, and I will only applause.
I’ll come on this in a next post: my idea of a music player would not have (at first?) so much context tools like Amarok. But it will be scalable, usable for big music libraries and play music.
Sounds awesome! Thanks for your answer! Would you plan this to be cross platform? Including mobile/Android version?
It will be crossplatform and is aimed at having the same backend for mobile/desktop, with only a different UI (to have the best experience). More on this later 🙂
Cheers !
Let’s forge the programmers’ resources into an other wasteful project, what a great idea!
– Why don’t you revive the already working Amarok project and expand it with the desired services?
– Why don’t you help into the already working Tomahawk if they’ve already have the desired online services?
Why do you feel the urge to forge the time of developers and designers with arguing on feature, architecture and UX design? Why do you need an additional music player besides Amarok, Tomahawk, Clementine, JuK, Kaffeine, VLC, Bangarang, Gnome Music Player, Rhythmbox, mpv? Why do you feel that YOUR player will be THAT special snowflake that no one could’ve been in the previous decade?
Yes, it WILL be just n+1 player with a ton of man-hours go wasted into this project starting with the Akademy presentation.
It WILL be a dead project within 1..5 years when you’ll finally reach the feature parity with Tomahawk/Amarok and you leave because of shortage of free time. And then, suddenly some newcomer realises that none of the already existing music players fit their need and they have to write a new one, again. And we, end users, could’ve enjoyed a much better experience in these years if this previous dev could’ve the vision to smarten an already existing code and not to write a new one completely from scratch.
First of all, if I accept your comment and the ideas you have, I think the tone is very wrong and deserves you.
About your comments: I tried Tomahawk and can’t get how it works. Too complex for me, and I only want to play local music.
I tried to work on Amarok, but the codebase is too old and older devs have quitted the channel. Bandaging and Juk are very old. I love QuodLibet and it would be my choice. Because it is the only player out there that can handle classical music. Cite me one player that can tell you who the first violin, component and directors are? Who is playing the banjo? To do that, you just can’t rely on a sqlite dB.
This is also part of the discussion at Akademy to know if we have manpower or not.
Next time, if you comment, please ask questions before judging and being cynical.
Please no f***ing Amarok again. The latest new I read about Amarok, was about a Wikipedia plugin and the other about Karaoke support – I mean WTF! – it’s a music player!
Amarok has been coded to death by dev’s and Gsocs.
So yes, time to move on, thanks!