Update slim mode view in media browser & channel list

[prl]

[This discussion was moved from Movie duration not displayed in Media Player file list (hence the different post titles).]

As an aside, I've also added code to exit the media selection screen if the "Use slim mode" setting changes. This was always a source of confusion
because it initially looked like the setting change did nothing. It was made worse by the addition of optional columns that shouldn't be displayed
in slim mode, but were displayed after the setting changed back from slim to normal until the screen was restarted.

The setting description now says:

Use the alternative slim screen. Changing this option will close the media browser.

[IanSav]

Hi Prl,

As an aside, I've also added code to exit the media selection screen if the "Use slim mode" setting changes. This was always a source of confusion
because it initially looked like the setting change did nothing. It was made worse by the addition of optional columns that shouldn't be displayed
in slim mode, but were displayed after the setting changed back from slim to normal until the screen was restarted.

The setting description now says:

Use the alternative slim screen. Changing this option will close the media browser.

Please don't do this. Having the the screen close like that will be jarring.

I have already submitted a bug fix pull request that warns the user that changing this option will require a GUI restart.

If you really want to code a fix to this, and other problems, it would be great if we could ask all screens that are loaded at GUI start to reload (without the GUI restart) if a change to the skin or configuration is made. OverlayHD could really benefit from this sort of fix.

Regards,
Ian.

[MrQuade]

Please don't do this. Having the the screen close like that will be jarring.

I don't think he intends it to close the settings screen as soon as that setting is toggled, rather accepting/saving the settings change will result in the settings window being dismissed and being dumped back to LiveTV.

If you really want to code a fix to this, and other problems, it would be great if we could ask all screens that are loaded at GUI start to reload (without the GUI restart) if a change to the skin or configuration is made. OverlayHD could really benefit from this sort of fix

That would be a handy new feature! How long does it take to re-load those elements?

[IanSav]

Hi MrQuade,

I don't think he intends it to close the settings screen as soon as that setting is toggled, rather accepting/saving the settings change will result in the settings window being dismissed and being dumped back to LiveTV.

I believe that this would also be undesirable.

That would be a handy new feature! How long does it take to re-load those elements?

I haven't time tested any of this but I suspect it could happen in well less than a second. I believe that all the screen XML structures are already in memory. We just need all the init code to be re-run against any new options or settings that may have come into affect.

Even if this took a few seconds to process this would still be *MUCH* better than the time taken for a full GUI restart. This should also avoid any interruption to any current processing like recordings and/or tasks.

Regards,
Ian.

[MrQuade]

I haven't time tested any of this but I suspect it could happen in well less than a second. I believe that all the screen XML structures are already in memory. We just need all the init code to be re-run against any new options or settings that may have come into affect.

I was just curious on this point. Considering that the graphical EPG takes a couple of extra seconds to load the first time, I was just wondering what the effect of loading more skin elements may be. It's definitely a good idea, but if it takes longer than say 5 second to occur, then it might get a bit tedious if you were changing a lot of those settings in quick succession.

I do think it's a good idea, but until such a feature is implemented, I still think that closing the media player is a far better solution to reduce user confusion than not doing so.

[IanSav]

Hi MrQuade,

I was just curious on this point. Considering that the graphical EPG takes a couple of extra seconds to load the first time, I was just wondering what the effect of loading more skin elements may be. It's definitely a good idea, but if it takes longer than say 5 second to occur, then it might get a bit tedious if you were changing a lot of those settings in quick succession.

You would prefer a full GUI restart and cancellation of all active tasks over an unlikely, but for argument's sake, 5 second reload?

I do think it's a good idea, but until such a feature is implemented, I still think that closing the media player is a far better solution to reduce user confusion than not doing so.

I do not agree.

My pull request specifically warns the user that the view will not change until the GUI is restarted. This uses the existing warning mechanism built into the SETUP UI.

Regards,
Ian.

[MrQuade]

You would prefer a full GUI restart and cancellation of all active tasks over an unlikely, but for argument's sake, 5 second reload?

I'd prefer one single GUI restart at a time of my choosing over a series of 5 second outages as I go through the menus changing settings. If it is indeed less than a second as you suggest, then no problem.

