scripting proposal draft 3

[Peter Zhou]

Hi Seb,

Thanks for your feedback. I think I was too much concentrated on the
technical details instead of funcationality improvements.
Here I added two more paragraphs in the abstracting class part and script
manager UI part respectively,

Part 2:
Using the new script interface, we will be able to:
1. Add menus, buttons, bars to the current UI.
● Like the method I showed above, I will give access to every windows,
toolbars, buttons, menus, treeviews and listviews included in the
current UI. For example, we will be able to add a user defined column
in the playlist window using the script by giving access to the listview.
2. Response to some UI signals.
● Giving access to the widgets like buttons, bars, and etc. will
automatically allow the scripts to response to their signals, and some
other useful UI signals like "openUrlRequest", "VolumeChange",
"DeviceConnected" and etc. should also be added into the Kross
interface.
3. Use media, collection, playlist, device and Internet framework classes
(and their containers).
● Using the media class (and its container), we should be able to get and
set the meta info, change the volume, play and search the media, or
even have the method to rip CDs.
● The playlist class will allow us to add, delete, modify, build a playlist,
and to get extra information, like database info.
● The current device related functions are not polished yet, but it will be
still used as a separated class to connect, control and get info from a
specific device.
● The internet class should also be worked as a internal service, each
radio or internet service will be treated as a independent class.
● The idea of general class is like providing different services using the
existing Amarok functions. The proposal will not give the every detail of
the new abstracted classes or any functions, I will ask for feedbacks
and comments from the community about the content of the APIs and
the services provided by the new scripting interface before
implementation.

Part 3:
The goal of the script manager is to keep scripts updated and to make some
hard
rules when scripts communicate with Amarok, to insure the script is written
in
some scripting language not binary, have its dependency checked, run with
the
right Amarok version, run with the right platform, and etc.


Part 5 Road Map:
I will have my final exams by the end of May, but I think it is necessary to
have a
month to think and to discuss about the details of the APIs. So I plan to
have 20
hours/week to spend on the project in May. Then my summer vocation will
start
on 30/5, I will expect 50 hours/week on the project start from the beginning
of
June to the end of August except probably a one-week vocation for traveling.
1/5/2008 – 30/5/2008
I will try to get some feedbacks from the community, and will help to add
functions in Amarok 2. These functions will add value to the scripting
services,
and yet to make sure all the function needed for the new script manager is
included. Work include writing script validation functions and writing API
proposals on the wiki.
31/5/2008 – 13/7/2008
To implement the Kross and D-Bus handlers I've mentioned above.
14/7/2008 – 5/8/2008
To implement the script manager UI and to integrate it into Amarok 2.
6/8/2008 – 1/9/2008
Final debugging and open testing will be done in this period.


The full copy of the revised proposal can be found at
http://www.eaglestudio.org/GSoC2008_Proposal.pdf

Regards,
Peter

On Fri, Mar 21, 2008 at 7:17 AM, Seb Ruiz <ruiz at kde.org> wrote:

> On 19/03/2008, Peter Zhou <peterzhoulei at gmail.com> wrote:
> > Hi all,
> >
> > this is the draft 3 of my proposal. I rewrite the whole part 3 and
> revised a
> > little in the other parts.
> > http://www.eaglestudio.org/GSoC2008_Proposal.pdf
> >
> > I wonder if I need to add more details about the general classes and UI
> > controller classes.
>
> Hi Peter
> Don't worry about adding more technical specifics about classes and
> the ui. You could, however, use a little bit more thinking regarding
> functional specifications. What do scripts need to achieve? What will
> we allow access to (eg, playlist, collection, devices, even changing
> the ui, like adding toolbars/buttons is a possibility).
>
> Additionally, it would be helpful to expand the section on your
> timeline. How many hours a week do you expect to work on the project?
> What other commitments will you have for the duration of the summer of
> code program, and will you be unavailable for any period of it. These
> are just a few examples.
>
> Regards
>
>
> --
> Seb Ruiz
>
> http://www.sebruiz.net/
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20080321/5a908c4b/attachment.html>