Make RGYB buttons customizeable

Message ID 4C917B54.3030701@schinagl.nl
State New
Headers

Commit Message

Olliver Schinagl Sept. 16, 2010, 2:05 a.m. UTC
  Hey all,

Ever had the trouble that your remote's color navigation key weren't the
same as VDR's? Well I wrote this patch the past 4 hours which lets you
configure them.

By doing so, the order of the buttons in the menu changes depending on
whatever you tell it to. So finally that remote can match whatever is
displayed on screen.

This only works for the classic and st-tng  skins, as those are supplied
with VDR. The Skin needs to support this feature. If there is no skin
support, the setting simply gets ignored by that skin. Since only the
order of the buttons in the skin are being changed any plugin
configuration will be independent from this change. What I mean is that,
when a plugin has configured blue to take you straight to the photo
gallery, the blue button will still do this, no matter where it is on
the remote. If the plugin however used the blue key to fast forward,
because it is the right most key, and thus made sense logically there,
it will no longer when you move the keys around. Practically, this will
boil down to a handful of plugins depending on location which imo is a
little weird anyway :)

Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have
so line numbers may be a little off in the patch due to various patches
Gentoo may apply. It's the only dev. box for VDR I have so forgive me on
that.

I'm looking forward to the review :)

Oliver
  

Comments

Olliver Schinagl Oct. 19, 2010, 7:16 a.m. UTC | #1
Nobody has any comment at all? :)

I haven't found an issue as of yet running this for weeks now on my own
VDR. I must say, it is nice to have the color order of the buttons match
my remote :)

On 09/16/10 04:05, Oliver Schinagl wrote:
> Hey all,
>
> Ever had the trouble that your remote's color navigation key weren't the
> same as VDR's? Well I wrote this patch the past 4 hours which lets you
> configure them.
>
> By doing so, the order of the buttons in the menu changes depending on
> whatever you tell it to. So finally that remote can match whatever is
> displayed on screen.
>
> This only works for the classic and st-tng  skins, as those are supplied
> with VDR. The Skin needs to support this feature. If there is no skin
> support, the setting simply gets ignored by that skin. Since only the
> order of the buttons in the skin are being changed any plugin
> configuration will be independent from this change. What I mean is that,
> when a plugin has configured blue to take you straight to the photo
> gallery, the blue button will still do this, no matter where it is on
> the remote. If the plugin however used the blue key to fast forward,
> because it is the right most key, and thus made sense logically there,
> it will no longer when you move the keys around. Practically, this will
> boil down to a handful of plugins depending on location which imo is a
> little weird anyway :)
>
> Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have
> so line numbers may be a little off in the patch due to various patches
> Gentoo may apply. It's the only dev. box for VDR I have so forgive me on
> that.
>
> I'm looking forward to the review :)
>
> Oliver
>
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
VDRU VDRU Oct. 19, 2010, 8:14 a.m. UTC | #2
On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
> Nobody has any comment at all? :)
>
> I haven't found an issue as of yet running this for weeks now on my own VDR.
> I must say, it is nice to have the color order of the buttons match my
> remote :)

The color arrangement already matches all of my remotes so I don't
have any use for it.  However, because I think it's useful to other
users since a lot of remotes have a different color order, I'll help
test it if you provide a VDR-1.7.16 compatible patch.  That's my only
condition as I'm not willing to downgrade my VDR boxes for this.

