[maruchan]

After using a number of the latest video addons (TED Talks, YouTube, Hulu, etc.) I noticed that, while plugins largely stick to the intention of "a directory listing of items you can play back in XBMC", there are certain items that should be given visual priority, specifically the rudimentary navigation and user-interfaces necessary for content. For instance, in the TED Talks plugin, you navigate through the videos using "Next" and "Prev" in the file listing. Because they're simple directory items, they're displayed uniformly with the rest of the listings.

I feel like this is pretty unintuitive. You could achieve a nicer interface by writing a script with a custom UI, but that seems like overkill for just wanting a few items to stand out from the rest of the listings.

I propose the addition of a few things:
1.) Allow file lists to use the separator available to the settings GUI.
2.) Allow certain listings to be denoted as "Headers", sectioning off listings into a visual sub-category (seen below as the blue text.)

Below is an image of 1 & 2 within Confluence and the SABnzbd plugin:



Because they're just reused design elements from other areas of the skin, I feel like it doesn't break the overall visual continuity nor does it stray too far from the simplicity a plugin is supposed to have. I'm interested in hearing if anyone else has suggestions for ways to improve the overall look of content navigation in plugins or thoughts on the matter.

Sorry if this should be in Feature Requests, but since it directly pertains to Python development, I thought it was better suited here.

[jmarshall]

This (the category headings) is something that is probably worthwhile - not sure quite so much about the separators.

The difficulty here is it has the potential to break one of the principles that the container controls rely on - that each item has the same dimension(s), other than the focused item.

