[topfs2]

Hi!

For the last two years I haven't really had an apparment where I got to use XBMC that much but this all changed last month.
I got a new device and set it all up again. This is when I noticed, that even if lots have improved, there are still a few interaction issues with xbmc.
So I wanted to create a place where we can discuss how we can solve these, and a place where we can add new ones we find.

Problem: Pressing suspend, shutdown, reboot or any of the power management doesn't yield any visual interaction that the power management action is happening.
Solution: Pop up a busy dialog with cancel (if the powermanagement system allows for cancelation) or with animations (like a tube tv going down ) make it very clear that the system _is_ shutting down and that no further interaction with XBMC is possible.

Problem: Choose a new fanart, poster and if the server doesn't respond the GUI will freeze. Even if the server responds, the GUI will freeze until server responds.
Solution: Don't download, even how small, in GUI thread. Use a job and make it cancelable and show in GUI (popup? or busy icon in skin?) that we are busy.

Problem: Try to install an addon where it fails to download. The progress will go to 0% and then vanish, without any error popups or interaction of any kind. If the user has installed other addons he may guess that it failed, if this is his first addon he may very well think it was installed.
Solution: A first and simple solution is a popup stating that addon X failed to download. Another solution would be to reschedule a download later and useing label2 (where the progress is) say "failed to download, retrying in (x)"

Problem: Press play on a movie, from file or library view, while the movie loads the GUI is essentially locked. Even if the GUI continues to render there is no way to cancel.
Solution: Instead of a kai dialog, perhaps use a cancel dialog. And, IMO, even better. Go to fullscreen view imediately with a "busy" icon while buffering and setting it up. And respond to stop and back out actions. This would make XBMC feels like its reacting quickly, and the intent was carried out. In comparisson to old busy kai it doesn't remove the old gui so I would almost expect to be able to navigate there while its working.

Problem: Press play from recently added. If the device where the content resides is not available, the GUI will pop up a "busy" dialog but will silently fail.
Solution: Tell the user why it failed and perhaps an helpful tip, for example if we know its a remote device e.g. "Was unable to find the content, is device X turned on and connected to the network?"

I'll be adding in more of these when I find them and it would be awesome if everyone does the same

In general I think we need to set up a few guidelines on new features.

• We cannot pull in a feature if its doing anything intense in GUI thread, ever. XBMC should never stop rendering the GUI, even how intense a process is
  
• I'd say a valid guideline is that anything which may take a little while (like downloading listings etc.) should be cancelable. Or, see addon manager as example, be completely unintrusive if it takes forever.
  
• A pull must not only assume it may fail everywhere, it must also have a way to tell the user that it fails. Silently failing is generally bad.
  

Cheers,
Tobias

[zag]

Yey for developers using their software

[Martijn]

Yey for developers using their software

Blasphemy and all that but I agree on all those points
Now the point will come how we are going to keep track of these. imo just add them to trac as feature request and milestone 13.0 so we won't forget and everyone can have a quick overview what "needs" to be done.

[topfs2]

Awesome work! And I agree with Martijn, we should focus on just finding here and span out in new threads for solutions. I could create a thread for each, move all issues to my first post and link from there? What do you think?

I found some more yesterday (Some of these are from a core side of things the same problem manifested itself in multiple locations in view but I opted to seperate them to make it easier to move to tickets later)

Problem: Switch skin, depending on how large the new skin is can take a considerable time, and during this time the GUI is completely frozen.
Solution: If we assume we can't use any popups from the old skin, perhaps use the splash with a small animation?

Problem: Add a remote source. If we navigate to smb the GUI may freeze for a considerable time.
Solution: Canceble busy popup? or just a busy icon in label2?

Problem: Go through videos on home -> tv shows -> e.g. Big bang theory -> Season 1. Then go home (through a home button or back window, not regular back). Pressing TV Shows in Home now brings you within Season 1, which is somewhat odd?
Solution: Completely seperated history between videos, movies and tvshows?

Problem: OSD -> Video -> Calibration and press back and you end up in video
Solution: Back should only pop one of the stack, so should pop back to video in OSD?

Problem: Go to Videos -> TV Shows -> etc. Then suspend, and resume. Entering videos will take you to where you where prior to suspend
Solution: Consider hibernate and suspend the same as shutting down xbmc, clear history stacks.

Problem: In confluence the Info/OSD dialog uses an 'X' to close fullscreen, kindof double mapped and I actually thought that closed the dialog
Solution: Do as in home with a down arrow and "minimize playback" or something?

Problem: Enter a source from videos/music which is unconnectable or slow in any way will freeze the GUI without any way to cancel
Solution: Busy dialog with cancel or busy icon by the source?

[jmarshall]

Lots of great stuff here.

Problem: Choose a new fanart, poster and if the server doesn't respond the GUI will freeze. Even if the server responds, the GUI will freeze until server responds.
Solution: Don't download, even how small, in GUI thread. Use a job and make it cancelable and show in GUI (popup? or busy icon in skin?) that we are busy.

Hmm, this shouldn't be the case as far as I'm aware - no download is done at all so everything is done off app thread. Could it perhaps be the filebrowser waiting for it's thumbloader to cancel? Some more info would be good. If it's the latter, then cancelling the thumbloader async might be a way to go (this may be non-trivial, as IIRC we grab a new instance of the filebrowser and delete it after the fact, but I *think* it'll be OK).

Problem: Try to install an addon where it fails to download. The progress will go to 0% and then vanish, without any error popups or interaction of any kind. If the user has installed other addons he may guess that it failed, if this is his first addon he may very well think it was installed.
Solution: A first and simple solution is a popup stating that addon X failed to download. Another solution would be to reschedule a download later and useing label2 (where the progress is) say "failed to download, retrying in (x)"

The way we handle add-on installation needs a complete rethink IMO. Resolving dependencies before install, installing dependencies fifrst, issues with dependencies disappearing and so on all need rethinking through. Further, we need to better consider how we handle rolling back to earlier versions of XBMC (Frodo->Eden for example) where Frodo add-ons are left behind yet are still started by Eden.

Problem: Press play on a movie, from file or library view, while the movie loads the GUI is essentially locked. Even if the GUI continues to render there is no way to cancel.
Solution: Instead of a kai dialog, perhaps use a cancel dialog. And, IMO, even better. Go to fullscreen view imediately with a "busy" icon while buffering and setting it up. And respond to stop and back out actions. This would make XBMC feels like its reacting quickly, and the intent was carried out. In comparisson to old busy kai it doesn't remove the old gui so I would almost expect to be able to navigate there while its working.

The busy dialog (not kai) is cancellable with back/escape actions for directory listings. It's not in this case, however. I'd agree that jumping immediately to fullscreen might be a way to go, though ofc you couldn't do that for audio-only files, and we don't necessarily know in advance (though we can make a guess ofc). Would be interested in elupus' comments. I believe there's something done on app thread before the busy spins up (I notice this if the server disks are spun down), possibly an exists() or similar in the mediawindow somewhere?

Problem: Press play from recently added. If the device where the content resides is not available, the GUI will pop up a "busy" dialog but will silently fail.
Solution: Tell the user why it failed and perhaps an helpful tip, for example if we know its a remote device e.g. "Was unable to find the content, is device X turned on and connected to the network?"

This is symptomatic of a larger problem where we have multiple methods of starting playback (e.g. via playlistplayer or via some builtin). IIRC if it's started through the playlist player then it'll pop up an OK dialog with an error (usually fairly vague).

Cheers,
Jonathan