If your patch made it into VDR and there are any plugins which use
position to relate functions as you described (for example, right most
key=ffwd) then maybe there also needs to be some mechanism for plugins
to know which key is where (if there isn't one already).  After VDR
has been programmed for red/green/blue/yellow keys, then it can
associate something like color1/color2/color3/color4 to the color
order.

Another thought is that VDR is supposed to get a truecolor OSD upgrade
so we'll finally be able to have a great looking (HD) interface to use
VDR with.  Maybe the functionality of your patch is something Klaus
has already considered during that upgrade.  That's only speculation
however but worth asking I think.

Regards.
  
Rainer Blickle March 29, 2011, 8 a.m. UTC | #3
I've tried the patch and it worked at the first glance. But with the
plugin Extrecmenu there are problems with the color keys. So i rolled
back the patch.

2010/10/19 VDR User <user.vdr@gmail.com>:
> On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
>> Nobody has any comment at all? :)
>>
>> I haven't found an issue as of yet running this for weeks now on my own VDR.
>> I must say, it is nice to have the color order of the buttons match my
>> remote :)
>
> The color arrangement already matches all of my remotes so I don't
> have any use for it.  However, because I think it's useful to other
> users since a lot of remotes have a different color order, I'll help
> test it if you provide a VDR-1.7.16 compatible patch.  That's my only
> condition as I'm not willing to downgrade my VDR boxes for this.
>
> If your patch made it into VDR and there are any plugins which use
> position to relate functions as you described (for example, right most
> key=ffwd) then maybe there also needs to be some mechanism for plugins
> to know which key is where (if there isn't one already).  After VDR
> has been programmed for red/green/blue/yellow keys, then it can
> associate something like color1/color2/color3/color4 to the color
> order.
>
> Another thought is that VDR is supposed to get a truecolor OSD upgrade
> so we'll finally be able to have a great looking (HD) interface to use
> VDR with.  Maybe the functionality of your patch is something Klaus
> has already considered during that upgrade.  That's only speculation
> however but worth asking I think.
>
> Regards.
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  
Olliver Schinagl March 29, 2011, 8:17 a.m. UTC | #4
I've never heard of that plugin before, and don't have it as such, so no
idea how it goes wrong.

Can you more closely describe how it goes wrong? From the description, I
think they implement their own additional 'skin' and thus the plugin
would have to be ported aswel.

On 03/29/11 10:00, Rainer Blickle wrote:
> I've tried the patch and it worked at the first glance. But with the
> plugin Extrecmenu there are problems with the color keys. So i rolled
> back the patch.
>
> 2010/10/19 VDR User <user.vdr@gmail.com>:
>> On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
>>> Nobody has any comment at all? :)
>>>
>>> I haven't found an issue as of yet running this for weeks now on my own VDR.
>>> I must say, it is nice to have the color order of the buttons match my
>>> remote :)
>> The color arrangement already matches all of my remotes so I don't
>> have any use for it.  However, because I think it's useful to other
>> users since a lot of remotes have a different color order, I'll help
>> test it if you provide a VDR-1.7.16 compatible patch.  That's my only
>> condition as I'm not willing to downgrade my VDR boxes for this.
>>
>> If your patch made it into VDR and there are any plugins which use
>> position to relate functions as you described (for example, right most
>> key=ffwd) then maybe there also needs to be some mechanism for plugins
>> to know which key is where (if there isn't one already).  After VDR
>> has been programmed for red/green/blue/yellow keys, then it can
>> associate something like color1/color2/color3/color4 to the color
>> order.
>>
>> Another thought is that VDR is supposed to get a truecolor OSD upgrade
>> so we'll finally be able to have a great looking (HD) interface to use
>> VDR with.  Maybe the functionality of your patch is something Klaus
>> has already considered during that upgrade.  That's only speculation
>> however but worth asking I think.
>>
>> Regards.
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
Rainer Blickle March 29, 2011, 9:17 a.m. UTC | #5
I will take a look on it

2011/3/29 Oliver Schinagl <oliver@schinagl.nl>:
> I've never heard of that plugin before, and don't have it as such, so no
> idea how it goes wrong.
>
> Can you more closely describe how it goes wrong? From the description, I
> think they implement their own additional 'skin' and thus the plugin
> would have to be ported aswel.
>
> On 03/29/11 10:00, Rainer Blickle wrote:
>> I've tried the patch and it worked at the first glance. But with the
>> plugin Extrecmenu there are problems with the color keys. So i rolled
>> back the patch.
>>
>> 2010/10/19 VDR User <user.vdr@gmail.com>:
>>> On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
>>>> Nobody has any comment at all? :)
>>>>
>>>> I haven't found an issue as of yet running this for weeks now on my own VDR.
>>>> I must say, it is nice to have the color order of the buttons match my
>>>> remote :)
>>> The color arrangement already matches all of my remotes so I don't
>>> have any use for it.  However, because I think it's useful to other
>>> users since a lot of remotes have a different color order, I'll help
>>> test it if you provide a VDR-1.7.16 compatible patch.  That's my only
>>> condition as I'm not willing to downgrade my VDR boxes for this.
>>>
>>> If your patch made it into VDR and there are any plugins which use
>>> position to relate functions as you described (for example, right most
>>> key=ffwd) then maybe there also needs to be some mechanism for plugins
>>> to know which key is where (if there isn't one already).  After VDR
>>> has been programmed for red/green/blue/yellow keys, then it can
>>> associate something like color1/color2/color3/color4 to the color
>>> order.
>>>
>>> Another thought is that VDR is supposed to get a truecolor OSD upgrade
>>> so we'll finally be able to have a great looking (HD) interface to use
>>> VDR with.  Maybe the functionality of your patch is something Klaus
>>> has already considered during that upgrade.  That's only speculation
>>> however but worth asking I think.
>>>
>>> Regards.
>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  
Rainer Blickle March 30, 2011, 11:39 a.m. UTC | #6
Sorry for the noise, because:

when learning lirc i havn't pressed the colors vdr wanted to be
pressed, i pressed them from left to right. Afterwards, when switching
the colors of the on-screen buttons, i thought only the color but not
the positions of the on screen buttons get changed.

When pressing the correct color buttons while learning, everything is
ok. But i don't want this because then jumping +/- 1 minute while
watching a recording are not on the middle color keys.

All i would like to have is that only the color on the on-screen
buttons changes.

2011/3/29 Rainer Blickle <rainer.blickle@googlemail.com>:
> I will take a look on it
>
> 2011/3/29 Oliver Schinagl <oliver@schinagl.nl>:
>> I've never heard of that plugin before, and don't have it as such, so no
>> idea how it goes wrong.
>>
>> Can you more closely describe how it goes wrong? From the description, I
>> think they implement their own additional 'skin' and thus the plugin
>> would have to be ported aswel.
>>
>> On 03/29/11 10:00, Rainer Blickle wrote:
>>> I've tried the patch and it worked at the first glance. But with the
>>> plugin Extrecmenu there are problems with the color keys. So i rolled
>>> back the patch.
>>>
>>> 2010/10/19 VDR User <user.vdr@gmail.com>:
>>>> On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
>>>>> Nobody has any comment at all? :)
>>>>>
>>>>> I haven't found an issue as of yet running this for weeks now on my own VDR.
>>>>> I must say, it is nice to have the color order of the buttons match my
>>>>> remote :)
>>>> The color arrangement already matches all of my remotes so I don't
>>>> have any use for it.  However, because I think it's useful to other
>>>> users since a lot of remotes have a different color order, I'll help
>>>> test it if you provide a VDR-1.7.16 compatible patch.  That's my only
>>>> condition as I'm not willing to downgrade my VDR boxes for this.
>>>>
>>>> If your patch made it into VDR and there are any plugins which use
>>>> position to relate functions as you described (for example, right most
>>>> key=ffwd) then maybe there also needs to be some mechanism for plugins
>>>> to know which key is where (if there isn't one already).  After VDR
>>>> has been programmed for red/green/blue/yellow keys, then it can
>>>> associate something like color1/color2/color3/color4 to the color
>>>> order.
>>>>
>>>> Another thought is that VDR is supposed to get a truecolor OSD upgrade
>>>> so we'll finally be able to have a great looking (HD) interface to use
>>>> VDR with.  Maybe the functionality of your patch is something Klaus
>>>> has already considered during that upgrade.  That's only speculation
>>>> however but worth asking I think.
>>>>
>>>> Regards.
>>>>
>>>> _______________________________________________
>>>> vdr mailing list
>>>> vdr@linuxtv.org
>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
  
Olliver Schinagl March 30, 2011, 1:15 p.m. UTC | #7
I belive that is exactly only what this patch does, it changes the
positions on the screen for the ST-NG theme I think (it's been a while I
admit).

So if VDR is told that the red button performs the job of the red
button, then everything is ok.

To recap, the problem I had with VDR that caused me to write this patch,
was:

My Remote control had 2 buttons different from where VDR expected the
buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
control was Red Yellow Blue Green.

So in the end, this patch works for you and does what you want? Or is
your remote layed out as VDR expects it?

On 03/30/11 13:39, Rainer Blickle wrote:
> Sorry for the noise, because:
>
> when learning lirc i havn't pressed the colors vdr wanted to be
> pressed, i pressed them from left to right. Afterwards, when switching
> the colors of the on-screen buttons, i thought only the color but not
> the positions of the on screen buttons get changed.
>
> When pressing the correct color buttons while learning, everything is
> ok. But i don't want this because then jumping +/- 1 minute while
> watching a recording are not on the middle color keys.
>
> All i would like to have is that only the color on the on-screen
> buttons changes.
>
> 2011/3/29 Rainer Blickle <rainer.blickle@googlemail.com>:
>> I will take a look on it
>>
>> 2011/3/29 Oliver Schinagl <oliver@schinagl.nl>:
>>> I've never heard of that plugin before, and don't have it as such, so no
>>> idea how it goes wrong.
>>>
>>> Can you more closely describe how it goes wrong? From the description, I
>>> think they implement their own additional 'skin' and thus the plugin
>>> would have to be ported aswel.
>>>
>>> On 03/29/11 10:00, Rainer Blickle wrote:
>>>> I've tried the patch and it worked at the first glance. But with the
>>>> plugin Extrecmenu there are problems with the color keys. So i rolled
>>>> back the patch.
>>>>
>>>> 2010/10/19 VDR User <user.vdr@gmail.com>:
>>>>> On Tue, Oct 19, 2010 at 12:16 AM, Oliver Schinagl <oliver@schinagl.nl> wrote:
>>>>>> Nobody has any comment at all? :)
>>>>>>
>>>>>> I haven't found an issue as of yet running this for weeks now on my own VDR.
>>>>>> I must say, it is nice to have the color order of the buttons match my
>>>>>> remote :)
>>>>> The color arrangement already matches all of my remotes so I don't
>>>>> have any use for it.  However, because I think it's useful to other
>>>>> users since a lot of remotes have a different color order, I'll help
>>>>> test it if you provide a VDR-1.7.16 compatible patch.  That's my only
>>>>> condition as I'm not willing to downgrade my VDR boxes for this.
>>>>>
>>>>> If your patch made it into VDR and there are any plugins which use
>>>>> position to relate functions as you described (for example, right most
>>>>> key=ffwd) then maybe there also needs to be some mechanism for plugins
>>>>> to know which key is where (if there isn't one already).  After VDR
>>>>> has been programmed for red/green/blue/yellow keys, then it can
>>>>> associate something like color1/color2/color3/color4 to the color
>>>>> order.
>>>>>
>>>>> Another thought is that VDR is supposed to get a truecolor OSD upgrade
>>>>> so we'll finally be able to have a great looking (HD) interface to use
>>>>> VDR with.  Maybe the functionality of your patch is something Klaus
>>>>> has already considered during that upgrade.  That's only speculation
>>>>> however but worth asking I think.
>>>>>
>>>>> Regards.
>>>>>
>>>>> _______________________________________________
>>>>> vdr mailing list
>>>>> vdr@linuxtv.org
>>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>>>
>>>> _______________________________________________
>>>> vdr mailing list
>>>> vdr@linuxtv.org
>>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
Steffen Barszus March 30, 2011, 1:45 p.m. UTC | #8
2011/3/30 Oliver Schinagl <oliver@schinagl.nl>:
> I belive that is exactly only what this patch does, it changes the
> positions on the screen for the ST-NG theme I think (it's been a while I
> admit).
>
> So if VDR is told that the red button performs the job of the red
> button, then everything is ok.
>
> To recap, the problem I had with VDR that caused me to write this patch,
> was:
>
> My Remote control had 2 buttons different from where VDR expected the
> buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
> control was Red Yellow Blue Green.
>
> So in the end, this patch works for you and does what you want? Or is
> your remote layed out as VDR expects it?

I would say better "patch" your remote. A sharp knife and a
screwdriver might be quite effective and will fix the problem also for
the next vdr releases ^^

SCNR

Steffen
  
Rainer Blickle March 31, 2011, 1:40 p.m. UTC | #9
2011/3/30 Steffen Barszus <steffenbpunkt@googlemail.com>:
> 2011/3/30 Oliver Schinagl <oliver@schinagl.nl>:
>> I belive that is exactly only what this patch does, it changes the
>> positions on the screen for the ST-NG theme I think (it's been a while I
>> admit).
>>
>> So if VDR is told that the red button performs the job of the red
>> button, then everything is ok.
>>
>> To recap, the problem I had with VDR that caused me to write this patch,
>> was:
>>
>> My Remote control had 2 buttons different from where VDR expected the
>> buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
>> control was Red Yellow Blue Green.

My remote has the color order Yellow, Red, Blue, Green (only an
example, i dont have the remote at hand). Lets say the buttons are
Button0, Button1, Button2, Button3

When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed.

In the vdr layout Button0 is Red, Button1 is Yellow and so on ...
while watching a recording vdr jumps 1 minute in the past when
pressing yellow and one minute in the future when pressing green.
These are the "middle" color buttons.

I also wanted to have this functionality in the "middle" buttons (on
the buttons 1 and 2).

So i pressed the Buttons Yellow, Red, Blue, Green while learning
Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute
functionality still on the middle color buttons.

The only thing left is that the color on the osd has to be adjusted,
but not the positions of the text on it. If have dont this by
modifying your patch (the texts for ->DrawText are taken directly from
the parameters, not from the mapping).

My (and perhaps only my) opinion is that vdr should request the
leftmost color button, then the color right next to it (and so on)
while learning. The color displayed in the osd should be assigned via
the setup menu.

@Klaus: If there is a change to integrate this into the vdr, i would
provide a patch for it.




>>
>> So in the end, this patch works for you and does what you want? Or is
>> your remote layed out as VDR expects it?
>
> I would say better "patch" your remote. A sharp knife and a
> screwdriver might be quite effective and will fix the problem also for
> the next vdr releases ^^

This would be a real good solution, but i dont want to void my warranty :-)

