• 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7
WIP reduce context menu size by mving some option to second dialog
#76
(2013-11-12, 09:25)Ned Scott Wrote: Refresh?
Change content?
Scan for new content? (very "maybe" on that one. not sure)

The last two are only available in files view and probably are the most used context menu items for source items. That's why I don't think that a "Manage..." sub-menu makes sense there. I can look into if it's possible to add "Refresh" (from the video info dialog).
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#77
popcornmix: What was the reason you had to mark a whole heap of episodes as watched? I'm genuinely intrigued as to the usage pattern, as I never use mark as watched (or unwatched) at all as it's automatically done once I've watched something.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#78
Given Mark as Watched appears to be the most used Manage... option, perhaps it should be first? This would get rid of those that complain of it being in the main context as well as the manage menu.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#79
I propose to move all the "go to X" entries in the PVR EPG context menu to a "go to..." submenu (like the "manage...") to clean that thing a bit up. Those are probably rarely used. Talked about it with xhaggi already and he's also fine with it. What's the RMs view on this?
Reply
#80
(2013-12-29, 02:59)jmarshall Wrote: popcornmix: What was the reason you had to mark a whole heap of episodes as watched? I'm genuinely intrigued as to the usage pattern, as I never use mark as watched (or unwatched) at all as it's automatically done once I've watched something.

I think there have been 3 different occasions I've needed to "mark as watched" large groups:

Initially when I moved from using a different media player to xbmc, and was partway through a number of series.
After rescanning my library when I had a few series that weren't detecting new episodes. I backed up and restored the watched status with Milhouse's texture cache utility, but about 10% of series didn't restore the watched state correctly (possibly due to minor changes in series name).
When I've replaced a series with a higher quality version (e.g. sickbeard's archive version). The watched settings get lost here.
Reply
#81
Marked as watched for large groups of videos will be useful until we have a means of maintaining a persistent library. Might be something to think about as development on multi-client really gets rolling.
Reply
#82
popcornmix: Thanks, that's useful.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#83
A user in another thread ( http://forum.xbmc.org/showthread.php?tid=194294 ) was asking if "Scan for new content" could still work if a playlist is selected. I guess this is something that used to work, where the user has a playlist of TV shows, and they could scan for new library content on just that specific set of shows. The "Scan for new content" context item doesn't show up, but is that because it can't work anymore or because it's just not exposed in those situations?

Normally, I would say that this isn't much of an issue because "Scan for new content" is really just meant for folders (and TV shows, which are basically folders), but the use-case is actually a really great idea and I could see it being a nice way to do partial library updates, as updates can take a long time on some devices or based on the size of the library/number of shows.

If it's something that would be a lot of work, no worries, but I thought I would ask in case it's just something that might be possible to expose.
Reply
#84
TBH I didn't know that's even possible and I don't see how it would work. Maybe jmarshall can enlighten us. It should still work on a per tv show bases though.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#85
I don't think it was ever intentional, and there was certainly no code to only grab the paths of items in a smartplaylist or whatever.

I doubt it's worth the code overhead - there's too many pitfalls where it wouldn't actually do as described (the paths contained in the smartplaylist may contain a bunch of other things not in the smartplaylist).
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#86
Yeah that's what I thought. I'm not very familiar with the scanning code but I didn't remember it working that way. It only works on items that have a path which can be looked up in our database to find the appropriate source and scraper which is not the case for a playlist.
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#87
Fair enough, thanks for explaining it to me :)
Reply
#88
I've started to see reports of people complaining Now Playing has been removed from the Context Menu, see http://forum.xbmc.org/showthread.php?tid=195026 and I've seen other posts on the subject to.

I fully understand the reason behind the move and the renaming to Current Playlist, as it's not a contextual item then the view was it has no place there, but I can also understand the user argument that you queue items from the Context Menu and it's easier and more intuitive to enter the playlist of queued items from the Context Menu after you've queued them up.
Reply
#89
(2014-05-15, 16:17)jjd-uk Wrote: I've started to see reports of people complaining Now Playing has been removed from the Context Menu, see http://forum.xbmc.org/showthread.php?tid=195026 and I've seen other posts on the subject to.

I fully understand the reason behind the move and the renaming to Current Playlist, as it's not a contextual item then the view was it has no place there, but I can also understand the user argument that you queue items from the Context Menu and it's easier and more intuitive to enter the playlist of queued items from the Context Menu after you've queued them up.

I can see the point but the problem is if we follow this line of thought we can put everything back into the context menu. You can start playback from the context menu so why should the "Full screen" button or the player controls not be in the context menu button as well?
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#90
Indeed. I have no doubt that we could expose the Current playlist button better (outside of the sidebar menu for example), but I don't think the context menu is the right place.
Reply
  • 1
  • 3
  • 4
  • 5
  • 6(current)
  • 7

Logout Mark Read Team Forum Stats Members Help
reduce context menu size by mving some option to second dialog0