Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Callback function for xbmc module #834

Merged
merged 0 commits into from

5 participants

@amet

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

Cheers,
amet

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()
@Montellese
Owner

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
Collaborator

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.

@jmarshallnz
Owner

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?

@jimfcarroll
Collaborator

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.

@jimfcarroll
Collaborator

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

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

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

@jimfcarroll
Collaborator

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

@amet

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

@jmarshallnz
Owner

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.

Thoughts?

@amet

@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

updated with some cosmetics

@amet

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
Showing with 0 additions and 0 deletions.
Something went wrong with that request. Please try again.