>
> SCNR
>
> Steffen
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  
Olliver Schinagl April 1, 2011, 7:42 a.m. UTC | #10
Ah, I use a lirc based remote and don't learn anything. I've just told
VDR, that my VDR_RED is LIRC_RED etc, so when I press the red button,
the action that is bound to VDR_RED is executed, regardless of the
location of the button. This patch only changes the OSD location of the
button, to match the location on the remote.

On 03/31/11 15:40, Rainer Blickle wrote:
> 2011/3/30 Steffen Barszus <steffenbpunkt@googlemail.com>:
>> 2011/3/30 Oliver Schinagl <oliver@schinagl.nl>:
>>> I belive that is exactly only what this patch does, it changes the
>>> positions on the screen for the ST-NG theme I think (it's been a while I
>>> admit).
>>>
>>> So if VDR is told that the red button performs the job of the red
>>> button, then everything is ok.
>>>
>>> To recap, the problem I had with VDR that caused me to write this patch,
>>> was:
>>>
>>> My Remote control had 2 buttons different from where VDR expected the
>>> buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
>>> control was Red Yellow Blue Green.
> My remote has the color order Yellow, Red, Blue, Green (only an
> example, i dont have the remote at hand). Lets say the buttons are
> Button0, Button1, Button2, Button3
>
> When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed.
>
> In the vdr layout Button0 is Red, Button1 is Yellow and so on ...
> while watching a recording vdr jumps 1 minute in the past when
> pressing yellow and one minute in the future when pressing green.
> These are the "middle" color buttons.
>
> I also wanted to have this functionality in the "middle" buttons (on
> the buttons 1 and 2).
>
> So i pressed the Buttons Yellow, Red, Blue, Green while learning
> Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute
> functionality still on the middle color buttons.
>
> The only thing left is that the color on the osd has to be adjusted,
> but not the positions of the text on it. If have dont this by
> modifying your patch (the texts for ->DrawText are taken directly from
> the parameters, not from the mapping).
>
> My (and perhaps only my) opinion is that vdr should request the
> leftmost color button, then the color right next to it (and so on)
> while learning. The color displayed in the osd should be assigned via
> the setup menu.
>
> @Klaus: If there is a change to integrate this into the vdr, i would
> provide a patch for it.
>
>
>
>
>>> So in the end, this patch works for you and does what you want? Or is
>>> your remote layed out as VDR expects it?
>> I would say better "patch" your remote. A sharp knife and a
>> screwdriver might be quite effective and will fix the problem also for
>> the next vdr releases ^^
> This would be a real good solution, but i dont want to void my warranty :-)
>
>> SCNR
>>
>> Steffen
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
fnu April 1, 2011, 10:13 a.m. UTC | #11
> My remote has the color order Yellow, Red, Blue, Green (only an example, i
dont have the remote at hand). Lets say the buttons are Button0, Button1,
Button2, Button3

