xbmc/xbmc — pull request #1281 by jmarshallnz (2012-08-12 09:47:39+00:00)
Title: Plugins drop progress dialog

There's currently an issue with layered dialogs where a plugin throws up a keyboard dialog for search and the like. The dialogs involved are:

1. Busy dialog from CDirectory::GetDirectory.
2. Progress dialog from CPluginDirectory::WaitForScriptResult.
3. Keyboard dialog from plugin.

The problem case is where the progress pops up after the keyboard dialog is on screen, which often happens in plugins which implement a search feature, such as youtube.

This fixes it by eliminating the progress dialog**. This isn't ideal, as we lose the progress from the plugin (such as number of items to retrieve, and progress retrieving them). I'm not sure whether or not many plugins use this or not. IMO extending busy would be a nicer way to handle this either way - plugins that take a lot of time can throw up the progress themselves should they wish to (some already do). One disadvantage with this is that it's not necessarily obvious that it can be cancelled perhaps?

An alternate fix would be to stop the progress popping up if another modal dialog pops up. Trouble with this is it's hard to determine this case nicely inside the PluginDirectory class, as the app loop is running at this point, and thus there's potential races during tests for modal dialogs, as well as the busy gets in the way.

Yet another alternate might be that the progress stuff is moved into CDirectory::GetDirectory if the directory class can be cancelled.

Comments/criticisms welcome.

**Note that we don't have the same issues with busy being on screen, as it's automatically hidden when another dialog pops up over the top of it, and also the keyboard dialog can't pop up until it's on screen, which guarantees the keyboard is on top, thus receives input.