Hi Seb,<br><br>Thanks for your feedback. I think I was too much concentrated on the technical details instead of funcationality improvements.<br>Here I added two more paragraphs in the abstracting class part and script manager UI part respectively,<br>
<br>Part 2:<br>Using the new script interface, we will be able to:<br>1. Add menus, buttons, bars to the current UI.<br>● Like the method I showed above, I will give access to every windows,<br>toolbars, buttons, menus, treeviews and listviews included in the<br>
current UI. For example, we will be able to add a user defined column<br>in the playlist window using the script by giving access to the listview.<br>2. Response to some UI signals.<br>● Giving access to the widgets like buttons, bars, and etc. will<br>
automatically allow the scripts to response to their signals, and some<br>other useful UI signals like "openUrlRequest", "VolumeChange",<br>"DeviceConnected" and etc. should also be added into the Kross<br>interface.<br>3. Use media, collection, playlist, device and Internet framework classes<br>
(and their containers).<br>● Using the media class (and its container), we should be able to get and<br>set the meta info, change the volume, play and search the media, or<br>even have the method to rip CDs.<br>● The playlist class will allow us to add, delete, modify, build a playlist,<br>
and to get extra information, like database info.<br>● The current device related functions are not polished yet, but it will be<br>still used as a separated class to connect, control and get info from a<br>specific device.<br>
● The internet class should also be worked as a internal service, each<br>radio or internet service will be treated as a independent class.<br>● The idea of general class is like providing different services using the<br>
existing Amarok functions. The proposal will not give the every detail of<br>the new abstracted classes or any functions, I will ask for feedbacks<br>and comments from the community about the content of the APIs and<br>the services provided by the new scripting interface before<br>
implementation.<br><br>Part 3:<br>The goal of the script manager is to keep scripts updated and to make some hard<br>rules when scripts communicate with Amarok, to insure the script is written in<br>some scripting language not binary, have its dependency checked, run with the<br>
right Amarok version, run with the right platform, and etc.<br><br><br>Part 5 Road Map:<br>I will have my final exams by the end of May, but I think it is necessary to have a<br>month to think and to discuss about the details of the APIs. So I plan to have 20<br>
hours/week to spend on the project in May. Then my summer vocation will start<br>on 30/5, I will expect 50 hours/week on the project start from the beginning of<br>June to the end of August except probably a one-week vocation for traveling.<br>
1/5/2008 – 30/5/2008<br>I will try to get some feedbacks from the community, and will help to add<br>functions in Amarok 2. These functions will add value to the scripting services,<br>and yet to make sure all the function needed for the new script manager is<br>
included. Work include writing script validation functions and writing API<br>proposals on the wiki.<br>31/5/2008 – 13/7/2008<br>To implement the Kross and D-Bus handlers I've mentioned above.<br>14/7/2008 – 5/8/2008<br>
To implement the script manager UI and to integrate it into Amarok 2.<br>6/8/2008 – 1/9/2008<br>Final debugging and open testing will be done in this period.<br><br><br>The full copy of the revised proposal can be found at <a href="http://www.eaglestudio.org/GSoC2008_Proposal.pdf">http://www.eaglestudio.org/GSoC2008_Proposal.pdf</a><br>
<br>Regards,<br>Peter<br><br><div class="gmail_quote">On Fri, Mar 21, 2008 at 7:17 AM, Seb Ruiz <<a href="mailto:ruiz@kde.org">ruiz@kde.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On 19/03/2008, Peter Zhou <<a href="mailto:peterzhoulei@gmail.com">peterzhoulei@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> this is the draft 3 of my proposal. I rewrite the whole part 3 and revised a<br>
> little in the other parts.<br>
> <a href="http://www.eaglestudio.org/GSoC2008_Proposal.pdf" target="_blank">http://www.eaglestudio.org/GSoC2008_Proposal.pdf</a><br>
><br>
> I wonder if I need to add more details about the general classes and UI<br>
> controller classes.<br>
<br>
</div></div>Hi Peter<br>
Don't worry about adding more technical specifics about classes and<br>
the ui. You could, however, use a little bit more thinking regarding<br>
functional specifications. What do scripts need to achieve? What will<br>
we allow access to (eg, playlist, collection, devices, even changing<br>
the ui, like adding toolbars/buttons is a possibility).<br>
<br>
Additionally, it would be helpful to expand the section on your<br>
timeline. How many hours a week do you expect to work on the project?<br>
What other commitments will you have for the duration of the summer of<br>
code program, and will you be unavailable for any period of it. These<br>
are just a few examples.<br>
<br>
Regards<br>
<font color="#888888"><br>
<br>
--<br>
Seb Ruiz<br>
<br>
<a href="http://www.sebruiz.net/" target="_blank">http://www.sebruiz.net/</a><br>
_______________________________________________<br>
Amarok mailing list<br>
<a href="mailto:Amarok@kde.org">Amarok@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok" target="_blank">https://mail.kde.org/mailman/listinfo/amarok</a><br>
</font></blockquote></div><br>