Plugins drop progress dialog

[jmarshallnz]

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.

[ghost]

i see no way around this. question becomes if we should allow some backwards compat here (spec'd in addon.xml). i.e. anything running under py 2.0/1.0 will get their dialog unless specified? bit counter-productive as the bug may very well bite in those plugins, but still this is a rather harsh behaviour change...

[pieh]

How about something like this pieh@247cdd5 ? (messy as this is just draft). It re-adds progress dialog that runs instead of busy dialog in CDirectory::GetDirectory on gui thread. Most important part are changes to IDirectory (did my best to comment them doxy style in IDirectory.h but I defenitely suck at doing that ;P)

Note: this patch is addition to commits in this PR - not usable in master

This doesn't solve plugins trying to spit their own progress dialog, dunno if we need to fix it just here or globaly (active GUIWindow being taken over by something else)

[jmarshallnz]

Given that the only info we're displaying is the progress percentage, the interface could be simpler to just include that percentage, and then you could drop the lock. Also, we could potentially hook it up to the busy dialog, which is possibly a bit lighter, and doesn't have the issue with clashing with the progress. I think the existing busy could just have a percentage added to it (progress or label) easily enough without breaking skins.

@Jezz_X your thoughts?

[pieh]

Currently we're also displaying script name in heading, "Loading directory" in first line and "Retrieved %i items" in last line, but I guess we can just drop them as they're not essential.

That struct was meant to be used generally with GUIDialogProgress so that's why I stuffed percentage,heading and lines there and placed it in IProgressCallback.h.

And as I said, this was just a draft (now i even see that I forgot to update percentage, but still updating line with items loaded count) - my main idea was to pass progress info from IDirectory to CDirectory::GetDirectory(). What dialog, how much progress info to pass? That's up to You guys.

[jmarshallnz]

I like the idea of allowing feedback, but IMO the busy would work better than the main dialog overall:

Advantages:

1. Much lighter weight.
2. Doesn't have issue with progresses that python or other VFS's might throw up.
3. Doesn't require progress should the VFS not provide it.
4. Simpler code (no locking required on the progress, a single new (const) function to IDirectory to get progress).

Disadvantages:

1. Skin change required (though it would be backcompat)
2. Not as obvious that the process is cancellable?

I suspect number 2 isn't much of a problem - the natural thing when something is busy is to try going back? If we find it's an issue, a label could be added to the working dialog to make it clear.

[pieh]

DialogBusy now is also cancalable (if we cancel, IDirectory continue to fetch dir, but we don't wait on it and don't care about items that will eventually be fetched), so I would remove 2. from disadvantages (or rather say it's not directly related to this). /agree with rest.

[jmarshallnz]

I meant not as obvious to the user (no gigantic "Cancel" button).

I'll mock something up on the weekend unless someone beats me to it.

[vicbitter]

Guys, I think commit 49cc4be is causing the problem. If you comment out the commit then the "Loading Directory" dialog is not shown over the top of the Search dialog.

[vicbitter]

@jmarshallnz, I tried your commits with the "lock.leave()" commit and everything worked great. Thanks

[jmarshallnz]

Ok, some work on progress bar to busy dialog can be found here (branched off here).

https://github.com/jmarshallnz/xbmc/tree/add_progress_to_busy_dialog

@Jezz_X: nasty skinning work there by me - would appreciate you having a crack. ATM it's id 10 - not sure whether to make it an infolabel or not - your thoughts?

[jmarshallnz]

@JezzX: see above.

[jmarshallnz]

@JezzX I've pulled in the confluence progress dialog addition to busy. Would appreciate you taking a look. ATM it's a fixed ID, but I could do an infolabel if you think that is more useful.

This is mostly a fix, but as it changes API, it would be nice to get this in the merge window.

[fritsch]

@jmarshallnz:
Could you rebase it on the latest master code. We want to test it within our xvba ppa. Disappearing plugin dialogs is a great issue there.

[ghost]

button is green.......

[jmarshallnz]

@cptspiff: what do you think about merging as a fix (there's still issues with search dialogs popping up under the progress in current master)

Obviously the skin needs work, but I can drop 7285c2e and ask @JezzX to do it (or do it myself and thus force the issue)

[ghost]

it is a fix. and it works fine i have had it in my builds for a while. green button is up for some hitting.