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.
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.
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
@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.
@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:
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.
@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.
updated with some cosmetics
squished, updated with osx/atv2/ios xcode fixes and if I understand linux build process, that should be done as well