So from what I've found out it looks like new controls will be needed to skin the EPG (tv-gude) gridview.
I'd also like to investigate setting the horizontal time span by aspect ratio. (To avoid having the grid compressed for 4x3 display owners. In their case it makes more sense to display less hours than to try and display the same amount of info in a reduced screen area.
Could we let the user choose the number of channels vertically? Does this make life much harder for skinning?
I'd welcome the skinner's POV on these points, let me know what you want or need..
Proto-crappy mockups
Love it, I hope it takes advantage of a 720p display and shows many channels at a time
Id say more, but we've already talked
NineT9mustang Wrote:Love it, I hope it takes advantage of a 720p display and shows many channels at a time
Id say more, but we've already talked
That's basically the main thing for me, having the grid scale in a smart fashion for the big variances in available screen space.
Looks quite nice so far. Without being able to see what is going on "behind the scenes" I would say if you had an option to select how many time blocks are visible on the screen that it *shouldn't* effect skinning. The time block unfocused and focused colors could just be 1px images that would fill the area as required. This might not work, as I said I don't really know what or how you have coded the thing. It seems like the easiest way to do it would be to have predefined areas, ie focused button, unfocused, panel width, panel height, genre(sports), genre(comedy), button locations etc. Then the skinner can just edit the xml to match their skin. That would still allow the skinner to edit the layout of the epg to match their skin. It would also make it easy to add a PMIII epg to skins that the skinner has stopped working on as you could just copy the default from PMIII. They would be missing some textures but it would work. The only thing i worry about is that if the skinner changes the width/height of the panel the epg would have to do the math dynamically to put in the proper amount of rows/columns as selected in the epg settings menu. Unless you want to leave the rows/columns # up to the skinner which I personally think would lead to users have less choices. Just my random thoughts on it. Cheers.
BTW These are compositions made in photoshop, not actual skins
Rand Al Thor Wrote:..[snip]..It seems like the easiest way to do it would be to have predefined areas, ie focused button, unfocused, panel width, panel height, genre(sports), genre(comedy), button locations etc. Then the skinner can just edit the xml to match their skin. That would still allow the skinner to edit the layout of the epg to match their skin. It would also make it easy to add a PMIII epg to skins that the skinner has stopped working on as you could just copy the default from PMIII. They would be missing some textures but it would work. The only thing i worry about is that if the skinner changes the width/height of the panel the epg would have to do the math dynamically to put in the proper amount of rows/columns as selected in the epg settings menu. Unless you want to leave the rows/columns # up to the skinner which I personally think would lead to users have less choices. Just my random thoughts on it. Cheers.
I *do* want to leave the numbers of rows & columns up to the skinner.
For instance with a 1080p skin with acres of room, they can have 15 channels vertically, whereas with PAL 4x3 you wouldn't want more than 6 maybe, text would get too small.
Or another way: you have a 1080p skin with two views. One where the EPG fills the whole screen, the other where the EPG is half the screen height, with the rest transparent showing the video underneath. Ideally these decisions would be made in the skin, not the coding.
All I need to know is howmanychannels*howmanyhours of EPG to queue up, otherwise you'd get the same in both circumstances, and the skin would have to squash the layout for the second scenario.
alcoheca Wrote:I'd also like to investigate setting the horizontal time span by aspect ratio. (To avoid having the grid compressed for 4x3 display owners. In their case it makes more sense to display less hours than to try and display the same amount of info in a reduced screen area.
Yes that is why XBMC skinning-engine suppors using different XML files for each resolution and aspect-ratio. For example the Project Mayhem 3 skin takes advantage of a 16:9 widescreen non-HDTV display in by displaying one more colum of movie-covers when in 16:9 mode compared to 4:3 mode (IIRC PM3 displays 4 movie-covers horisontally while in 16:9 mode, and only 3 movie-covers horisontally in 4:3 mode). Also in 720p (which is always 16:9 aspect-ratio) the PM3 skin displays even more covers both horisontally and vertically, and in 1080i/1080p even more than 720p (I think).
alcoheca Wrote:I *do* want to leave the numbers of rows & columns up to the skinner.
For instance with a 1080p skin with acres of room, they can have 15 channels vertically, whereas with PAL 4x3 you wouldn't want more than 6 maybe, text would get too small.
Great!
Hi Gamester17,
I still need to know the size of the numChannels*numTimeUnits grid which would make up the on screen EPG. Those values would be used while navigating up/down/left/right.
I could retrieve the values during the xml loading stage. At the moment this seems like the most sensible way.
On a related note, what about allowing the user to fine tune this? The space in the skin allocated would not change size, but the griditems (the coloured blocks representing programs in a timeline) would then expand or reduce, including the text. Only reason I want to mention this is I don't mind small text on screen, when others get headaches looking at them. Might be good to allow for this. (More useful than just increasing the font size alone).
alcoheca Wrote:Hi Gamester17,
On a related note, what about allowing the user to fine tune this? The space in the skin allocated would not change size, but the griditems (the coloured blocks representing programs in a timeline) would then expand or reduce, including the text. Only reason I want to mention this is I don't mind small text on screen, when others get headaches looking at them. Might be good to allow for this. (More useful than just increasing the font size alone).
That is what i was talking about in my post. The skinner makes the dimensions of the main window which would stay static. Then the user would have an option in the settings menu to select # of columns and # of rows. The skinner would just provide a color for onfocus, unfocus, text, etc. but the program would dynamically scale the boxes per the users preference and fill them appropriately. I think this would lead to more options for the user. Cheers.
Ahh, one more thing. Can't edit my previous post. You might want to leave the column that shows channel # and logo static and up to the discretion of the skinner so that that column doesn't get scaled too small to see the channel logos. Just a thought.
@ Rand Al Thor, you can now
Rand Al Thor Wrote:Ahh, one more thing. Can't edit my previous post. You might want to leave the column that shows channel # and logo static and up to the discretion of the skinner so that that column doesn't get scaled too small to see the channel logos. Just a thought.
I totally agree - I doubt that column will scale at all with these user options. What I'm talking about is a +/- 1 unit of fine tuning for number channel rows vertically and number of time units horizontally. The emphasis firmly being on fine tuning. I think you were suggesting more control to choose more extreme grid dimensions?
To be honest, I'd tend to be a little hesitant to allow users to change the layout too much. The skinners know what they're doing and what looks good within their skin and works well from a usability point of view (for the most part). This is what they do "for a living" after all.
I guess it depends on the resolution to some extent though. Larger numbers of pixels to play with allows more options in some respects.
Navigation-wise, I'm thinking we can show 24 hours at a time (i.e. from the start of the current timeblock), with free scrolling horizontally within the 24 hours and then a jump to the next block, or, if we can get away with it memory + loading-wise free scrolling right up to the end of the EPG information.
Vertical scrolling would be like the normal list controls today. Whether or not we need to be able to navigate away from the grid (i.e. we'd currently be trapped if we use the dpad to navigate) needs to be considered as well.
Cheers,
Jonathan