> My (and perhaps only my) opinion is that vdr should request the leftmost
color button, then the color right next to it (and so on) while learning.
The color displayed in the osd should be assigned via the setup menu.

Are you seriously asking for a major change like this, just for your most
propably unique remote control?

The color order of the RGYB buttons is a common standard, defined for
Teletext centuries ago. So, 99.999% of all remotes providing these keys do
have this order.

http://en.wikipedia.org/wiki/Teletext

Regards
fnu
  
Rainer Blickle April 1, 2011, 12:54 p.m. UTC | #12
Yes i do. But the request can be refused, of course. Why not asking.

I have a hama MCE ir. Dont know how many people use this remote.

2011/4/1 fnu <vdr@auktion.hostingkunde.de>:
>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
> dont have the remote at hand). Lets say the buttons are Button0, Button1,
> Button2, Button3
>
>> My (and perhaps only my) opinion is that vdr should request the leftmost
> color button, then the color right next to it (and so on) while learning.
> The color displayed in the osd should be assigned via the setup menu.
>
> Are you seriously asking for a major change like this, just for your most
> propably unique remote control?
>
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.
>
> http://en.wikipedia.org/wiki/Teletext
>
> Regards
> fnu
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  
Olliver Schinagl April 1, 2011, 1:23 p.m. UTC | #13
I actually wrote the patch and posted it on this list, about 4? months
ago. It was maybe 20 lines total? It is a realyl small patch.

And so far, I have not found 99.999% to follow the same coloring
standard at all actually. Personally, I wasn't aware that the order of
buttons was standarized on remotes (I could agree that most teletekst
screens would be identical).

On 04/01/11 12:13, fnu wrote:
>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
> dont have the remote at hand). Lets say the buttons are Button0, Button1,
> Button2, Button3
>
>> My (and perhaps only my) opinion is that vdr should request the leftmost
> color button, then the color right next to it (and so on) while learning.
> The color displayed in the osd should be assigned via the setup menu.
>
> Are you seriously asking for a major change like this, just for your most
> propably unique remote control?
>
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.
>
> http://en.wikipedia.org/wiki/Teletext
>
> Regards
> fnu
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
Olliver Schinagl April 1, 2011, 1:26 p.m. UTC | #14
I have a iMon remote control, which also doesn't use this 'standard'
order ;)

Additionally on my previous mail (I hit send by accident actually :p) I
checked the wikipage, and i couldn't find any mention of color or colour
in relation to the order of the buttons. Also searching for Yellow
didn't result in a single hit, nor did RGYB.

So I'm not so sure of this 'standard order for remotes' yet?

On 04/01/11 14:54, Rainer Blickle wrote:
> Yes i do. But the request can be refused, of course. Why not asking.
>
> I have a hama MCE ir. Dont know how many people use this remote.
>
> 2011/4/1 fnu <vdr@auktion.hostingkunde.de>:
>>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
>> dont have the remote at hand). Lets say the buttons are Button0, Button1,
>> Button2, Button3
>>
>>> My (and perhaps only my) opinion is that vdr should request the leftmost
>> color button, then the color right next to it (and so on) while learning.
>> The color displayed in the osd should be assigned via the setup menu.
>>
>> Are you seriously asking for a major change like this, just for your most
>> propably unique remote control?
>>
>> The color order of the RGYB buttons is a common standard, defined for
>> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
>> have this order.
>>
>> http://en.wikipedia.org/wiki/Teletext
>>
>> Regards
>> fnu
>>
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  
VDRU VDRU April 1, 2011, 4:08 p.m. UTC | #15
On Fri, Apr 1, 2011 at 3:13 AM, fnu <vdr@auktion.hostingkunde.de> wrote:
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.

That's definitely not true.  I have about 8 different remotes and at
least half don't use that button order.  In addition, not every remote
has color buttons 4 in a row.  Plenty of them make a square around
other buttons such as 'ok/enter' for example.
  
fnu April 1, 2011, 9:54 p.m. UTC | #16
vdr-user:
> That's definitely not true.  I have about 8 different remotes and at least half don't use that button order.  In addition, not every remote has color buttons 4 in a row.  Plenty of them make a square around other buttons such as 'ok/enter' for example.

Oliver Schinagl:
> I wasn't aware that the order of buttons was standarized on remotes

===

Well, could be that not all remotes for each pinchy device might provide color keys at all or in this order. But if they are somehow TV oriented, they follow this order in a global manner, even the M$ ones, if they have colored keys.

You want an evidence? Just check out the universal remotes form the big three manufactures, Philips, Logitech & One-for-All, if the devices do offer colored keys, the order is RGYB, nothing left, nothing right, and you should really ask yourself, why?

And, the most important point, global standard or not, it has been defined as standard in VDR a century ago, and this is a fact.

Regards
fnu
  
VDRU VDRU April 2, 2011, 1:23 a.m. UTC | #17
On Fri, Apr 1, 2011 at 2:54 PM, fnu <vdr@auktion.hostingkunde.de> wrote:
> vdr-user:
>> That's definitely not true.  I have about 8 different remotes and at least half don't use that button order.  In addition, not every remote has color buttons 4 in a row.  Plenty of them make a square around other buttons such as 'ok/enter' for example.
>
> Oliver Schinagl:
>> I wasn't aware that the order of buttons was standarized on remotes
>
> ===
>
> Well, could be that not all remotes for each pinchy device might provide color keys at all or in this order. But if they are somehow TV oriented, they follow this order in a global manner, even the M$ ones, if they have colored keys.
>
> You want an evidence? Just check out the universal remotes form the big three manufactures, Philips, Logitech & One-for-All, if the devices do offer colored keys, the order is RGYB, nothing left, nothing right, and you should really ask yourself, why?
>
> And, the most important point, global standard or not, it has been defined as standard in VDR a century ago, and this is a fact.

I'm not sure why you're trying to argue this.  There are users in this
thread (including myself) that already own remote(s) that don't follow
this order.  Assuming they're all for some "pinchy device" is silly.
ALL of my remotes either came with dvb cards or sold as a media remote
-- all of which are 'oriented' for tv among other devices.

Also, you pointing out remote makers that follow the RGYB _scheme_
doesn't void the fact that plenty of remotes exist that don't.  It's
funny you use Logitech as one of your examples considering they make a
mixture of remotes that do and don't follow that button scheme.  That
goes against your claims, not suport them.

Ignoring remotes that don't follow the RGYB scheme doesn't make them
any less 'tv oriented' or go away.  I can't imagine it's much of a
leap to make the colored button position customizable and is probably
something that's better to have then not.  What good argument against
allowing the user to customize the layout according to their actual
remote button layout could there be?  None that I can think of.  I'd
guess Klaus will consider any patches submitted to him which don't
cause problems.  Regardless, users always have the option to patch the
feature in if it doesn't become a part of VDR's core.
  
Rolf Ahrenberg April 2, 2011, 9:33 a.m. UTC | #18
On Fri, 1 Apr 2011, VDR User wrote:

> Ignoring remotes that don't follow the RGYB scheme doesn't make them
> any less 'tv oriented' or go away.  I can't imagine it's much of a
> leap to make the colored button position customizable and is probably
> something that's better to have then not.  What good argument against
> allowing the user to customize the layout according to their actual
> remote button layout could there be?  None that I can think of.  I'd
> guess Klaus will consider any patches submitted to him which don't
> cause problems.  Regardless, users always have the option to patch the
> feature in if it doesn't become a part of VDR's core.

The RGYB color enumeration is defined in the video teletext standard and 
every TV/STB set implementing the teletext feature DOES use the 
mentioned color button order. I guess the teletext is used mainly in 
Europe, so there might be different conventions elsewhere, but the VDR 
is a STB for DVB standard that documents the teletext too.

IMO, you really should switch the OSD button colors in skin plugins 
instead of patching the core VDR. There will be some glitches with 
learning the remotes, but these can be fixed with some extra 
documentation (Press 'Red/leftmost color' button). These remotes with 
"wrong" color button orders are really a small minority here mainly 
targeted to some odd mediacenters or PS3 - at least here in the northern 
Europe.

BR,
--
rofa
  
Klaus Schmidinger April 2, 2011, 10:23 a.m. UTC | #19
On 02.04.2011 11:33, Rolf Ahrenberg wrote:
> On Fri, 1 Apr 2011, VDR User wrote:
>
>> Ignoring remotes that don't follow the RGYB scheme doesn't make them
>> any less 'tv oriented' or go away. I can't imagine it's much of a
>> leap to make the colored button position customizable and is probably
>> something that's better to have then not. What good argument against
>> allowing the user to customize the layout according to their actual
>> remote button layout could there be? None that I can think of. I'd
>> guess Klaus will consider any patches submitted to him which don't
>> cause problems. Regardless, users always have the option to patch the
>> feature in if it doesn't become a part of VDR's core.
>
> The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB
> standard that documents the teletext too.
>
> IMO, you really should switch the OSD button colors in skin plugins instead of patching the core VDR. There will be some glitches with learning the remotes, but these can be fixed with some extra documentation (Press 'Red/leftmost color' button). These remotes with "wrong" color button orders are
> really a small minority here mainly targeted to some odd mediacenters or PS3 - at least here in the northern Europe.

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. I haven't looked into the original
patch yet, so I can't say whether it only handles the
display sequence or also messes with the functionality.
At any rate, a patch that changes the functionality is
unacceptable for me.

Klaus
  
fnu April 2, 2011, 11:40 a.m. UTC | #20
> Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core.

Here we go! Provide a patch, users can use or not w/o assuming to change vdr-core.

Like the majority of users, I do use remotes following kls's VDR standard defined a century ago. I don't want to bothered w/ configurable colored keys, it can be just another cause for malfunctions, mere you guys are not willing to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high expectation, because you also buy DVB devices which are compatible w/ VDR ...

If remotes would be some very expensive devices, I may follow your arguments, but you guys do often buy the cheapest you can get and expect that core VDR will changed to be usable with these sometimes pulpy devices, wereas also compatible devices are available for the same price ...

Regards
fnu
  
Udo Richter April 2, 2011, 12:53 p.m. UTC | #21
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. ;)
  
Tony Houghton April 2, 2011, 2:05 p.m. UTC | #22
On Sat, 2 Apr 2011 12:33:58 +0300 (EEST)
Rolf Ahrenberg <rahrenbe@cc.hut.fi> wrote:

> The RGYB color enumeration is defined in the video teletext standard and 
> every TV/STB set implementing the teletext feature DOES use the 
> mentioned color button order. I guess the teletext is used mainly in 
> Europe, so there might be different conventions elsewhere, but the VDR 
> is a STB for DVB standard that documents the teletext too.
> 
> IMO, you really should switch the OSD button colors in skin plugins 
> instead of patching the core VDR. There will be some glitches with 
> learning the remotes, but these can be fixed with some extra 
> documentation (Press 'Red/leftmost color' button). These remotes with 
> "wrong" color button orders are really a small minority here mainly 
> targeted to some odd mediacenters or PS3 - at least here in the northern 
> Europe.

It isn't true that only very obscure and trashy remotes have the buttons
in the wrong order. I've got a Sony TV where the colours are arranged in
a sort of cross layout with green above blue and red and yellow at the
sides. It's a good quality remote that I think was used with a number of
different models of Sony TV set and it was definitely designed to
support teletext.

I've got another remote with the wrong order which came with a KWorld
DVB card bought from Maplins, a major high street electronics chain.
That remote isn't really usable with VDR anyway though, because the
colours are also play, pause, stop and record. I suppose they didn't
think that people would use teletext or MHEG while watching a recording,
and there is no standard for the way that VDR uses the colours. I can't
use the remote that came with my other card (Hauppauge) because the
current kernel/DVB drivers aren't compatible with it (for at least the
2nd time in hstory). So I'm making do with a wireless keyboard until
that's fixed.
  
VDRU VDRU April 2, 2011, 8:36 p.m. UTC | #23
On Sat, Apr 2, 2011 at 4:40 AM, fnu <vdr@auktion.hostingkunde.de> wrote:
>> Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core.
>
> Here we go! Provide a patch, users can use or not w/o assuming to change vdr-core.
>
> Like the majority of users, I do use remotes following kls's VDR standard defined a century ago. I don't want to bothered w/ configurable colored keys, it can be just another cause for malfunctions, mere you guys are not willing to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high expectation, because you also buy DVB devices which are compatible w/ VDR ...
>
> If remotes would be some very expensive devices, I may follow your arguments, but you guys do often buy the cheapest you can get and expect that core VDR will changed to be usable with these sometimes pulpy devices, wereas also compatible devices are available for the same price ...

You aren't doing yourself any favors by making all these silly
assumptions.  I mean this in the nicest way possible -- everything
quoted above is complete nonsense.  Nobody is ever giong to take you
seriously if you keep posting such rubbish.
  
VDRU VDRU April 2, 2011, 8:42 p.m. UTC | #24
On Sat, Apr 2, 2011 at 2:33 AM, Rolf Ahrenberg <rahrenbe@cc.hut.fi> wrote:
> The RGYB color enumeration is defined in the video teletext standard and
> every TV/STB set implementing the teletext feature DOES use the mentioned
> color button order. I guess the teletext is used mainly in Europe, so there
> might be different conventions elsewhere, but the VDR is a STB for DVB
> standard that documents the teletext too.

I have two top end tv's, one Panasonic, one Sony.  Both support
teletext, neither have the color button scheme as RGYB.  I would guess
it's as you mentioned, maybe that scheme is commonly used in Europe
but it's simply not true that RGYB is some standard used across the
globe with only cheap obscure remotes not conforming to it.
  