Assuming we restrict things so that that is not broken, I see no problem here. Note that my guess (and it's a guess only) is that this is already doable with some skinning magic (conditional labels based on the listitem content). The trick would be to make that magic easier for the skinner, and easier for the plugin author.

Cheers,
Jonathan

[theuni]

Agreed on the next/prev issue. Very annoying for lots of plugins. It seems that could be easily solved by allowing for a list to hold infinite items, while only displaying X. If a list with 12 elements is displayed in a container that only shows 10, auto-create next/prev page controls for lists of 10 and 2. Those controls could be up to the skinner but they would be distinct from the list items themselves.

jmarshall: Am I way off the mark there?

TheUni

[jmarshall]

The Next/Prev is something the plugin maker does in order to populate the list in a reasonable time, usually due to the fact that they're scraping a website that has paginated results listings.

There's nothing particularly stopping the plugin from returning many more results than just one page, other than the fact that it's a little more complicated and will take longer to list.

Not sure the best way to make this better to be honest - it's something to discuss with plugin authors that have things setup this way to see if we can help them out.

Cheers,
Jonathan

[topfs2]

I think there are several options for the prev, next situation. Basically if the plugin was able to just give a part of the total amount of items and could continue parsing and working while the user navigates would help quite abit.

Another option, that would limit the bw and memory would be that our GUI ask the plugin for items x to y and plugin provides them. Nothing stopping us from asking items that aren't displayed which means that we could probably limit this so that the user doesn't even see it happening (unless he is navigating far faster than the plugin is able to provide).

[spiff]

async vfs ftw. run everything vfs in a separate thread, have it do a callback for each item found. much like the plugins work today, except general. and fully async - so as soon as an item pops up we toss up the list.

[Clumsy]

Would be good if a list that is still being populated shows this visually somehow, so that if the internet connection is very slow, the user knows there might still be items popping up in the future. This should be something very subtle, maybe just a small text that says "populating list" in the bottom of the screen, or if the skinner wants, maybe just a very slim animated "line" or whatever below the list, showing that something is still working.

This would be very nice though, because it would also make plugins alot more responsive, my eevblog plugin atm just fetches the 110 video blogs the author has made and that does take some time. I don't like thos prev/next buttons though, I think it makes the user interface feel very strange, so that's why I opted for the "slow" way.

[Jezz_X]

jmarshall from a skinner point of view (which I'm sure it pretty much works this way anyway) for the extra items lists and panels become a like a grouplist of groups with the itemlayouts and the focused layouts are just a group of other controls (so they can still be different) and the main "panel,list" is the grouplist.
And you and you can also define a 'separator' type group as well that gets used as the separator item which is basically another fill of ListItem.Label and some pretty graphics that get skipped on navigation because its classed as not focusable like labels in current grouplists

Just a thought

[Jezz_X]

or you could just add a "seperatorlayout" to the current ones but you would have to take into account possible variations in size

[jmarshall]

Variations in size is where things get more complicated unfortunately. Essentially it means iterating through the list, and/or holding a more complex data structure that contains sizing information which is tracked and updated on the fly. Grouplist does it by the former as you generally don't have more than a dozen items in the list. General lists can potentially have thousands of items, so the latter is the only way to do it.

Panels in particular make no sense in this regard.

[CrashX]

Another option, that would limit the bw and memory would be that our GUI ask the plugin for items x to y and plugin provides them. Nothing stopping us from asking items that aren't displayed which means that we could probably limit this so that the user doesn't even see it happening (unless he is navigating far faster than the plugin is able to provide).

I like this idea but should apply to everything not just plugins. I don't think plugin developers should add Next and Prev, it should handled automatically by XBMC core.

[alshain]

The Next/Prev is something the plugin maker does in order to populate the list in a reasonable time, usually due to the fact that they're scraping a website that has paginated results listings.

There's nothing particularly stopping the plugin from returning many more results than just one page, other than the fact that it's a little more complicated and will take longer to list.

Not sure the best way to make this better to be honest - it's something to discuss with plugin authors that have things setup this way to see if we can help them out.

Cheers,
Jonathan

I have just now picked up my plugin again, (you may remember it: Swiss television) and because they changed the RSS feed, I am now forced to use a pagination.

As you have mentioned, these "prev" and "next" buttons are due to the nature in which many websites serve content.
Of course, such requests are very time intensive, and you have to be careful not to do too many because of the current nature of XBMC, which is, that you can only update the UI once - when the plugin stops.

As a result, plugins that need to do some heavy scraping of any kind
are very uncomfortable for the user.
Of course, you can employ a simple caching mechanism, but you have to do it at one time or another - and you have to update the info in time as well.

So how to solve this issue? I would propose a plugin, that acts as daemon.
It will fork itself (advantageously with an a little more recent version of Python to provide some ease for the plugin authors so you don't write code only to realize that it isn't available for 2.4.something. (This would probably require the user to set a path for the python executable of his choice, to provide cross-platform compatibility)

Any plugin can register with that server and outsource tasks - like scraping. An advantage for this would be, that the caching interface becomes uniform. It will not be necessary for the plugin author to write his own caching mechanism - instead he can rely on existent functionality.

It should be possible to do certain tasks in specified intervals of time. (like a cronjob)
So say you want a plugin to scan a videoportal every half an hour.
Instead of waiting for the plugin to finish when it's done in the traditional way, you will always be able to access the plugin's functionality as if everything was local. This will allow for much more complex and more time consuming tasks that can be consumed.

By catching all unhandled exceptions, you can prevent plugins from crashing the daemon.

Of course, this does not yet provide a unified way for pagination... but I believe good code basis for plugins is needed. I have looked at some plugins and most follow the guide on the wiki very closely.
Not that there is anything wrong with that, but such code inevitably leads to spaghetti code resulting in an unmanageable addon in due time.


Bottom line: I propose an independent (python powered) worker in the background to outsource tasks to. It can periodically start tasks and load-balance them.

Furthermore, I'd be in favour of having a good and strong plugin framework to simplify the development of plugins. Thereby reducing code duplication and increase the reliability and allow for better methods of enhancing plugins due to a more clear code structure.

[topfs2]

I like this idea but should apply to everything not just plugins. I don't think plugin developers should add Next and Prev, it should handled automatically by XBMC core.

Agreed, such an improvement should be for any vfs and as such plugins included.

[daledude]

I don't think plugin developers should add Next and Prev, it should handled automatically by XBMC core.

I would love this. I have an addon that checks addon listings for new entries and a standard way to NEXT/PREV would be very useful. Also, being able to visually separate some entries from others would useful.