Monday, July 14. 2008GSoC Week 6: Amarok Scripting Interface
Hey, I have a lot things to demo since we were moving very fast In the past two weeks!
I've added a lot of QtScript API functions, including GUI, Playlist, Collection, Music Engine and Scriptable Service. Here are some small pieces from the whole cake: one of the engine signals: function TrackChanged() { print( "Dude! Do something! The track changed!" ); } Engine.trackChanged.connect( TrackChanged ); Track Meta Info: var TrackInfo = Amarok.Engine.TrackInfo; StatusBar.shortMessage( "You are listening to album: " + TrackInfo.Album ); Collection and Playlist Access: var totalTrack = Amarok.Collection.totalTracks; Amarok.Playlist.clearPlaylist; I've almost finished the DBus interface by supporting MPRIS standard ( http://wiki.xmms2.xmms.se/wiki/MPRIS ). Now the script manager could handle script errors, write them to log files and correctly start/stop scripts. A simple demo script and a scriptable service QtScript called "Cool Stream" was released with Amarok Alpha 1.  Everyone loves eye candy, the API implementation and bug fixing are mostly behind the scene. So I decided to make some candy for non-latin character users  .I grabbed the charset detector code from Mozilla, merged them into Amarok. Now, the wolf recognizes non-UTF8 tags:  The summer of code project seems always stuck on some building system stuff. The charset detector didn't compatible with cmake 2.4.8, and the Qt bindings generator was needed to be ported from qmake to cmake. ( thanks "compiling king" Ian for helping me  )The SoC project will be ended in one month. And we still have some work to do. Ladies and Gentlemen, let's wait for the finalized script API, and the brand new script manager! Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
The first screenshot doesn't look good, you have 8 buttons in a that small window, have you considered the use of a toolbar instead?
yes, that's a possible solution. I am working on the script manager layout currently. I guess artists are needed
Maybe use the same plugin selector that ktorrent or kwin use? It works pretty well.
i've been trying to convince our code-gurus that implementing the required abstraction needed for something like that isn't wasted effort - i'm not sure i'm getting through to them yet, though
 giggles In short - i agree, KPluginSelector would be the obvious fix for the rather funky UI here
When do you recommend people start using all these shiny new features to write scripts for amarok? Is enough of it in place now to start (I'm asking about lyrics scripts specifically)?
The APIs are not finalized yet. You may start to write scripts when beta 1 is out.
And the API docs will be ready by that time.
About the D-Bus interface; is it just MPRIS? Because I browsed through that quickly, and that doesn't specify things like walking through the collection, getting album art, or fetching lyrics.
 With the scripting interface, will it be possible to write extra functionality to do when tranfering songs to portable media players? For instance, I've got a Cowon D2 that can show album art and store text files. I'd love a script that could get the album art for a song, run it through image magic to make it the right size, save it the song folder as "cover.jpg", and then get the lyrics and save them to the text folder in the same hierarchy as my music folder. I wrote a script that did that using the previous dcop interface, but it was inconvenient because I couldn't figure out how to execute it on-the-fly when files were being transfered to the player. Amarok is awesome, by the way, and I'm sure you guys are doing an good job writing Amarok 2!
Please read this blog article, it explains the new scripting system:
http://amarok.kde.org/blog/archives/705-Amarok-Scripting-SoC-Project-Week-3.html
The media player service is currently under heavy development, so I cannot tell want kind of APIs there will be supported in Amarok2. Anyway, you are not recommended to use DBus to write scripts for Amarok2. DBus is for external applications only. We have introduced QtScripts in our new scripting interface, which is totally different from the previous version.
I was thinking that a Now Playing plasmoid might need to use D-Bus to get the Album Art, and a really fancy one might even want to display the Amarok lyrics.
But mainly, as long as I can add some control over media file transfer, that would be awesome. I thought of another thing too, if I could write a plugin that would sync my media player with my Amarok collection, but only tranfer songs meeting a certain criteria, like above 2 stars. Or add a function that will copy all songs above a certain beat per minute to my "exercise" folder. (It might need to use another program to determine BPM, I don't think it's an IDE tag normally. Hope QtScript supports executing binary programs and reading their standard output.)
Hi,
I'm interested in ID3 character encoding issues with Amarok. I have an app in alpha stadium that can be found under code.google.com/p/id3encodingconverter/ Planning to make it useable together with Amarok. If you're interested ping me.
What's nice about Peter's solution is that it doesn't require any conversion: it just detects what the encoding is (using code from Firefox) and then displays it correctly.
I'm sure there are still other reasons to convert your id3 tags to UTF (eg make them work on your portable device), but now Amarok isn't one of them.
I wanna disagree on that. Peter's solution sounds cool, but it's success depends heavily on the quality of the detection. After all you only have approx. 30 bytes (aka 10 chars) for detection. So if your detection fails you want to have a permanent solution.
Furthermore as Amarok is cool for your portable music you want to convert and not detect on the fly. Either way, can't wait until I can try it out. Btw, we need more developers from Asia!
Currently the situation is that if you have non-ASCII non-UTF characters in ID3 (which is against the spec of id3), Amarok displays garbage. Peter has hopefully fixed this. It might take the final release to get enough feedback to know if it works for everyone, but don't be so pessimistic.
Um, yea we agree that it might be useful for media players.
Preliminary tests have shown that the detection works quite well, about 90% hit rate.
Thanks both for your reply. 90% sounds good. I have a test case of mainly GB2312, I guess less than Peter, but I'll try it out, too, once Debian ppl get some packages out (dunno if anything is planned).
You can get another 5% if you weight your character encodings in use. I guess most of us won't have any TSCII around, so you might vote it down in favour of other encodings. Idea: Get out of the box weighting by checking the user's language and look up what ppl with his language like to listen too (e.g. German: German, English -> Latin-1, Chinese: Chinese, Japanese, Korean -> GB2312, BIG5, JS*, EUC-*). Breaking a fly on the wheel? I'm optimistic
I don't really agree to make it complicated. the conversion program is good enough to keep it external, but too large to be merged into Amarok. I guess most of the users won't appreciate that feature.
Writing tags, I agree. For conversion on the fly though I would welcome any improvement.
I believe the focus of users currently lies on the western part of the world with Latin-1 being overly represented. But in a few years I believe, or at least hope, that this will change. So while ID3 tagging works for estimated 80% of the people right now without any flaws, this might change. Sorry btw, for highjacking this blog post, as charset detection was only an example of what is possible
To be fair... that focus exists since ID3 never supported non-latin1 local charsets. Just a lot of poorly written taggers did it anyways.
Was Qt charset detection insufficient? Can you talk to the trolls and see what needs to be added to make Qt able to do this without every app ripping mozilla's code?
I wasn't aware that Qt had any. There's something to detect if its local-encoding or UTF I believe, but thats it.
I asked Will by mail and he said he mixed it up with the KDE stuff. [1]
But his point is good: Amarok isn't the only one that needs charset detection, it's a fundamental problem. So if the Mozilla detection is way better than the kdelib one then one might consider porting. Regarding "To be fair [...]": Either way, if we can fix it all the better [1] http://lxr.kde.org/source/KDE/kdelibs/kdecore/localization/kencodingdetector.h
Well, yeah, if you've got an improved charset detection routine, don't hog it for Amarok alone. Make it shared so other KDE programs can use it! Um, but obviously that's a task that'll have to wait for after 4.1 because of feature freezes. But at some point when it makes since then? Or maybe see if Qt doesn't want to incorporate it directly somehow. My 2 cents.
I don't understand the API of KEncodingDetector. It detects the encoding but you also have to specify a locale?
|
Amarok LinksCalendar
QuicksearchCategoriesSyndicate This BlogBlog AdministrationWe Listen To... Powered by
|
|||||||||||||||||||||||||||||||||||||||||||||||||