Klaus Schmidinger April 3, 2011, 10:37 a.m. UTC | #25
On 31.03.2011 15:40, Rainer Blickle wrote:
> 2011/3/30 Steffen Barszus<steffenbpunkt@googlemail.com>:
>> 2011/3/30 Oliver Schinagl<oliver@schinagl.nl>:
>>> I belive that is exactly only what this patch does, it changes the
>>> positions on the screen for the ST-NG theme I think (it's been a while I
>>> admit).
>>>
>>> So if VDR is told that the red button performs the job of the red
>>> button, then everything is ok.
>>>
>>> To recap, the problem I had with VDR that caused me to write this patch,
>>> was:
>>>
>>> My Remote control had 2 buttons different from where VDR expected the
>>> buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
>>> control was Red Yellow Blue Green.
>
> My remote has the color order Yellow, Red, Blue, Green (only an
> example, i dont have the remote at hand). Lets say the buttons are
> Button0, Button1, Button2, Button3
>
> When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed.
>
> In the vdr layout Button0 is Red, Button1 is Yellow and so on ...
> while watching a recording vdr jumps 1 minute in the past when
> pressing yellow and one minute in the future when pressing green.
> These are the "middle" color buttons.
>
> I also wanted to have this functionality in the "middle" buttons (on
> the buttons 1 and 2).
>
> So i pressed the Buttons Yellow, Red, Blue, Green while learning
> Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute
> functionality still on the middle color buttons.
>
> The only thing left is that the color on the osd has to be adjusted,
> but not the positions of the text on it. If have dont this by
> modifying your patch (the texts for ->DrawText are taken directly from
> the parameters, not from the mapping).
>
> My (and perhaps only my) opinion is that vdr should request the
> leftmost color button, then the color right next to it (and so on)
> while learning. The color displayed in the osd should be assigned via
> the setup menu.
>
> @Klaus: If there is a change to integrate this into the vdr, i would
> provide a patch for it.

I assume you meant a "chance" ;-)

Well, as stated earlier, i'd be willing to accept a patch that
rearranges the sequence of the color buttons on the OSD, to make them
match the sequence on the remote control. What I don't like is to
mess with the actual functionality of the color buttons, because that
would cause a "babylonification". If somebody asks "how do I do this
or that", the answer could no longer be "press the green button", but
would rather have to be "press the second button from the left in the
row of color buttons, provided they are arranged in a row at all" ;-)
It would also have a major impact on all sorts of documentation, and
all source code that currently uses kRed, kGreen, kYellow and kBlue
would have to be modified.

Klaus
  
Klaus Schmidinger April 3, 2011, 10:55 a.m. UTC | #26
On 01.04.2011 15:26, Oliver Schinagl wrote:
> I have a iMon remote control, which also doesn't use this 'standard'
> order ;)
>
> Additionally on my previous mail (I hit send by accident actually :p) I
> checked the wikipage, and i couldn't find any mention of color or colour
> in relation to the order of the buttons. Also searching for Yellow
> didn't result in a single hit, nor did RGYB.

I guess he was referring to the screen shots on that page:

   http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_lebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg
   http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK%29.jpg/250px-  Digital_teletext_%28NRK%29.jpg

Klaus

> So I'm not so sure of this 'standard order for remotes' yet?
>
> On 04/01/11 14:54, Rainer Blickle wrote:
>> Yes i do. But the request can be refused, of course. Why not asking.
>>
>> I have a hama MCE ir. Dont know how many people use this remote.
>>
>> 2011/4/1 fnu<vdr@auktion.hostingkunde.de>:
>>>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
>>> dont have the remote at hand). Lets say the buttons are Button0, Button1,
>>> Button2, Button3
>>>
>>>> My (and perhaps only my) opinion is that vdr should request the leftmost
>>> color button, then the color right next to it (and so on) while learning.
>>> The color displayed in the osd should be assigned via the setup menu.
>>>
>>> Are you seriously asking for a major change like this, just for your most
>>> propably unique remote control?
>>>
>>> The color order of the RGYB buttons is a common standard, defined for
>>> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
>>> have this order.
>>>
>>> http://en.wikipedia.org/wiki/Teletext
>>>
>>> Regards
>>> fnu
  
fnu April 3, 2011, 2:56 p.m. UTC | #27
Well, not only the German one's, there was also a Screenshot from Norway, I
guess a kind of advanced teletext:

http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg

Regards
fnu

-----Ursprüngliche Nachricht-----
Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Sonntag, 3. April 2011 12:55
An: vdr@linuxtv.org
Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable

On 01.04.2011 15:26, Oliver Schinagl wrote:
> I have a iMon remote control, which also doesn't use this 'standard'
> order ;)
>
> Additionally on my previous mail (I hit send by accident actually :p) 
> I checked the wikipage, and i couldn't find any mention of color or 
> colour in relation to the order of the buttons. Also searching for 
> Yellow didn't result in a single hit, nor did RGYB.

I guess he was referring to the screen shots on that page:

 
http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l
ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg
 
http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK%
29.jpg/250px-  Digital_teletext_%28NRK%29.jpg

Klaus
  
fnu April 4, 2011, 9:34 a.m. UTC | #28
Hi there,

to finish discussion if RGYB ist a standard or not or where does it come
from:

- http://www.topteletext.com/en.asp
- http://www.topteletext.com/working/

Regards
fnu

-----Ursprüngliche Nachricht-----
Von: fnu [mailto:vdr@auktion.hostingkunde.de] 
Gesendet: Sonntag, 3. April 2011 16:57
An: 'VDR Mailing List'
Betreff: AW: [vdr] [Patch] Make RGYB buttons customizeable

Well, not only the German one's, there was also a Screenshot from Norway, I
guess a kind of advanced teletext:

http://upload.wikimedia.org/wikipedia/en/d/d0/Digital_teletext_%28NRK%29.jpg

Regards
fnu

-----Ursprüngliche Nachricht-----
Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von
Klaus Schmidinger
Gesendet: Sonntag, 3. April 2011 12:55
An: vdr@linuxtv.org
Betreff: Re: [vdr] [Patch] Make RGYB buttons customizeable

On 01.04.2011 15:26, Oliver Schinagl wrote:
> I have a iMon remote control, which also doesn't use this 'standard'
> order ;)
>
> Additionally on my previous mail (I hit send by accident actually :p) 
> I checked the wikipage, and i couldn't find any mention of color or 
> colour in relation to the order of the buttons. Also searching for 
> Yellow didn't result in a single hit, nor did RGYB.

I guess he was referring to the screen shots on that page:

 
http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Teletext_level1_0_l
ebel2_5.jpg/500px-Teletext_level1_0_lebel2_5.jpg
 
http://upload.wikimedia.org/wikipedia/en/thumb/d/d0/Digital_teletext_%28NRK%
29.jpg/250px-  Digital_teletext_%28NRK%29.jpg

Klaus
  
VDRU VDRU April 4, 2011, 2:47 p.m. UTC | #29
On Mon, Apr 4, 2011 at 2:34 AM, fnu <vdr@auktion.hostingkunde.de> wrote:
> Hi there,
>
> to finish discussion if RGYB ist a standard or not or where does it come
> from:

Your theory that the RGYB color scheme is a worldwide standard with
only cheap obscure non-media remotes being 'non-compliant' has already
been thrown out the window.  I don't know why you think pasting a link
to an Italian website can somehow resurrect the dead theory.  Btw, no
link you ever paste will outweigh what color scheme people see on
their physical remotes.  If you want to argue about it further then
contact Panasonic, Sony, and your friends at Logitech to start with.
  
