Consistency

[smeghead]

I am really impressed with all the plugins that are now available for GBPVR. However, one of the big advantages to me and the "Wife Acceptance Factor" for something like BeyondTV is that they maintain a common set of button presses to do the same or similar things in all the different bits of the software. For instance

1. Page up / Page Down. Page down seems to be Blue button but can we "standardise" on page up?  Yellow or Green
2. Menu Button - Xrecord goes to side menu and then out to main menu on a second press. The "My" series goes straight out to the main menu on a single press.

What do you think - is it possible that the plugin developers (and sub) can agree on these things.

Also I am sure there are more buttons that could be standardised............

[reven]

i originally had it as "green" = page up, which is what sub appears to be using, but it was a major design flaw with any remote other than the older hauppauge remote, since the colour buttons are red green yellow blue. then i changed the page up to yellow so they are next to each other, and work just as well on the older hauppauge remote. it makes the most sense. also my sky digital box uses yellow/blue for the page up/down.

[TechVW]

I dont think the colored buttons should be used for any major functionality. The Skip left and right buttons make more sense for paging up and down. Colors dont mean anything to a new user.

Its also not a good idea to assume everyone is using the same remote. I am using a Firefly (which doesnt have color buttons)

[reven]

the skip buttons shouldnt be used for this, they cause issues with music playback, the colour buttons can be found on most remotes (the mce and hauppauge ones, which are the most common remotes). the skip just cause to much issues.

[Jeff]

I like the skip buttons for page up and down (and use them for this purpose in my plug-in), although I do understand the problem with the music. I recall and old post where sub said that he tened to use these buttons for page up and down except for the TV guide, where he had them do day forward and backward and used to of the colored buttons for page up and down, or something like that.

It seems to me that when a plug-in is active and consumes those events GBPVR should not process them with respect to the music tracks. If someone is in the main menu then these buttons could again be used to control music playback control. I've never tried playing music wile in the TV guide to see what they also control the music in this case.

Jeff

[colin]

Someone once talked about doing a widget library which would solve a lot of these inconsistencies. It might be worth thinking about designing a common library with this in mind.

Cheers,
Colin.

[reven]

im rethinking this again. a few plugins have a unique menu (eg the menu in "my videos", yeah i know its my plugin ). so i was thinking of instead of using "menu" = return to main menu. use "menu" to bring up the unique menu, and a lot of people seem to have the newer hauppauge remote, which has a "Go" button. Yeah its on the old one too, but this one has a pretty little "home" painted on it. so i was thinking of using that as "home" ie return to main menu, makes sense, no?

i really want a standard set of buttons, everyone wants it, we really need to have a big discussion and just set it out. i suggest
page up = yellow
page down = blue
main menu = home
alternate page up = rewind (since this doesnt effect music playback, ie instead of using skip)
aternate page down = fastforward.

leaving
red,blue, back, home for each plugin to customize, might want to make similar however, eg if you have "change view" use the same as "change view" in other plugins etc.

also sub could you make it so gbpvr sets the same keystorkes as "func" and "full" on the older hauppuage remote to "text/*" and "sub/cc/#" on the newer one? these buttons dont seem to be set (well i dont think they are) and would allow use of them on both remotes. i want to use "func" as a backspace but the newer remote doesnt have it. (running low on buttons).

oh yeah i often listen to music while browsing for things to watch, so the skip in tv guide is annoying. the skip/prev should be left alone, play is alright, since if you going to play a show the music will stop anyway.

ok turn for your thoughts.

[Lucas_24]

The reason I don't use my new Hauppauge remote yet is because of the location of the color buttons. When browsing the guide the page up down buttons make sense on the older remote, but are pretty akward on the newer remote since they are line up at the bottom. Just a big "IF", but if everyone had the new remote, the channel up down seems to be a great set of buttons for page up down. If you're watching live TV, and the new live TV guide is not active, channel up down is channel up down. Everywhere else, it's page up down. I think it would be pretty intuative. But not everyone uses the new Hauppauge remote.

