[lexicon]

I am interested in that previous thread, kraqh3d, so please post the link if you have it. Thanks.

p.s.
If you don't find that thread for me, then I will NEVER make another request, post another question, answer another members question, or offer any suggestion on this board again.

[lexicon]

p.s.
If you don't find that thread for me, then I will NEVER make another request, post another question, answer another members question, or offer any suggestion on this board again.

guess you missed your chance, buddy Is this it: http://forum.xbmc.org/showthread.php?tid=15029

I offer no guarantees of any progress, but I think I'll have a stab at it. At worst I'll learn something new.

Is there any new info to add to that thread - it is rather old now, so is it still relevant?

[jmarshall]

Yeah, that's the thread. However, something to be aware of:

The "view types" is going to be skin-dependent in the future, where skinners can define whatever view types they like, up to a maximum of N views (probably N = 10), so we need to have some sort of "fallback" system in place when the user changes skins, and the view type has been lost.

My current thinking is just 2 main "fallback" view types: list and icon. The view database would save:

1. Current view (integer type) which depends on skin.
2. View type (integer type) "classification" of this type (list or icon)
3. Sort type
4. Sort order
5. Possibly "view-specific" things, such as stacking for videos etc.

If anyone else can think of a better way to do the skin independence thing in particular, please chime in. One obvious way is to define more than 2 view classifications (eg list, details, icon, largeicon, wideicon, etc.) and have the skinner specify which one each viewtype falls under.

Cheers,
Jonathan

[kraqh3d]

appologies, i couldnt find the thread over the weekend. the forums were behaving badly. i was getting alot of database errors. thanks for finding it.

and cold_realms, you've misinterpretted my message. it was not meant to be rude or argumenative, but a frank reminder that this is an open source project and to set expectations. nothing more.

it gets annoying reading a constant flurry of messages which seem to convey the idea that we are somehow "obliged" to do what the user majority wants which is how i took your message. i presume that was not your intent and further illustrates jmarshalls point.

and sure, once and i while i need to vent a little but i always leave it civil and express that i was just venting, ala the (end rant) statement. i even continued on after that with further details about how this feature should be a bit easier to implement now that the code is a bit more organized.

this is a community driven project. i urge you not to stop making suggestions. as i said, suggestions are always welcom, no matter how crazy (and believe me there are some that are way out there.) doing so only hurts xbmc in the long run.

[kraqh3d]

jmarshall,
assuming the skin engine can understand the view types defined in the skin and update the "view as" button accordingly it doesnt matter. if the user changes skin, and the view type is no longer valid, just default down to listview and then apply autoswitching if enabled. (the database could also contain the skin as well so that the settings are saved per-skin, per-media window, per-folder.)

[jmarshall]

Per skin is IMO a little bit of a waste - most users tend to stick with one skin in the long run, and I expect most skins will offer the same types of viewmodes as things evolve (viewmodes that are useless will be removed with time).

My current thinking is that the skinner will implement however many panels/lists they want in the skin, and each one has an attribute defining what type of view it is:

list, thumb, details, widethumb, largethumb, .... (whatever we come up with). There can be more than one of each "type" if the skinner so wishes. The viewas button will then simply say "Change view" and will toggle through these. Anything the user changes will be saved to the db.

Do you think this should be implemented within the current db's, or in a separate one (not sure how sqlite handles multiple databases open at a time - one presumes it's fine with it).

And yeah, a simple fallback system can be used (eg all thumb-type views go to a thumb first, all list type views go to a list)

As for the auto-switching, this itself is not so obvious anymore (no point specifying separate thumb sizes, as the skin may only have one, or may have four). I've been thinking of just making it list/thumb switching, or perhaps a better heirachy of views (eg detail list preferred over thumb in some situations) and making that the default when "view remembering" is enabled. The auto-switching options would then change to a simple bool: "Remember view mode for folders"

Let me know your thoughts.

Cheers,
Jonathan

[kraqh3d]

i was envisioning a seperate db for the settings but there first needs to be some better error checking around it. today if the media library db cant be created, it also prevents the files view from working. this needs to be corrected so that files view always works regardless if the media library database or the settings database is ok or not. the "HasDatabases()" function might be a good base for something to track this state and essentially lock out database related functions in an error condition.

the current autoswitch still has merit. it could be used to pick the view when the current folder is not in the database, or if the database cant be accessed or is errored, etc.

if the "change view" button will know the views, why not just require one list and one thumb view, and any others that are defined are just skin specific and need some numberic identifier. here's a simple example...

list.0 and thumb.0 are the mandatory views. (it might also be a good idea to build these base views into xbmc and not part of the skin.) the skin can then define the additional views: list.1, list.2, list.3, thumb.1, thumb.2, thumb.3, etc.

lets now assume the user saves the folder view as list.3 and then changes skin. if there is a defined list.3 view in the new skin, xbmc would use it. otherwise use the standard list.0 list.

and heres an off the wall idea regarding thumb panels... could the size of the thumb be extracted from the skin now so that the user could change the size, per folder, via the gui and have it save to the db? (the default size would still need be defined in the skin.) this eliminates the need for seperate thumb panels based on thumb size. (the thumb size choice would need to be fixed to something between 100 and 300 pixels.)

