Re: [Patch] Make RGYB buttons customizeable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 02.04.2011 12:23, schrieb Klaus Schmidinger:
> I could imagine accepting a patch that centralizes handling
> the sequence in which the color buttons are displayed, and
> offers a standard interface to skin plugins that allows
> them to arrange the color buttons accordingly.
> 
> What I don't want to change is the actual functionality
> of the color buttons, meaning, for instance, the red button
> will always have the same functionality, no matter what sequence the
> remote control uses. 


There is no simple solution to this. The problem is, that in some cases
the meaning of the button is linked to their color ('red' means
recording), and in some cases the meaning is linked to the placement
(button 2 for backwards, 3 for forward).

Making the color <-> placement relation configurable will automatically
break one or the other. The only 'clean' solution would be to decide by
situation whether key assignment should be by-placement or by-color. So
for example, in replay the assignment is BUTTON_1=jump, BUTTON_2=skip
back, BUTTON_3=skip fwd, BUTTON_4=stop, while in EPG view, the
assignment is BUTTON_RED=record, BUTTON_GREEN=now, BUTTON_YELLOW=next,
BUTTON_BLUE=switch.

Generally, the goal is to match the color order in the OSD with the
order on the remote, so the skins need to know the ordering. VDR
internally, the keys are called kRed, kGreen, kYellow, kBlue, their
meaning is obviously color related. So as long as the red button stays
the red button, it doesn't matter whether the skin displays the red
color button label on the left or right.


The most difficult question is, how to handle buttons by placement. A
eKeys key cannot be kRed and kButton1 at the same time. Any query
interface would break all the nice switch(Key) statements. (case
getColorOfButton1(): ... is not a constant.)

My suggestion would be to add pseudo keys kButton1..kButton4, that are
only transformed on demand:

switch (Key) {
case kRed: ....

switch (MAP_COLOR_KEYS_TO_PLACEMENT(key)) {
case kButton1: ...


Also, there should be a wrapper for SetHelp() to set the button labels
by placement, so you either call SetHelp("Red", "Green", "Yellow",
"Blue"), or SetHelpByPlacement("Left", "Mid-Left", "Mid-Right", "Right").


Finally, some documentation will need rewrites, from green/yellow to
mid-left, mid-right color button to skip fwd/bwd.


All in all a lot of changes to do it properly...


Cheers,

Udo

PS: My remote has the color order red, green, yellow, blue, purple. ;)


_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux