[Feedback] DBus Interface Needed Enhancements

[Kimball Robinson]

As for the talk regarding backward compatibility, perhaps the best thing would 
be for someone to implement a dummy amarok dcop interface that merely 
translates dcop calls into dbus calls as transparently as it can.  This 
project could play catch-up if needed, and if there wasn't enough interest, 
it could fall by the wayside and the dcop interface would still die a natural 
death.

I'd like to make a couple suggestions of my own in this vein.  I'm a beginning 
amarok script writer, and love the ideas in the original post--they would 
make my life a lot easier.  

I'm using 1.4.4, so hopefully some of this is already planned/implemented.


Interface interactions through dcop/dbus
*  A dcop call to show an arbitrary string in the OSD display.  It would help 
keep a consistent look and feel rather than using kdialog --passivepopup.
*  Notification to the script when certain UI elements appear and disappear.  
For example, it doesn't make sense for a script to fetch lyrics if the user 
is typing in new lyrics.  Also, a script that shows the current track in a 
ticker or other place might not want to show it when the collection window is 
open.  This is rather general, I know--so this idea may be impractical.  
Still, it might give someone an idea.

Other ideas:
* I'm not familiar with dbus, so this may be redundant: It would be great if a 
script could start receiving output from amarok on various events (on-screen 
if desired).  In this way, a totally separate application could connect to 
amarok with the same STDIN paradigm as amarok scripts use to gather events 
from amarok.  Something like "amarok --watchevents" or a similar command 
given through dbus?
* Ability to get url lists by supplying a label list.
* Functions to manipulate the queue:  Get queue list; get queued track at 
index N; append tracks to queue; insert tracks at index N; move a track up in 
the queue by +N or -N; remove track(s) by index/name; be notified of 
additions to the queue;
* Similar functions to manipulate the playlist in the same way as I suggested 
for the queue.
* Notifications for songs being added to the playlist, and where it was added 
(including in dynamic mode).  Eg, "New track added at index N, or reverse 
index -M" (the script could get the name of the song if it's interested, if 
it will help efficiency).  
* Similar notifications for changes to the queue
* Since scanning the entire collection can take a lot of time, a dbus call to 
scan specific directories, tracks, or urls would be great.  
* The ability to manipulate part or all of the window title, (same string 
format as with OSD display)
* Add %TimeRemaining and %CurrentTime to the OSD display configuration options 
(and thus the playlist title options).
* Function calls to skip or stop a track without affecting its score.  
(scripts can add menu entries for this functionality if desired, later).
* Ability to register global shortcuts for Amarok, to trigger events in a 
script. (Or attempt it, with a boolean return value showing if the shortcut 
is was available).
* Ability to interact with smart playlists:  Get a random song from a smart 
playlist, check to see if a song matches a smart playlist's criteria;  Copy 
smart playlist criteria, Create/delete smart playlists;  check how many 
tracks are matched by a smart playlist;  (And wouldn't it be nice if smart 
playlists could be defined by sql queries, in an "advanced" box?)

I would love to write some concept scripts that use such functions, if only to 
advertise the new dbus interface.  I wouldn't mind helping to port a couple 
unclaimed scripts to the new interface, too;  While I prefer writing perl 
code, I've been thinking about trying Ruby, and I also need to get to know 
dbus anyway.

-- 
-Kimball Robinson
(bluekb on irc.freenode.net)