Virtual Python Folders

1. CPythonDirectory deciphers URL and calls script with whatever parameters have been set in the URL.
I'm not sure I understand this. If URL="http://apple.com/movie.mov" would it just play the url?

2. CPythonDirectory then waits on an event for some max timeout period.
This is tricky, Apple Movie Trailers could take 5-15 minutes to finish the first time you enter a genre(folder). If the script crashed you would have to also reset by the user backing out of the folder.
a. Would it make sense to have CPythonDirectory control a progress dialog and have a hook that the script could update? Then if it wasn't updated in a shorter amount of time it could force the script closed. (maybe ugly)

3. Meanwhile (in another part of Gotham City), the script goes away and does whatever it needs to fetch the items it wants to display, and then calls a function xbmcSetDirectory() with the item list.
4. xbmcSetDirectory() then sends CPythonDirectory the contents and sets the event.
5. CPythonDirectory sees the event as set, and returns the data.
If a. is used above, The script could send a finished parameter with the list.

6. User is presented with the list.
The key issues are:
a. How does xbmcSetDirectory() know which instance of the CPythonDirectory class to call?
b. How does CPythonDirectory know it's been updated by the correct script?
I think 2.a. takes care of that?

I like the idea too.. I'll try to flesh out how I see the UI working.

In the "Browse for new Share" dialog from "Add Source", we add a new item "Add Plugin Folder..." (or something similar) under "Add Network Location..."

The resultant dialog will be populated by scripts in q:\plugins\sources

These scripts are standard scripts within their own folder and with a default.py, only their location matters. (Other types of plugin scripts could be possible in the future).

As for the functioning of the scripts... there are two options I suppose,
the first is similar to JM's suggestion...
A) Call a python program with a directory specified via sys.argv
1) sys.argv specifies directory path and directory handle
2) script calls xbmc.SetDirectoryContents(handle, [listitems])
3) exits

the second might be faster and avoids passing handles
B) Extend a object like xbmc.Source and override its FetchDirectoryContents() funtion..
1) CPython object registers itself and gets its own pointer to CPythonDirectory
2) xbmc responds to events by calling xbmc.Source.GetDirectoryContents()
3) scripts calls xbmc.Source.SetDirectoryContents([listitems]) to add listitmes
4) always have the script run until xbmc calls xbmc.Source.close()

The main difference between A and B is that A has the script running off and on while B has the script launch once and respond to events. A sounds alot simpler from C++ side but I have a feeling it could cause problems with scripters, probably scripts would cache alot of results. B is more expandable though. Scripts would have an easier time specifying context menu items for example.


With both of these I think a plugin version number similar to what we have on the skin side of things might be a good idea.

I do and don't like the script always running.
1. What if it crashes?
2. Memory? not as much of a problem since we aren't createing a gui.
3. Most operations won't take that long, maybe if python could be initialized when entering python:// that may help some small amount?

About caching, is that something that XBMC could handle, Say I just passed a url to a poster. Would XBMC handle downloading and caching it?

I was thinking about situations where you might have to login and maintain some connection state between accesses sort of like an AFS token.

... but yeah.. the more we go down that route the more it is just another script as opposed to a plugin. The run and exit of method A seems easier and you could probably use the directory handle to extend the source just fine.

Any thoughts on integrating with the library?

There's nothing stopping you from calling anoth .py file and keep that running. But exiting it would be an issue.

1400 AMT records added, might not be good But if we can set listitem.* labels we could have the same functionality.

*bump* any news on this? did I miss something on IRC? I set up the development environment today and if somebody passes a (simple) task to me (I'm not that experienced yet with c++ programming, have a lot of OOP experience though), I'd be glad to do it.

If you want to take a shot, here's how I'd do it (just elaborating slightly on the above).

1. Create a CPythonDirectory class. Model it on any of the other directory classes (CPlaylistDirectory for instance).

2. In the GetDirectory() method, evoke a (test) python script using g_pythonParser.evalfile(<script>,<argc>,<argv>). One of the arguments should be a void * handle which is the pointer to your CPlaylistDirectory class (this).

3. Start a loop at that point, waiting on a boolean member (set to false at the beginning of GetDirectory) (or use WaitForSingleObject() stuff if you know how to do that already)

4. Implement a xbmcSetDirectory() call somewhere in the python classes (libPython) that takes in the handle and the list of items.

5. In this method, construct a C++'d version of the python content, cast the handle into the CPythonDirectory object, and pass the items through to it (via a SetDirFromPython() command).

6. In SetDirFromPython(), we copy the item content into a CFileItemList (member of CPythonDirectory) and set the bool/event that the GetDirectory() function is waiting on.

7. When it breaks out of the wait loop in GetDirectory(), copy the items across into the list and return true.

Once you have a simple test framework up, we can review it and improve on it etc.

Have fun

Cheers,
Jonathan

jmarshall Wrote:4. Implement a xbmcSetDirectory() call somewhere in the python classes (libPython) that takes in the handle and the list of items.

5. In this method, construct a C++'d version of the python content, cast the handle into the CPythonDirectory object, and pass the items through to it (via a SetDirFromPython() command).

6. In SetDirFromPython(), we copy the item content into a CFileItemList (member of CPythonDirectory) and set the bool/event that the GetDirectory() function is waiting on.

I can manage to do the first steps, but I have no clue how I can access C++ variables from python and vice versa. Even if I have the pointer in Python, how can I write to that adress?
Do I have to do it like in this documentation? Or is the embedding of Python in XBMC solved in a different way? http://docs.python.org/ext/ext.html
I once did such a thing with Java and Swig for some scientific image library and remember that this was really painful...

You don't need to access c++ variables from python (I don't think), but to go the other way

Search the source for

PyList_GetItem
PyArg_ParseTuple
PyGetUnicodeString
...

Nuka1195 Wrote:You don't need to access c++ variables from python (I don't think), but to go the other way

So I just store the data in the Python code, let the python script end and after that grab the variables of the python object from c++? So the variables don't vanish when the script exits?
I thought I'd at least have to call a C++ function with the handle from the python code....?