Amarok is slowly catching up
I was previously working on Macaw-Movies (already in the KDE Community) and, after a while, I felt really alone and wasn’t so sure if a movie organizer still made sense in this all-connected time, where you can stream whatever you are interested in.
I finally went to the Amarok guys, cloned the source and began to help to port it to the Frameworks.
The plan
Aroonav (roguedragon) did his GSoC on this topic [1]. And I catch up at the end of August.
What is the plan? In theory it was this:
- Remove all KDELibs from the dependencies
- Port the CMakeLists.txt
- Get to 100% of build
- Start the program without segmentation faults
- Port the tests
- Release and Party
- When sober again, port out of KDELibs4Support
In practice, build 100% is quite hard because as you may know, Amarok has a context part (in the middle by default) that relies comprehensively on Plasma (from KDELibs) and QGraphics(Item|Scene|...). This whole thing must be totally rewritten, from scratch, in QML. And that’s a hell of a work!
I decided at a certain point to directly port the main components out of KDELibs4Support. No more KUniqueApplication but a puzzle between KDBus and QApplication.
Where are we now?
Currently we did until 4 (no segmentation faults anymore) but didn’t port the context part. I still have troubles with D-Bus and Amarok cannot exit without being killed.
The unit tests are almost ported [2].
What is the next step?
I’m quite ashamed to say it but I’m always postponing the porting of the context part. I’ve never done any QML in my life, and I think I’ll have a hard time. That’s why I worked on the unit tests, and I’m still tracking some bugs in the current state of the porting.
Before August, I was always writing pure Qt, and never touched to KDELibs nor the Frameworks. I learned a lot of things, thanks to #kde-devel and the kde-devel mailing list. I often felt stupid as dfaure or tsdgeos redirected me to Techbase (because I didn’t know how to setup a good working environment for instance), or when I asked a question which answer was totally obvious… And I think it’s not going to stop before some time.
So see you around,
Cheers and have fun!
Source
[1] http://binaryspring.blogspot.de/
[2] https://git.reviewboard.kde.org/r/126005/
14 comments
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Nice. I’m already using the git version of Amarok, but I noticed that it has two main issues right now:
1. Some problems with Baloo. If I try to search anything in KRunner, Amarok crashes. Pretty annoying. Sometimes when restarted, the playlist gets cleared.
2. The playlist… does not actually display text. It’s all just two-pixel-height lines. The search works, and I can play the tracks, but the only way to tell which track it is is to first manage to put the mouse cursor on those two pixels, and then look at the tooltip. Again quite annoying. I could send you a screenshot if you’d like.
Using openSUSE Tumbleweed here, with wolfi’s repository, which conveniently packages the git sources: https://software.opensuse.org/package/amarok5
Yes I committed things about this yesterday… For your (1), no idea. For your (2) it should be corrected already…
I’m impressed that it’s already released somewhere, because, it’s not really usable yet 🙂
Ah, nice. Hopefully the package will be rebuilt soon.
As for the other issue, I wonder, could the problems be somehow related to the music file database or such being retained from the previous Amarok version? Because I get a crash when I go to Configuration, Local Collection, and press Full rescan (after the scan is done).
Perhaps I can give you a stack trace of the crash.
Yea, here’s the stack trace: https://paste.kde.org/pklnrl5lo
Not sure if all that helpful, since not much seems to come from Amarok itself…
Oh, and it crashes every time I go to local collections, too. Pretty much the same error:
https://paste.kde.org/piwfe1sjp
Looks like it dies due to ThreadWeaver’s IdDecorator. Perhaps something to do with decorated null pointers, as the comment on that line suggests?
And this is what happens when I press to restart Amarok in DrKonqi:
https://paste.kde.org/puontokn9
(Weird, looks like something related to Pulse…)
And the crash in KRunner can be stopped by disabling directory tracking.
I saw this, yes. For now I didn’t have time to find the source of this bug. Also, we can’t close Amarok normally, but I have to kill it.. Still don’t know why. If you are interested, you can give us a hand 🙂
Cheers
I’m interested, also interested in adding better support for MIDI files, but I’m way too busy with other stuff as it is.
Here’s another backtrace, of a crash right after boot:
https://paste.kde.org/pmwhahmff
The repository just updated and indeed both the issue with track names not being displayed as well as the Baloo crashes are now solved! That makes Amarok quite usable now.
The only annoyance right now is another crash that happens during session restore, see: https://paste.kde.org/pduw73j7x
Don’t ever be ashamed for learning. I spend quite some time trying to learn a thing or two and always scared from it. now I jump on things that I wanna learn. 🙂
As a Qt-Beginner a am curious: Why is QGraphicsView Framework bad and QML Better?
It’s not about what is good or wrong.. KDE made a choice which is that they want to rely on QML. And what is better in our case, is that it’s easier to maintain and to expand. But there is definitely no bad or good. It depends of the choices made on the project or community, and of the needs.
Instead of cobbling something together to fake the unique feature with dbus, you could use quniqueapplication. Check out the way it’s done in krita/krita/ui/KisApplication.cpp