Ultimatly, I think it would be great if teh remote buttons were mappeable in the Skin.XML files for each plugin. So something like Xrecord. You press the yellow button to switch the group view.

SwitchGroup = Yellow

Now the user can change it to whatever he wants. I guess there would have to be a button definition file for every supported remote as well, but in the end, the users could choose what fits them best.

just a thought.

[KingArgyle]

Also to address the consistency thing, I had started a thread in the developers forum on a possible redesign of the skin.xml files, to include the actual screens and the widgets they use to make up the screen.

Currently the skin.xml just defines a bunch of widgets grouped together, and there is no way to really determine which widget is used on what screen a plugin may have. If a plugin only has a single screen then the current format is fine, but when a plugin starts to have multiple screens it gets kind of difficult to figure out what needs to be skinned.

Anyway, maybe I'm totally off base and there isn't a problem in this aspect.

[jasonf]

I didn't know that this thread had expanded so much.  I sent this email to Sub this morning with a scheme to handle the consistency issue:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Hi Sub,

Wondering if you might find the following worthwhile for implementing in GBPVR.

It seems that consistency is an issue for plugin developers in how
they handle keypress events, or more specifically, how they map
keypresses to actions within their plugin.  In addition, the use of
the "color" keys on the hauppague remote does not translate well to,
say, the firefly remote.  Therefore, I'm proposing that we externalize
remote mappings and key press actions so that ultimately, the user can
change behavior if they need to remap an action to a different remote
key.

I came up with the following sample xml files.  The first one is a
"remote control key mapping file".  It simply provides a name to each
keypress, and could be defined for any number of remote controls (some
mapping names would be "global").

<remoteControlMappings>
      <map name="LeftArrow" keypress="{left}" />
      <map name="RightArrow" keypress="{right}" />
      <map name="UpArrow" keypress="{up}" />
      <map name="DownArrow" keypress="{down}" />
      <map name="Escape" keypress="{esc}" />
      <map name="Number0" keypress="0" />
      <map name="Number1" keypress="1" />
      <map name="Number2" keypress="2" />
      <map name="Number3" keypress="3" />
      <map name="Number4" keypress="4" />
      <map name="Number5" keypress="5" />
      <map name="Number6" keypress="6" />
      <map name="Number7" keypress="7" />
      <map name="Number8" keypress="8" />
      <map name="Number9" keypress="9" />
      <map name="Rewind" keypress="^R" />
      <map name="Forward" keypress="^F" />
</remoteControlMappings>

The next xml file is an "keypress action" file.  It maps an
application-defined string to a remote key mapping name.  This is
where the user could perform their own custom mappings (perhaps using
a helper application to make it easier for a novice):

<keypressActions>
      <action name="solitaire.Left" mapping="LeftArrow" />
      <action name="solitaire.Right" mapping="RightArrow" />
      <action name="solitaire.Up" mapping="UpArrow" />
      <action name="solitaire.Down" mapping="DownArrow" />
      <action name="solitaire.Escape" mapping="Escape" />
      <action name="solitaire.Redeal" mapping="Number0" />
      <action name="solitaire.Deck" mapping="Number1" />
      <action name="solitaire.Undo" mapping="Rewind" />
</keypressActions>

A wrapper class (part of GBPVR.Public namespace) could be instantiated
when gbpvr initializes.  This class will perform the actual
translation that, in this example, sets "solitaire.Left" to be the
keypress "{left}".

The OnKeypress event handler within the plugin, then, would use this
wrapper class to when checking which key was pressed.

So, instead of:

if (e.KeyCode == System.Windows.Forms.Keys.Up)
{
      CursorUp();
      return true;
}

The plugin developer might use:

if (e.KeyCode == keypressActionMapper.getKeyCode("solitaire.Up"))
{
      CursorUp();
      return true;
}
[/QUOTE]