fnu April 4, 2011, 10:33 p.m. UTC | #30
===
Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window.  I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory.  Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes.  If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with.
===

Well, that's a claim.

It's not just any italian URL, this is the main page of the inventor and license holder for "TOP Teletext". This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue).

Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ...

Regards
fnu
  
VDRU VDRU April 4, 2011, 10:46 p.m. UTC | #31
On Mon, Apr 4, 2011 at 3:33 PM, fnu <vdr@auktion.hostingkunde.de> wrote:
> ===
> Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window.  I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory.  Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes.  If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with.
> ===
>
> Well, that's a claim.
>
> It's not just any italian URL, this is the main page of the inventor and license holder for "TOP Teletext". This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue).
>
> Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ...

...shakes head...  Please refer to my previous post, then let's not
continue this foolishness on the VDR ml ok?  Ok.
  
Olliver Schinagl April 7, 2011, 3:48 p.m. UTC | #32
Not wanting to throw any oil on this fire, or make things worse, I still
don't see any mention of an order for these keys. Not even all colors
are defined. A quote from the site you linked:

other keys marked in various colours (e.g.: red, green, yellow, blue)

Various colors, meaning there's no limit to the amount of colors. E.g.
meaning, for example red, green, yellow and blue. It doesn't state 'only
red green yellow and blue, in this order' Actually, the whole point of
TOP teletekst using colors and not order was that order did not matter.
Hence even big name manufactures of big name remotes (Logitech, Sony as
mentioned here, my iMon that came with my silverstone case as menitoned
by me, and it even has purple as mentioned by someone else which also
falls under the category 'various colours') don't always use this
specific order and layout.

Anyway, I wrote a simple patch to solve this issue 4 months ago, and was
simple asking for a review. So I'll simply re-send that mail and we can
all move on and get a long :)


On 04/05/11 00:33, fnu wrote:
> ===
> Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window.  I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory.  Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes.  If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with.
> ===
>
> Well, that's a claim.
>
> It's not just any italian URL, this is the main page of the inventor and license holder for "TOP Teletext". This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue).
>
> Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ...
>
> Regards
> fnu
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

Patch

diff -ru config.c.orig config.c
--- config.c.orig	2010-09-16 03:34:59.000000000 +0200
+++ config.c	2010-09-16 03:35:36.000000000 +0200
@@ -218,6 +218,10 @@ 
   strcpy(OSDLanguage, ""); // default is taken from environment
   strcpy(OSDSkin, "sttng");
   strcpy(OSDTheme, "default");
+  Button0 = 0;
+  Button1 = 1;
+  Button2 = 2;
+  Button3 = 3;
   PrimaryDVB = 1;
   ShowInfoOnChSwitch = 1;
   TimeoutRequChInfo = 1;
@@ -417,6 +421,10 @@ 
   if      (!strcasecmp(Name, "OSDLanguage"))       { strn0cpy(OSDLanguage, Value, sizeof(OSDLanguage)); I18nSetLocale(OSDLanguage); }
   else if (!strcasecmp(Name, "OSDSkin"))             Utf8Strn0Cpy(OSDSkin, Value, MaxSkinName);
   else if (!strcasecmp(Name, "OSDTheme"))            Utf8Strn0Cpy(OSDTheme, Value, MaxThemeName);
+  else if (!strcasecmp(Name, "Button0"))             Button0            = atoi(Value);
+  else if (!strcasecmp(Name, "Button1"))             Button1            = atoi(Value);
+  else if (!strcasecmp(Name, "Button2"))             Button2            = atoi(Value);
+  else if (!strcasecmp(Name, "Button3"))             Button3            = atoi(Value);
   else if (!strcasecmp(Name, "PrimaryDVB"))          PrimaryDVB         = atoi(Value);
   else if (!strcasecmp(Name, "ShowInfoOnChSwitch"))  ShowInfoOnChSwitch = atoi(Value);
   else if (!strcasecmp(Name, "TimeoutRequChInfo"))   TimeoutRequChInfo  = atoi(Value);
@@ -524,6 +532,10 @@ 
   Store("OSDLanguage",        OSDLanguage);
   Store("OSDSkin",            OSDSkin);
   Store("OSDTheme",           OSDTheme);
+  Store("Button0",            Button0);
+  Store("Button1",            Button1);
+  Store("Button2",            Button2);
+  Store("Button3",            Button3);
   Store("PrimaryDVB",         PrimaryDVB);
   Store("ShowInfoOnChSwitch", ShowInfoOnChSwitch);
   Store("TimeoutRequChInfo",  TimeoutRequChInfo);
diff -ru config.h.orig config.h > ~/Desktop/config.h.diff
--- config.h.orig	2010-09-16 03:34:39.000000000 +0200
+++ config.h	2010-09-16 03:35:38.000000000 +0200
@@ -219,6 +219,10 @@ 
   char OSDLanguage[I18N_MAX_LOCALE_LEN];
   char OSDSkin[MaxSkinName];
   char OSDTheme[MaxThemeName];
+  int Button0;
+  int Button1;
+  int Button2;
+  int Button3;
   int PrimaryDVB;
   int ShowInfoOnChSwitch;
   int TimeoutRequChInfo;
diff -ru menu.c.orig menu.c
--- menu.c.orig	2010-09-16 03:34:44.000000000 +0200
+++ menu.c	2010-09-16 03:35:36.000000000 +0200
@@ -2422,6 +2422,7 @@ 
   const char *useSmallFontTexts[3];
   const char *mainMenuTitle[MAXMAINMENUTITLE];
   int osdLanguageIndex;
+  const char *buttonColorTexts[4];
   int numSkins;
   int originalSkinIndex;
   int skinIndex;
@@ -2475,12 +2476,20 @@ 
   mainMenuTitle[1]=tr("VDR - text");
   mainMenuTitle[2]=tr("text");
   mainMenuTitle[3]=tr("VDR - version");
+  buttonColorTexts[0]=tr("Key$Red");
+  buttonColorTexts[1]=tr("Key$Green");
+  buttonColorTexts[2]=tr("Key$Yellow");
+  buttonColorTexts[3]=tr("Key$Blue");
   Clear();
   SetSection(tr("OSD"));
   Add(new cMenuEditStraItem(tr("Setup.OSD$Language"),               &osdLanguageIndex, I18nNumLanguagesWithLocale(), &I18nLanguages()->At(0)));
   Add(new cMenuEditStraItem(tr("Setup.OSD$Skin"),                   &skinIndex, numSkins, skinDescriptions));
   if (themes.NumThemes())
   Add(new cMenuEditStraItem(tr("Setup.OSD$Theme"),                  &themeIndex, themes.NumThemes(), themes.Descriptions()));
