On Sat, Apr 22, 2006 at 06:04:38PM -0400, Tim Moloney wrote: > I have three questions regarding the D-BUS API. > > There are four signals (playingChanged, playingUriChanged, > elapsedChanged, and visibilityChanged). Except for visibility, there > are matching accessor methods (getPlaying, getPlayingUri, getElapsed). > Can a getVisibility accessor be added? If so, then an application can > initialize itself using the accessor methods and use the signals to stay > in sync.
This is the sort of thing we should be using the dbus Properties interface for. > The /org/gnome/Rhythmbox/Shell object has a getPlayer method. It > appears to return a DBusInterface representation of the > /org/gnome/Rhythmbox/Player object. Why would this method be used > rather than asking the org.gnome.Rhythmbox service for the > /org/gnome/Rhythmbox/Player object (especially since this is how the > /org/gnome/Rhythmbox/Shell object was retrieved in the first place)? I'm really not sure why that method (and the getPlaylistManager method) exists. The example rb-print-playing.py program doesn't use it, it requests the player object directly instead. > The /org/gnome/Rhythmbox/Shell object has a present method. Looking at > the source for Rhythmbox, I think that it's related to removable media > but I'm not sure. Can someone explain what this method does and why > someone would use it? The 'present' method is used to present the main window to the user. It unhides the window and grabs focus. It's called when the user runs a second rhythmbox process (without the -n flag). _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
