scripting proposal draft 3

[Miguel Angel Alvarez]

Hi Peter,
I'd like to add my little grain of sand (I'm the replaygain script's writer)

El Viernes 21 Marzo 2008, Peter Zhou escribió:
> 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.
This is great!
The current model of only allowing a context menu in the playlist is too 
restrictive. Some things need their own menu entry, or a button in the UI 

> 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.
More than just some UI signals, the scripts should be notified of any event 
that changes amarok's state or behaviour, so they can replicate accurately 
the amarok's state. Currently, the number of signals is very lacking: no 
signals on configuration changes, collection changes, device changes, play 
mode changes, user initiated song changes, ....
To keep track on those changes, scripts need to continuously poll amarok 
through dcop calls, which, needless to say, is very expensive
> 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.
Don't know what to say about that.... does it refer to amarok's internals or 
is it an API?

> 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.
DON'T!
You shoundn't enforce any particular or personal preferences about scripts. 
Let the script writers deal with that. If someone want's to go binary, it is 
his election.
The issue of dependencies is very complex, and distribution dependant. There 
is no safe way to deal with all of them, so I also think that the script 
writer should deal with it. What you could provide, is some way to register 
the executable (even different executables depending on plataform) with 
amarok. Right now amarok just picks anything executable under the scripts 
directory, which is not the best strategy.
>
> Part 5 Road Map:
About the number and quality of actual dcop functions, I personally find them 
good enough, so they are a good starting point.
Just a note, the comunication between amarok and the scripts needs to be 
faster. Actually some dcop calls may take several tenths of second to return, 
causing very noticeable lags (which in my particular case, are very 
important)

-- 
Don't see the world through a window, be open{source}minded, and be free :-)