+  Add(new cMenuEditStraItem(tr("Setup.OSD$Button0"),                &data.Button0, 4, buttonColorTexts));
+  Add(new cMenuEditStraItem(tr("Setup.OSD$Button1"),                &data.Button1, 4, buttonColorTexts));
+  Add(new cMenuEditStraItem(tr("Setup.OSD$Button2"),                &data.Button2, 4, buttonColorTexts));
+  Add(new cMenuEditStraItem(tr("Setup.OSD$Button3"),                &data.Button3, 4, buttonColorTexts));
   Add(new cMenuEditIntItem( tr("Setup.OSD$Left"),                   &data.OSDLeft, 0, MAXOSDWIDTH));
   Add(new cMenuEditIntItem( tr("Setup.OSD$Top"),                    &data.OSDTop, 0, MAXOSDHEIGHT));
   Add(new cMenuEditIntItem( tr("Setup.OSD$Width"),                  &data.OSDWidth, MINOSDWIDTH, MAXOSDWIDTH));
diff -ru skinclassic.c.orig skinclassic.c
--- skinclassic.c.orig	2010-09-16 03:35:21.000000000 +0200
+++ skinclassic.c	2010-09-16 03:35:36.000000000 +0200
@@ -277,16 +277,19 @@ 
 void cSkinClassicDisplayMenu::SetButtons(const char *Red, const char *Green, const char *Yellow, const char *Blue)
 {
   const cFont *font = cFont::GetFont(fontOsd);
+  const char *lutKeys[] = {Red, Green, Yellow, Blue};
+  tColor lutFg[4] = {clrButtonRedFg, clrButtonGreenFg, clrButtonYellowFg, clrButtonBlueFg};
+  tColor lutBg[4] = {clrButtonRedBg, clrButtonGreenBg, clrButtonYellowBg, clrButtonBlueBg};
   int w = x3 - x0;
   int t0 = x0;
   int t1 = x0 + w / 4;
   int t2 = x0 + w / 2;
   int t3 = x3 - w / 4;
   int t4 = x3;
-  osd->DrawText(t0, y4, Red,    Theme.Color(clrButtonRedFg),    Red    ? Theme.Color(clrButtonRedBg)    : Theme.Color(clrBackground), font, t1 - t0, 0, taCenter);
-  osd->DrawText(t1, y4, Green,  Theme.Color(clrButtonGreenFg),  Green  ? Theme.Color(clrButtonGreenBg)  : Theme.Color(clrBackground), font, t2 - t1, 0, taCenter);
-  osd->DrawText(t2, y4, Yellow, Theme.Color(clrButtonYellowFg), Yellow ? Theme.Color(clrButtonYellowBg) : Theme.Color(clrBackground), font, t3 - t2, 0, taCenter);
-  osd->DrawText(t3, y4, Blue,   Theme.Color(clrButtonBlueFg),   Blue   ? Theme.Color(clrButtonBlueBg)   : Theme.Color(clrBackground), font, t4 - t3, 0, taCenter);
+  osd->DrawText(t0, y4, lutKeys[Setup.Button0], Theme.Color(lutFg[Setup.Button0]), lutKeys[Setup.Button0] ? Theme.Color(lutBg[Setup.Button0]) : Theme.Color(lutBg[Setup.Button0]), font, t1 - t0, 0, taCenter);
+  osd->DrawText(t1, y4, lutKeys[Setup.Button1], Theme.Color(lutFg[Setup.Button1]), lutKeys[Setup.Button1] ? Theme.Color(lutBg[Setup.Button1]) : Theme.Color(lutBg[Setup.Button1]), font, t2 - t1, 0, taCenter);
+  osd->DrawText(t2, y4, lutKeys[Setup.Button2], Theme.Color(lutFg[Setup.Button2]), lutKeys[Setup.Button2] ? Theme.Color(lutBg[Setup.Button2]) : Theme.Color(lutBg[Setup.Button2]), font, t3 - t2, 0, taCenter);
+  osd->DrawText(t3, y4, lutKeys[Setup.Button3], Theme.Color(lutFg[Setup.Button3]), lutKeys[Setup.Button3] ? Theme.Color(lutBg[Setup.Button3]) : Theme.Color(lutBg[Setup.Button3]), font, t4 - t3, 0, taCenter);
 }
 
 void cSkinClassicDisplayMenu::SetMessage(eMessageType Type, const char *Text)
diff -ru skinsttng.c.orig skinsttng.c
--- skinsttng.c.orig	2010-09-16 03:35:23.000000000 +0200
+++ skinsttng.c	2010-09-16 03:35:36.000000000 +0200
@@ -499,6 +499,9 @@ 
 
 void cSkinSTTNGDisplayMenu::SetButtons(const char *Red, const char *Green, const char *Yellow, const char *Blue)
 {
+  const char *lutKeys[] = {Red, Green, Yellow, Blue};
+  tColor lutFg[4] = {clrButtonRedFg, clrButtonGreenFg, clrButtonYellowFg, clrButtonBlueFg};
+  tColor lutBg[4] = {clrButtonRedBg, clrButtonGreenBg, clrButtonYellowBg, clrButtonBlueBg};
   cString date = DayDateTime();
   const cFont *font = cFont::GetFont(fontSml);
   int d = 10;
@@ -513,10 +516,10 @@ 
   osd->DrawRectangle(t1 + d2, y6, t2 - d2, y7 - 1, clrBlack);
   osd->DrawRectangle(t2 + d2, y6, t3 - d2, y7 - 1, clrBlack);
   osd->DrawRectangle(t3 + d2, y6, t4 - d2, y7 - 1, clrBlack);
-  osd->DrawText(t0 + d, y6, Red,    Theme.Color(clrButtonRedFg),    Theme.Color(clrButtonRedBg),    font, t1 - t0 - 2 * d, 0, taCenter);
-  osd->DrawText(t1 + d, y6, Green,  Theme.Color(clrButtonGreenFg),  Theme.Color(clrButtonGreenBg),  font, t2 - t1 - 2 * d, 0, taCenter);
-  osd->DrawText(t2 + d, y6, Yellow, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font, t3 - t2 - 2 * d, 0, taCenter);
-  osd->DrawText(t3 + d, y6, Blue,   Theme.Color(clrButtonBlueFg),   Theme.Color(clrButtonBlueBg),   font, t4 - t3 - 2 * d, 0, taCenter);
+  osd->DrawText(t0 + d, y6, lutKeys[Setup.Button0], Theme.Color(lutFg[Setup.Button0]), Theme.Color(lutBg[Setup.Button0]), font, t1 - t0 - 2 * d, 0, taCenter);
+  osd->DrawText(t1 + d, y6, lutKeys[Setup.Button1], Theme.Color(lutFg[Setup.Button1]), Theme.Color(lutBg[Setup.Button1]), font, t2 - t1 - 2 * d, 0, taCenter);
+  osd->DrawText(t2 + d, y6, lutKeys[Setup.Button2], Theme.Color(lutFg[Setup.Button2]), Theme.Color(lutBg[Setup.Button2]), font, t3 - t2 - 2 * d, 0, taCenter);
+  osd->DrawText(t3 + d, y6, lutKeys[Setup.Button3], Theme.Color(lutFg[Setup.Button3]), Theme.Color(lutBg[Setup.Button3]), font, t4 - t3 - 2 * d, 0, taCenter);
 }
 
 void cSkinSTTNGDisplayMenu::SetMessage(eMessageType Type, const char *Text)