[jingai]

In my plugin I pop a progress dialog for the lengthy operation of importing the iPhoto library. On most machines there is no (visible) problem, but on slower machines like the ATV2, the dialog takes many seconds display. During this wait the list items are still accessible, so most users think it didn't work and tend to click import a second time, which causes problems.

I could probably solve this through locking in my plugin (at least, preventing the second import operation), but I figured I'd ask here if this is actually how it's supposed to behave. It seems to me that after I do:

Code:

progress_dialog = gui.DialogProgress()
progress_dialog.create("foo")
progress_dialog.update(0, "bar")

that the dialog should take over right away, especially given that it's modal.

Or is there something else I'm supposed to be doing to achieve this?

-j

[jmarshall]

The progress bar technically is not modal - it's a funny one because it doesn't actually do the modal loop per-se. Typically within XBMC it's used as follows:

1. StartModal (the python create method calls this).
2. Run a loop.
3. Call Progress() every iteration. This calls the modal loop once, allowing the screen to update and actions to be performed.
4. Close progress dialog.

This occurs during the app thread itself - i.e. the app thread is stalled, thus the reason for the call to Progress() to get the app loop run once per iteration to handle cancellation and the like.

With python, it's already in a separate thread, so the app loop is already running. Thus, the user can execute actions before the dialog pops on screen. The delay could be due to the startup animation for the progress dialog being run (though a few seconds seems too long) combined with small slice time for the script perhaps.

How are you reacting to the directory item when the user clicks on it? Is it a folder item or a file item? From here we can track what's going on in the code and see if there's a solution.

Cheers,
Jonathan

[jingai]

With python, it's already in a separate thread, so the app loop is already running. Thus, the user can execute actions before the dialog pops on screen. The delay could be due to the startup animation for the progress dialog being run (though a few seconds seems too long) combined with small slice time for the script perhaps.

Ah, gotcha. I really do mean a few seconds though; as in, probably closer to 10 or so. When it finally appeared, in this one case, the progress bar had already moved about 1/4 of the way across. I suspect the delay is long because I am updating it once per photo imported. In this particular case, my father had right around 3000 photos to import.

I didn't see the need to update any less frequently simply because it seemed to perform OK and I honestly thought the progress dialog was in fact modal.

How are you reacting to the directory item when the user clicks on it? Is it a folder item or a file item?

It's a file item.

The user can get at this option one of three ways:

1) It fires off automatically if the iPhoto library is newer than what we've got cached,
2) They select the ListItem from the root listing,
3) They select the ListItem from the context menu.

The directory items call the plugin with the paramater "action" set to "rescan" which ultimately calls a function called import_library that sets up the progress dialog and does the import.

I'm not sure what kind of details you want me to post here, so maybe it'd be best if I just pointed you at the plugin code. In addon.py, the import_library function is what you'd want to look at. If anything is non-obvious please let me know.

I basically need some way of knowing whether or not the progress dialog is actually on the screen before I do work, I think.

-j

[jingai]

I think what I'm basically after is.. what's the right way to prevent multiple instances of my plugin? I could check for a lock file or something, but if there's some other/better mechanism, please let me know

-j

[jingai]

Would something like this work for ensuring the dialog is on-screen?

Code:

while (gui.getCurrentWindowDialogId() != 10101): xbmc.sleep(100)

I'd add a timeout too to make sure it doesn't ever get stuck. I also don't really like hardcoding the window ID, but I guess it's not likely to change (?).

-j

[jingai]

Additionally, I've done this to prevent multiple instances of the library import function:

Code:

# crude locking to prevent multiple simultaneous library imports
    if (xbmc.getInfoLabel("Window(10000).Property(iphoto_scanning)") == "True"):
        print "iPhoto: Library import already in progress."
        return
    else:
        gui.Window(10000).setProperty("iphoto_scanning", "True")

And I set the property back to False when done, of course. I don't really like this though, since it's possible something bad could happen that doesn't get caught (oversight, bug, etc) and the property might not get set back. It's not the end of the world since it's cleared when XBMC quits (right?), but still..

Anyway.. are there better/official ways to do these things?

-j