[Feedback] DBus Interface Needed Enhancements

[Kimball Robinson]

A couple more thoughts.

Scripts probably need a way to talk to each other.  If a dbus call to send a 
script event to all other scripts were available, it would greatly benefit 
script interactiveness, and modularity.  (the most common event I can think 
of is for a script to notify others that it has started or stopped.  
Conflicting scripts could then begin a conflict resolution process).

Also, someone mentioned in this thread that a wiki page with many such 
suggestions might be appropriate.  It would be great to discuss the pros and 
cons of specific ideas, and have a somewhat permanent log of decisions.  Has 
anyone made this wiki page?

-Kimball Robinson

On Saturday 11 August 2007 12:43:00 am Kimball Robinson wrote:
> 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)