[Nuka1195]

This is on linux branch.

My situation:

i want to call openSettings() if the user has not entered their username yet.

this worked fine on windows, i then tested it on the xbox. what happened was the settings window opened faster than on windows, then the cache dialog opened on top of that. which obviously caused issues.

so i thought an EnableCacheDialog() function and a m_enableCacheDialog bool at the check to create the cache dialog. this still may be necessary for the xbox and if it's a bug with linux branch that too. but what i found is no matter what io set
timeBeforeProgressBar to. the openSettings call waits.

I couldn't figure out why the delay on linux, but other calls do not wait. i mean a regular plugin can fill list almost instantly without the cache dialog.

so if this can be resolved, i can submit a patch, that when openSettings() is called it disables the creation of the cache dialog.

here is a simple test plugin, just save as default.py in any plugin folder that has settings.

PHP Code:

import sys
import xbmcplugin
if ( __name__ == "__main__" ):
    xbmcplugin.openSettings(sys.argv[ 0 ]) 


if you want a trac i can create one. or if you have something for me to try let me know.

thanks

[Nuka1195]

in windows (linux branch) xbmc gets "stuck" in
CPluginDirectory::WaitOnScriptResult. the python method does get called while in [SIZE=2]
CPluginDirectory::WaitOnScriptResult, but the dialog never shows.

can anything be put in there to allow dialogs to open? is it too dangerous? currently i put a sleep in the plugin if the platform is xbox, this works, not ideal though.

i still would prefer a disable cache dialog method (which i have) and a fix to allow other dialogs to open in windows.

any ideas?
[/SIZE]

[jmarshall]

The problem is the threading. The main application thread is calling the plugin to request the directory. This application thread is the one that is waiting in WaitOnScriptResult(). Thus, any request to open a dialog (which also must occur in the main application thread) will be stalled until the WaitOnScriptResult has finished it's minimal wait, and begins to throw up the "getting plugin contents..." dialog. On xbox the dialogs can be thrown up from any old thread, which is why it pops up async.

The ideal solution is for all directory fetches to be background threaded and run via callbacks so that the application thread doesn't have to wait on them, and can continue on it's merry way. This will take quite a bit of code reorganisation, however, but is certainly something we wish to do long-term.

A temporary solution might be to enforce the application loop while in the busy wait on the plugins - not sure how well that would work out though!

Cheers,
Jonathan

[Nuka1195]

thought it might be something more involved

i'll just leave the two second sleep in the plugin for xbox users. that way it equals out.