Even as it is now, I get impatient when a particularly long media list takes more than a few seconds to load. Anything that detracts from the perception of a responsive interface should be carefully considered.

[IanSav]

Hi MrQuade,

Given that the setting changes of which we are speaking are uncommon and they are unlikely to be slow I suspect that your concerns are unlikely to be realised.

Regards,
Ian.

[prl]

I'll post in moe detail tomorow, but the new slim mode change does not close the media browser the instant the option is changed. The media browser closes when the user exits the media browser settings screen. That obviously needs be clarified in the setting description text.

Also, a GUI restart is not required when the slim mode setting is changed in the media browser. All that's needed is for the media browser to be restarted. That is not the case for slim mode changes in the channel list. That does require a GUI restart to take effect.

[IanSav]

Hi Prl,

I'll post in moe detail tomorow, but the new slim mode change does not close the media browser the instant the option is changed. The media browser closes when the user exits the media browser settings screen. That obviously needs be clarified in the setting description text.

Rather than closing the screen can you reload the screen with the alternative screen skin?

Alternatively, can you catch the close event and determine that it was due to the screen change and immediately re-open the screen with the newly selected skin?

Also, a GUI restart is not required when the slim mode setting is changed in the media browser. All that's needed is for the media browser to be restarted. That is not the case for slim mode changes in the channel list. That does require a GUI restart to take effect.

Yes, you are absolutely correct. Apologies for getting the two confused and muddying the waters. My pull request covers the issue in the FAV screen not the MEDIA screen.

That said, if you can fix the FAV, InfoBar and other screens that are pre-loaded and require a GUI restart to update then that would be a very welcome improvement.

Regards,
Ian.

[prl]

...

I'll post in moe detail tomorow, but the new slim mode change does not close the media browser the instant the option is changed. The media browser closes when the user exits the media browser settings screen. That obviously needs be clarified in the setting description text.

Rather than closing the screen can you reload the screen with the alternative screen skin?

That sounds like a real can of worms.

Alternatively, can you catch the close event and determine that it was due to the screen change and immediately re-open the screen with the newly selected skin?

That may be a possibility. It would have to be caught in the InfoBar somewhere. The close event would have to communicate the need to restart back to where the media browser was opened.

... if you can fix the FAV, InfoBar and other screens that are pre-loaded and require a GUI restart to update then that would be a very welcome improvement. ...

That sounds ... challenging. The InfoBar in particular is special, in that it's initiated right out of the mytest.py startup code. There are also side references to the various channel list views.

But... closing the media browser screen is what the user needs to do to effect the slim mode change anyway.

[prl]

The main thing that was driving me to look at cleaning up how the "slim" mode switch is handled in the media browser turned out to be a bug in the calculation of the width of the name field in the list.

I think that the "slim" mode looks OK with both optional columns enabled, though it is a little cramped. So I intend to allow the additinal columns to be viewed in "slim" mode. If more optional columns were to be added, it might need looking at again.

I still think it would be a good idea to try to fix up the slim mode switching for both the channel list and the media browser, but I'll look at them as a separate item, since I think the added columns no longer need the slim mode fix.

It looks like automatically recreating the media browser screen on the slim mode change will need a change in the API of the media browser close callback.

It may be a good idea to start a new topic for the slim mode fixup, perhaps in the developers' area, since I think it's now more about the ugly details of how to implement it. I can move/copy related posts in this topic to a new topic if people are happy with that.

[prl]

I think that a re-creation of the MovieSelection (aka media browser) screen can be done on exit from the movie browser settings screen if "slim" setting has changed, but it would require a change to the API of the MovieSelection "close" callback. At the moment it returns either None (on EXIT, for example) or the selected service to play.

It might be possible to fake something up to flag "please restart me" by using an invalid serviceref with a path or name like "restart", so a serviceref like

-1:0:0:0:0:0:0:0:0:0:restart

However, I'm not sure how stable even that would be for code that's not expecting that behaviour if it does an openWithCallback() of MovieSelection (which is really the only sensible way of using MovieSelection). That's because the code would expect to be given a playable serviceref (or None).