Wednesday, June 25. 2008
Amarok Scripting SoC Project - Week 3
My SoC student Peter Zhou has interesting news about his progress with Amarok 2's all-new scripting system. I'm pasting his blog here, as he is not yet aggregated on Planet KDE.
Before that, let me fill you in with the details about our plans for scripting in Amarok 2:
What you can expect is something similar to Firefox's extensions. With one big difference: Amarok still aims to provide a rich feature set out of the box. We believe that an application should be usable without forcing the user to do Lego (TM) building
Peter writes:
I’ve been at home for three weeks, was with my family and had a three-weeks-leisure-break.
Finally, I am sitting here to talk about my summer of code project. I am sorry about the first three weeks break, I really do. But I did try to get familiar with the development environment and tried to hack some code. I am going back to campus in Hong Kong in two days, I can thus concentrate on my SoC project.
For a long time, I was trying to understand what is going on there. Trying to think what the other developers think. For the first month I joined the community, I was amazed that Amarok folks are so in love with what they are doing, and have so much passion on it. Different from my past projects, Amarok is a rather large project, different developers had different views on the future way.
For the first time, I am feeling myself being pulled to the bleeding edge. I compiled QT for four times in two different platforms (How many times for kdelibs and kdeRunTime?). I realized it is sure a though learning process. Playing with the fresh new hot stuffs, I am pretty happy with this.
In the first week, I was busy with my exams, and cleaned up the existing dbus interface.
For the second and third week, I had a slight trip with my girl friend, set up a new Leopard development environment, tested the MPRIS support, and made my first commitment to KDE svn server.
I did some paper work, studied a little with scripts, and I am now quite clear with my goals for the coming busy July.
I made my mind to immigrate everything to qtscript from dbus. I would keep the MPRIS stuffs (PlayerDBusHandler, RootDBusHandler, TracklistDBusHandler) for dbus interface. And the other functions will be scriptable through qtscript. (both ruby and python need additional runtime dependencies, but not qtscript. The simpler the better)
Compare to the current functions, I will add more signals since the signal mechanism are rather easy to be achieved using slots and signals. For example, signals like trackEnd ,trackChange, SeekingTime, configurationChange and etc. would be added.
The second change I will make is the scriptable GUI. You will be able to add buttons, menus, lists using scripts.
Before my visiting to Belgium, I will make a easier use script manager which include upgrade checking, simple dependency checking (to check Amarok version and optional packages for Amarok which will be also needed by scripts).
I am so looking forward to the coming working days and nights. Hopefully, I can work out a brand new scripting interface in one and half months and thus I can start a new script project during my visit to Europe.
Peter's original blog can be found here.
Before that, let me fill you in with the details about our plans for scripting in Amarok 2:
- Amarok scripts are based on QtScript (= JavaScript)
- Scripts are running in-process, as opposed to Amarok 1's way of running them in a separate process
- The new script manager will be able to do version management, and possibly automatic upgrades
- The scripting API will be much richer and it will be possible to extend the Amarok GUI with scripting
What you can expect is something similar to Firefox's extensions. With one big difference: Amarok still aims to provide a rich feature set out of the box. We believe that an application should be usable without forcing the user to do Lego (TM) building
Peter writes:
I’ve been at home for three weeks, was with my family and had a three-weeks-leisure-break.
Finally, I am sitting here to talk about my summer of code project. I am sorry about the first three weeks break, I really do. But I did try to get familiar with the development environment and tried to hack some code. I am going back to campus in Hong Kong in two days, I can thus concentrate on my SoC project.
For a long time, I was trying to understand what is going on there. Trying to think what the other developers think. For the first month I joined the community, I was amazed that Amarok folks are so in love with what they are doing, and have so much passion on it. Different from my past projects, Amarok is a rather large project, different developers had different views on the future way.
For the first time, I am feeling myself being pulled to the bleeding edge. I compiled QT for four times in two different platforms (How many times for kdelibs and kdeRunTime?
). I realized it is sure a though learning process. Playing with the fresh new hot stuffs, I am pretty happy with this.In the first week, I was busy with my exams, and cleaned up the existing dbus interface.
For the second and third week, I had a slight trip with my girl friend, set up a new Leopard development environment, tested the MPRIS support, and made my first commitment to KDE svn server.
I did some paper work, studied a little with scripts, and I am now quite clear with my goals for the coming busy July.
I made my mind to immigrate everything to qtscript from dbus. I would keep the MPRIS stuffs (PlayerDBusHandler, RootDBusHandler, TracklistDBusHandler) for dbus interface. And the other functions will be scriptable through qtscript. (both ruby and python need additional runtime dependencies, but not qtscript. The simpler the better
)Compare to the current functions, I will add more signals since the signal mechanism are rather easy to be achieved using slots and signals. For example, signals like trackEnd ,trackChange, SeekingTime, configurationChange and etc. would be added.
The second change I will make is the scriptable GUI. You will be able to add buttons, menus, lists using scripts.
Before my visiting to Belgium, I will make a easier use script manager which include upgrade checking, simple dependency checking (to check Amarok version and optional packages for Amarok which will be also needed by scripts).
I am so looking forward to the coming working days and nights. Hopefully, I can work out a brand new scripting interface in one and half months and thus I can start a new script project during my visit to Europe.
Peter's original blog can be found here.
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Hi
Isnt it going to use KPluginSelector like Kopete, Kate, Konqueror and KWin?
Isnt it going to use KPluginSelector like Kopete, Kate, Konqueror and KWin?
Yea sure it could, nothing on this blog says otherwise. KPluginSelector is just a UI I believe. Thanks for reminding us though.
We've considered it, and I prefer Ruby too. But we want to get rid of the dependency hell that exists with Amarok 1 scripting, especially in light of the Windows port.
That's why we decided going QtScript only, which is sufficiently powerful and requires no depencies at all. It's built into Qt4.
That's why we decided going QtScript only, which is sufficiently powerful and requires no depencies at all. It's built into Qt4.
But Amarok already depends on kdelibs and kross is a part of kdelibs...nah?
The issue isn't Kross itself, but the languages Kross uses and the wide variety of libraries those languages require.
Anyways what we code this summer doesn't have to be the end of the story. But I think QtScript + Qt bindings provides a very powerful development environment without as many dependency issues.
Anyways what we code this summer doesn't have to be the end of the story. But I think QtScript + Qt bindings provides a very powerful development environment without as many dependency issues.
You misunderstand. The point is to not having scripts depend on Ruby, Python, Perl, Bash, or whatnot.
With QtScript, every Amarok user will be able to run any script, on any platform, without additional dependencies.
With QtScript, every Amarok user will be able to run any script, on any platform, without additional dependencies.
Except they'll have a lot less scripts this way... I for one don't see myself (happily) hacking in JavaScript and I'm pretty sure I'm not the only one. The current approach might not be perfect (though Qt bindings are common place now and the language itself is hardly a problem) but this "solution" concentrates a bit to much on the problem aspects at expense of the scripting aspect. Surely you'll get less (of those) users complaints like this, but that will be partly because they'll have less "things" to play with. Anyway, I know it's to early to tell... who knows, maybe the desire to tweak something will be enough to overcome my (and others) initial repulsion for the chosen language 
My thoughts exactly. I also understand what the Amarok devs are trying to avoid (and they have [very] good reasons to do it). It has become a trend: users users users... will nobody think of the developers!?
It might be for the best in the long term. Though, as with Debian 5.0 releasing with KDE3, it saddens me a little.
It might be for the best in the long term. Though, as with Debian 5.0 releasing with KDE3, it saddens me a little.
Hehe.. yes, it's a trade-off, really. Do we prefer the developers' convenience, or the users' convenience?
I think that our goal should be to make the experience as smooth as possible for our users, even if the developers have some slight inconveniences, like learning JavaScript (which is pretty easy, btw).
I trust that we will still get a wide variety of good scripts; it works very well for Firefox after, all.
So, try to see it a bit positive: Your script will also get more (happy) users
I think that our goal should be to make the experience as smooth as possible for our users, even if the developers have some slight inconveniences, like learning JavaScript (which is pretty easy, btw).
I trust that we will still get a wide variety of good scripts; it works very well for Firefox after, all.
So, try to see it a bit positive: Your script will also get more (happy) users
Script writers are users too. Just sayin'. Though for an open source project they are the most valuable kind of user, the technically competent. So we really do love you guys!
Overall the job of script writers will be made a lot more easy. And with the possibility with even more powerful scripts. The scripts will actually be running inside the Amarok process after all, so it will be possible to extend the GUI and such. And Qt provides a very full featured set of tools to work with.
So I'd say overall things have definitely improved for the script writing users, while also helping out the users of the scripts being written by the script writers.
Overall the job of script writers will be made a lot more easy. And with the possibility with even more powerful scripts. The scripts will actually be running inside the Amarok process after all, so it will be possible to extend the GUI and such. And Qt provides a very full featured set of tools to work with.
So I'd say overall things have definitely improved for the script writing users, while also helping out the users of the scripts being written by the script writers.
A more powerful scripting framework it's good on its own and has definitely the potential to improve things. However, how much that framework buys you actually depends on how many people is willing to do something interesting with it (and that means developers, not users). I know it will be possible to do everything that can be done now and more, I just think that (initially, at least) there will be a lot less people interested in doing it. JavaScript might be a popular language within web developers but not so much within unixes users (your current contributors) for which anything else is a better choice (rightly so, because JavaScript -AFAIK- has no use for scripting outside the browser). This move has the potential to seriously reduce your current contributors pool, something which might not be a problem if (when ) Amarok becomes a big name in Windows, but that remains to be seen. Sorry for being reiterative. I just think you guys might be underestimating the impact this will have in potential contributors (saying that having to learn a new language -especially one so ugly as JS- is a slight inconvenience to developers seems rather naive).
) Amarok becomes a big name in Windows, but that remains to be seen. Sorry for being reiterative. I just think you guys might be underestimating the impact this will have in potential contributors (saying that having to learn a new language -especially one so ugly as JS- is a slight inconvenience to developers seems rather naive).
There is (or is planned for this year) a QtScript backend for Kross. That way QtScript plugins would not require additional dependencies and we (rubyists) could use our prefered language.
State of Kross in KDE4 (blog):
kdedevelopers.org/node/3187
Kross could also be used as a extension QtScriptExtension.
kdedevelopers.org/node/3187
Kross could also be used as a extension QtScriptExtension.
Even though I agree that ruby is an extremely nice language, I think the point Mark was trying to make was less about people writing scripts and more about the average user.
We get quite a large number of users on our Amarok irc channel who have problems getting this or that script working as they do not have the correct dependencies installed.
Allowing only QtScript, which will always be installed if you have Amarok installed, will, hopefully, greatly reduce this confusion. ( and as it gives you access to basically the full power of the Qt API, there should be much less need for installing other exotic dependencies as well )
We get quite a large number of users on our Amarok irc channel who have problems getting this or that script working as they do not have the correct dependencies installed.
Allowing only QtScript, which will always be installed if you have Amarok installed, will, hopefully, greatly reduce this confusion. ( and as it gives you access to basically the full power of the Qt API, there should be much less need for installing other exotic dependencies as well )
Our goal is not only to support QtScript, but also to keep away from other scripting languages which need additional dependencies.
Amarok Links
Calendar
Quicksearch
Categories
Syndicate This Blog
Blog Administration
We Listen To...
Powered by
