Callback function for xbmc module #834

merged 0 commits into from Apr 6, 2012


None yet

5 participants

amet commented Mar 31, 2012

xbmc.Monitor will monitor for ScreenSaver activation/deactivation, Settings changing and database update.

settings changing are quite useful on service addons to allow users to change the settings without deactivating/Activating addon to reload them. only changed addon will get notified.

cptspiff has gone over it but looks like the comments have been lost as I have squashed it down.

as ususal, this is a c/p monster from xbmc.Player callback , if anything needs changing I am all ears


class MyMonitor( xbmc.Monitor ):
    def __init__( self, *args, **kwargs ):
        xbmc.Monitor.__init__( self )

    def onSettingsChanged( self ):
        print "settings changed, fetch new settings" 

    def onScreensaverDeactivated( self ):
        print "screensaver Deactivated" 

    def onScreensaverActivated( self ):    
        print "screensaver Activated"

    def onDatabaseUpdated( self, database ):
        print "%s database updated" %  database  

monitor = MyMonitor()

Have you seen the discussion in #728 about how to implement callbacks into python?

Apart from that you may also want to take a look at how I got around the necessity of providing the addon ID in the constructor of the class providing the callback. It is possible to extract the addon ID of the running script from python.

ronie commented Mar 31, 2012

nice one amet.
onSettingsChanged would be quite useful for service addons.

i hope we can extend on this by adding callbacks for library updates.
it's something i could use for a number of scripts.


Looks OK to me. Obviously needs syncing with #728 somewhat to make sure things are nicely divided. Am not sure if the screensaver stuff needs to be put in the same place or not.

Also, given that most of these functions are being duplicated across the JSON announcement stuff, it might make sense for the internal XBMC bus to be somewhat similar. eg when a video or song stops playing we currently use 3 separate callback mechanisms to trigger various behaviours. This is orthogonal to the actual PR functionality though.

@jimfcarroll Your thoughts on this one?


What's the screensaver have to do with the settings? ;-)

Amet, nice job! I guess you couldn't wait the 2 months ;-)

If JSON-RPC is going to use the Announcement stuff then using the same mechanism would probably be preferable.


Actually, Don't get me wrong. This looks great. I'm hoping we can resolve a lot of the redundant code between JSON-RPC and Python (if there is a lot) once I'm done. I'm making progress but there's a lot to do.

amet commented Apr 1, 2012

ok, removed need for the ID when calling the class. used the same code as Montellese on #728 so that it can get reused at later stage.

@jimfcarroll if you would like us to wait for you just say it, I really dont mind waiting few months. I just wanted to see if I can c/p this , now that it works I am ok either way :)

@jmarshallnz I was not able to remove CPythonMonitor::Release() and CPythonMonitor::Acquire() , will keep trying

amet commented Apr 1, 2012

@ronie the onDatabaseUpdated(database) will follow, database will be 'video' or 'music' as string, anything else you can think of?


Nope. Don't want to hold you up. Go for it.

amet commented Apr 1, 2012

@ronie onDatabaseUpdated() done, just for you :)


Ok, with @jimfcarroll saying this can go in, given that this is so similar to #728, they could potentially be merged together.

I see two ways to go:

  1. Just stick with a few callbacks (one general one for JSON stuff, and a few others for things that make no sense to be broadcast, like settings changes).
  2. Have lots of callbacks, with XBMC basically handling the switch from the JSON announces into individual callbacks for python.

I'm not sure which is the better way to go (eg. should we just force the python addon do the switch themselves?) - I guess one potential argument is that it allows a more well defined API? (In addition, it makes it slightly more effort to add new ones, which might mean we better bump the API versioning).

If we think things will change later once @jimfcarroll gets his changes done (the chances of the python API being restructed following that seem high?) then it might not be worth the effort to split them up now.


amet commented Apr 2, 2012

@jmarshallnz as discussed, announce hooked in, let me know if thats what you had in mind.

I am keeping this as separate commits so that its easier to review, if you want me to I can squash it quickly.

amet commented Apr 2, 2012

updated with some cosmetics

amet commented Apr 3, 2012

squished, updated with osx/atv2/ios xcode fixes and if I understand linux build process, that should be done as well

@amet amet merged commit 816bab6 into xbmc:master Apr 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment