<br>thanks for your sharing and feedback!<br><br><div class="gmail_quote">On Sat, Mar 22, 2008 at 7:05 AM, Miguel Angel Alvarez <<a href="mailto:maacruz@gmail.com">maacruz@gmail.com</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;">
>Hi Peter,<br>
>I'd like to add my little grain of sand (I'm the replaygain script's writer)<br>
<br><div class="Ih2E3d"></div>>More than just some UI signals, the scripts should be notified of any event<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

>that changes amarok's state or behaviour, so they can replicate accurately<br>
>the amarok's state. Currently, the number of signals is very lacking: no<br>>signals on configuration changes, collection changes, device changes, play<br>
>mode changes, user initiated song changes, ....<br>
>To keep track on those changes, scripts need to continuously poll amarok<br>
>through dcop calls, which, needless to say, is very expensive </blockquote><div> <br>Yes, this is awsome! I should check and add signals which represent the current Amarok state.  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
>Don't know what to say about that.... does it refer to amarok's internals or<br>>is it an API?<br>
<div class="Ih2E3d"></div></blockquote><div class="Ih2E3d"> <br>
I am proposed to add some functionality by adding some classes and
functions in the dbus interface classes(Amarok2 will no longer use
DCOP). And the class I am going to add is classified by different
usages or objects. It seems it is confusing to use "API" here. The
script may access Amarok using DCOP/DBus/Kross fucntions, that is
pretty much alike using APIs.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
</div>>DON'T!<br>
>You shoundn't enforce any particular or personal preferences about scripts.<br>>Let the script writers deal with that. If someone want's to go binary, it is<br>
>his election.<br>>The issue of dependencies is very complex, and distribution dependant. There<br>
>is no safe way to deal with all of them, so I also think that the script<br>>writer should deal with it. What you could provide, is some way to register<br>
>the executable (even different executables depending on plataform) with<br>>amarok. Right now amarok just picks anything executable under the scripts<br>
>directory, which is not the best strategy. </blockquote><div><br>
This is hard. Different persons is holding different views on this one.
But this is only the matter of changing just several lines of code.<br>
I know the dependencies is very complex, especially Amarok2 will be
used in different platforms. What I am exactly doing now is to register
the executable. But I also do believe my approach could provide a
easier way to both the writers and users. At least something is better
then nothing. I think it is necessary to check if a user has a database
(not only installed, but also Amarok recognized) before running a
database related script.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>About the number and quality of actual dcop functions, I personally find them<br>

>good enough, so they are a good starting point.<br>
>Just a note, the comunication between amarok and the scripts needs to be<br>
>faster. Actually some dcop calls may take several tenths of second to return,<br>
>causing very noticeable lags (which in my particular case, are very<br>
>important)<font color="#888888"></font></blockquote><div><br>
I am not sure of the efficiency of D-Bus. This could be the tradeoff of
using external DBus instead of internal Kross interface since the
in-proccess script failure may fail the entire program.<br>
This should worth further discussion in order to find the balance of
using internal Kross and external DBus. (Maybe use more "safe" kross
functions to improve the efficiency.) </div></div><br>Peter<br>