though, allowing this to also account for widethumbs may be an issue so that may need to be maintained seperately. but im not sure how widethumbs even works. i thought xbmc caches the image as a 256x256 square. this would mean the cached image would be squished horizontally when cached. and then when its "unsquished" i would expect the image would look pretty bad.

another code question... does this now mean that each view wont need a seperate control id anymore?

[jmarshall]

1. Agreed about the databases - for this one, if it's corrupt, we simply kill it off - if it doesn't exist, we try and create it, but don't panic if it fails.

2. Yes, the current autoswitch still has merit, but I suggest we make it the default view mode, and actually add it to the view list as "Auto". If XBMC is set to remember viewtypes, then "Auto" will be the default choice if the folder has not yet been navigated to. Obviously there'd be no choice between large and small icons in that case - we'd have to auto-choose that (or leave it up to the skinner to prioritise)

3. My current thinking is id's 50 -> 59 would be the view controls, though we could in fact have no id necessary by assuming all lists + panels are views, though that breaks down if we ever decide to have more than one list...

4. I prefer the panels designed by the skinner - the current panel allows quite a few different layouts (basically the item layout is completely up to the skinner, so can include as much text as they like) and so scaling these automatically will not work well as the text layout will screw up. Most skinners tend to know what's going to look best anyway Also, lists can be set up to look essentially like 1 row (or column) panels, so the differentiation between the two has reduced somewhat.

5. Wide icons will need to be thought about - currently they're cached within the square (no aspect ratio fiddling) so yes, this is not ideal for these icons. I'm considering adding a separate wide icon caching system, but haven't really thought much about it. A simple method would just cache the thumb so that it's area is less than 65536 pixels for instance.

Any other ideas/suggestions while we're on it?

Cheers,
Jonathan

[jmarshall]

Ok, there's some preliminary stuff on this in the multiviews branch in SVN.

Currently I've done the following:

1. Expanded the skinners ability to put as many views as they like (up to 10), and changed the "View As..." button to just cycle views.

2. Added a database for saving per-folder views. It currently just saves view type, sortmode and sort direction.

Please give it a go and let me know what you think.

Cheers,
Jonathan

[lexicon]

2. Added a database for saving per-folder views. It currently just saves view type, sortmode and sort direction.

This is all really slick. Saved view modes are pefect for tweaking the display of movie and tv directories.

A nice feature is the saved sort order: I can now have Albums -> Sort by Artist ... and Compilations -> Sort by Album without always switching. Perfect.

I also like having the choice of List or List 2.

p.s. "List 2" is (imo) ugly terminology for the end-user. My vote would be for something like "Enhanced List". Just a thought.

...gotta go try some wide icons now...

[jmarshall]

And it's still being worked on. It's all in the main trunk now.

What we're currently looking into is to get the "what to do when no info is saved for this folder" stuff working a bit nicer. The first version just defaulted to list (with autoswitching). I'm currently experimenting with various other options.

Any suggestions will ofcourse be taken into consideration.

Cheers,
Jonathan

[Jezz_X]

p.s. "List 2" is (imo) ugly terminology for the end-user. My vote would be for something like "Enhanced List". Just a thought.

Yeah but the only main problem is translation and fitting it into the size of the button "Enhanced List" would go right off the side of it, its just too big

It was easier to add a number next to it just because it requires no translation and yet people know its a different view mode
Also glad you liked that I readded the old list as well

[lexicon]

Another idea, maybe. Is it possible to have a custom sort order for bookmarks.

e.g., right now in Videos I have bookmarks named
"1. Kids"
"2. Movies"
"3. TV Shows"
etc.

i.e. I'm using 1,2,3 to enforce my preferred order.

I know that there is functionality in place to edit the order of the now playing playlist - could that, coupled with the views db, be used to accomplish custom sort order for bookmarks?

Even if it is possible, I'll admit it ranks fairly low in importance. I just think the 1., 2., 3. is ugly, especially since I added them to the PMIII sidebar shortcuts.

[jmarshall]

The sort by methods for that suck anyway IMO. Alphabetical + xml order should suffice (what is the point of Type, after all).

If you can come up with a good short string for "original order", I'm sure that we can easily add a stub that'll disable sorting in that case. You may be able to do it already by hacking the ViewModes.db file in fact - change your sort order while in the root to get it saved in the db, then edit the db and change the sortmethod to 0. You'll notice it's stored by window ID and path (root:// in this case).

Cheers,
Jonathan

[lexicon]

If you can come up with a good short string for "original order", I'm sure that we can easily add a stub that'll disable sorting in that case.

hmmm, "XML"? "Config"? "Bookmark" "Original" or "Orig"?

You may be able to do it already by hacking the ViewModes.db file in fact - change your sort order while in the root to get it saved in the db, then edit the db and change the sortmethod to 0. You'll notice it's stored by window ID and path (root:// in this case).

nope, couldn't get that working. Cycling sort methods and orders while in My Videos didn't add such an entry to the db. I quickly tried adding this manually:

idView window path viewMode sortMethod sortOrder
14 10006 root:// 65586 0 0

where I thought 10006 was the Videos window, 65586 was just copied from another entry, and 0,0 for sorting.