From: Oliver Schinagl oliver@schinagl.nl
I've noticed a nasty typo in menu.c where all 4 buttons would be displayed as Button0. So a cosmetic issue only! Since there where no comments on my previous e-mails have not been answerd yet, so sending it as a whole patch again instead of a simple patch upon patch ;)
VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort.
config.*: Load/Save Button information menu.c : Add button selection to the UI skin*.c : Use button order from the config file
Signed-off-by: Oliver Schinagl oliver@schinagl.nl --- config.c | 12 ++++++++++++ config.h | 4 ++++ menu.c | 9 +++++++++ skinclassic.c | 11 +++++++---- skinlcars.c | 19 +++++++++++-------- skinsttng.c | 11 +++++++---- 6 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c index 56454df..165bcee 100644 --- a/config.c +++ b/config.c @@ -424,6 +424,10 @@ cSetup::cSetup(void) UseDolbyDigital = 1; ChannelInfoPos = 0; ChannelInfoTime = 5; + Button0 = 0; + Button1 = 1; + Button2 = 2; + Button3 = 3; OSDLeftP = 0.03; OSDTopP = 0.03; OSDWidthP = 0.93; @@ -620,6 +624,10 @@ bool cSetup::Parse(const char *Name, const char *Value) else if (!strcasecmp(Name, "UseDolbyDigital")) UseDolbyDigital = atoi(Value); else if (!strcasecmp(Name, "ChannelInfoPos")) ChannelInfoPos = atoi(Value); else if (!strcasecmp(Name, "ChannelInfoTime")) ChannelInfoTime = atoi(Value); + 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, "OSDLeftP")) OSDLeftP = atof(Value); else if (!strcasecmp(Name, "OSDTopP")) OSDTopP = atof(Value); else if (!strcasecmp(Name, "OSDWidthP")) { OSDWidthP = atof(Value); ChkDoublePlausibility(OSDWidthP, 0.87); } @@ -719,6 +727,10 @@ bool cSetup::Save(void) Store("UseDolbyDigital", UseDolbyDigital); Store("ChannelInfoPos", ChannelInfoPos); Store("ChannelInfoTime", ChannelInfoTime); + Store("Button0", Button0); + Store("Button1", Button1); + Store("Button2", Button2); + Store("Button3", Button3); Store("OSDLeftP", OSDLeftP); Store("OSDTopP", OSDTopP); Store("OSDWidthP", OSDWidthP); diff --git a/config.h b/config.h index acdf77a..3dd86ae 100644 --- a/config.h +++ b/config.h @@ -294,6 +294,10 @@ public: int UseDolbyDigital; int ChannelInfoPos; int ChannelInfoTime; + int Button0; + int Button1; + int Button2; + int Button3; double OSDLeftP, OSDTopP, OSDWidthP, OSDHeightP; int OSDLeft, OSDTop, OSDWidth, OSDHeight; double OSDAspect; diff --git a/menu.c b/menu.c index 9f4c54e..bea03b1 100644 --- a/menu.c +++ b/menu.c @@ -2510,6 +2510,7 @@ void cMenuSetupBase::Store(void) class cMenuSetupOSD : public cMenuSetupBase { private: const char *useSmallFontTexts[3]; + const char *buttonColorTexts[4]; int osdLanguageIndex; int numSkins; int originalSkinIndex; @@ -2560,12 +2561,20 @@ void cMenuSetupOSD::Set(void) useSmallFontTexts[0] = tr("never"); useSmallFontTexts[1] = tr("skin dependent"); useSmallFontTexts[2] = tr("always"); + 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 cMenuEditPrcItem( tr("Setup.OSD$Left (%)"), &data.OSDLeftP, 0.0, 0.5)); Add(new cMenuEditPrcItem( tr("Setup.OSD$Top (%)"), &data.OSDTopP, 0.0, 0.5)); Add(new cMenuEditPrcItem( tr("Setup.OSD$Width (%)"), &data.OSDWidthP, 0.5, 1.0)); diff --git a/skinclassic.c b/skinclassic.c index 64944de..2693036 100644 --- a/skinclassic.c +++ b/skinclassic.c @@ -291,16 +291,19 @@ void cSkinClassicDisplayMenu::SetTitle(const char *Title) 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 --git a/skinlcars.c b/skinlcars.c index 5937efe..f58b90b 100644 --- a/skinlcars.c +++ b/skinlcars.c @@ -1458,19 +1458,22 @@ void cSkinLCARSDisplayMenu::SetTitle(const char *Title)
void cSkinLCARSDisplayMenu::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}; const cFont *font = cFont::GetFont(fontSml); if (MenuCategory() == mcMain) { - DrawMainButton(Red, xd00, xd01, xd02, xd03, yd02, yd03, Theme.Color(clrButtonRedFg), Theme.Color(clrButtonRedBg), font); - DrawMainButton(Green, xd04, xd05, xd06, xd07, yd02, yd03, Theme.Color(clrButtonGreenFg), Theme.Color(clrButtonGreenBg), font); - DrawMainButton(Yellow, xd00, xd01, xd02, xd03, yd04, yd05, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font); - DrawMainButton(Blue, xd04, xd05, xd06, xd07, yd04, yd05, Theme.Color(clrButtonBlueFg), Theme.Color(clrButtonBlueBg), font); + DrawMainButton(lutKeys[Setup.Button0], xd00, xd01, xd02, xd03, yd02, yd03, Theme.Color(lutFg[Setup.Button0]), Theme.Color(lutBg[Setup.Button0]), font); + DrawMainButton(lutKeys[Setup.Button1], xd04, xd05, xd06, xd07, yd02, yd03, Theme.Color(lutFg[Setup.Button1]), Theme.Color(lutBg[Setup.Button1]), font); + DrawMainButton(lutKeys[Setup.Button2], xd00, xd01, xd02, xd03, yd04, yd05, Theme.Color(lutFg[Setup.Button2]), Theme.Color(lutBg[Setup.Button2]), font); + DrawMainButton(lutKeys[Setup.Button3], xd04, xd05, xd06, xd07, yd04, yd05, Theme.Color(lutFg[Setup.Button3]), Theme.Color(lutBg[Setup.Button3]), font); } else { int h = yb15 - yb14; - osd->DrawText(xb02, yb14, Red, Theme.Color(clrButtonRedFg), Theme.Color(clrButtonRedBg), font, xb03 - xb02, h, taLeft | taBorder); - osd->DrawText(xb06, yb14, Green, Theme.Color(clrButtonGreenFg), Theme.Color(clrButtonGreenBg), font, xb07 - xb06, h, taLeft | taBorder); - osd->DrawText(xb10, yb14, Yellow, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font, xb11 - xb10, h, taLeft | taBorder); - osd->DrawText(xb14, yb14, Blue, Theme.Color(clrButtonBlueFg), Theme.Color(clrButtonBlueBg), font, xb15 - xb14, h, taLeft | taBorder); + osd->DrawText(xb02, yb14, lutKeys[Setup.Button0], Theme.Color(lutFg[Setup.Button0]), Theme.Color(lutBg[Setup.Button0]), font, xb03 - xb02, h, taLeft | taBorder); + osd->DrawText(xb06, yb14, lutKeys[Setup.Button1], Theme.Color(lutFg[Setup.Button1]), Theme.Color(lutBg[Setup.Button1]), font, xb07 - xb06, h, taLeft | taBorder); + osd->DrawText(xb10, yb14, lutKeys[Setup.Button2], Theme.Color(lutFg[Setup.Button2]), Theme.Color(lutBg[Setup.Button2]), font, xb11 - xb10, h, taLeft | taBorder); + osd->DrawText(xb14, yb14, lutKeys[Setup.Button3], Theme.Color(lutFg[Setup.Button3]), Theme.Color(lutBg[Setup.Button3]), font, xb15 - xb14, h, taLeft | taBorder); } }
diff --git a/skinsttng.c b/skinsttng.c index d985538..49c94d4 100644 --- a/skinsttng.c +++ b/skinsttng.c @@ -571,6 +571,9 @@ void cSkinSTTNGDisplayMenu::SetTitle(const char *Title)
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 = 2 * Gap; @@ -585,10 +588,10 @@ void cSkinSTTNGDisplayMenu::SetButtons(const char *Red, const char *Green, const 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)
Patch reminder, in case it was missed the first time around :)
On 07/23/12 11:21, oliver+list@schinagl.nl wrote:
From: Oliver Schinagloliver@schinagl.nl
I've noticed a nasty typo in menu.c where all 4 buttons would be displayed as Button0. So a cosmetic issue only! Since there where no comments on my previous e-mails have not been answerd yet, so sending it as a whole patch again instead of a simple patch upon patch ;)
VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort.
config.*: Load/Save Button information menu.c : Add button selection to the UI skin*.c : Use button order from the config file
Signed-off-by: Oliver Schinagloliver@schinagl.nl
config.c | 12 ++++++++++++ config.h | 4 ++++ menu.c | 9 +++++++++ skinclassic.c | 11 +++++++---- skinlcars.c | 19 +++++++++++-------- skinsttng.c | 11 +++++++---- 6 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/config.c b/config.c index 56454df..165bcee 100644 --- a/config.c +++ b/config.c @@ -424,6 +424,10 @@ cSetup::cSetup(void) UseDolbyDigital = 1; ChannelInfoPos = 0; ChannelInfoTime = 5;
- Button0 = 0;
- Button1 = 1;
- Button2 = 2;
- Button3 = 3; OSDLeftP = 0.03; OSDTopP = 0.03; OSDWidthP = 0.93;
@@ -620,6 +624,10 @@ bool cSetup::Parse(const char *Name, const char *Value) else if (!strcasecmp(Name, "UseDolbyDigital")) UseDolbyDigital = atoi(Value); else if (!strcasecmp(Name, "ChannelInfoPos")) ChannelInfoPos = atoi(Value); else if (!strcasecmp(Name, "ChannelInfoTime")) ChannelInfoTime = atoi(Value);
- 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, "OSDLeftP")) OSDLeftP = atof(Value); else if (!strcasecmp(Name, "OSDTopP")) OSDTopP = atof(Value); else if (!strcasecmp(Name, "OSDWidthP")) { OSDWidthP = atof(Value); ChkDoublePlausibility(OSDWidthP, 0.87); }
@@ -719,6 +727,10 @@ bool cSetup::Save(void) Store("UseDolbyDigital", UseDolbyDigital); Store("ChannelInfoPos", ChannelInfoPos); Store("ChannelInfoTime", ChannelInfoTime);
- Store("Button0", Button0);
- Store("Button1", Button1);
- Store("Button2", Button2);
- Store("Button3", Button3); Store("OSDLeftP", OSDLeftP); Store("OSDTopP", OSDTopP); Store("OSDWidthP", OSDWidthP);
diff --git a/config.h b/config.h index acdf77a..3dd86ae 100644 --- a/config.h +++ b/config.h @@ -294,6 +294,10 @@ public: int UseDolbyDigital; int ChannelInfoPos; int ChannelInfoTime;
- int Button0;
- int Button1;
- int Button2;
- int Button3; double OSDLeftP, OSDTopP, OSDWidthP, OSDHeightP; int OSDLeft, OSDTop, OSDWidth, OSDHeight; double OSDAspect;
diff --git a/menu.c b/menu.c index 9f4c54e..bea03b1 100644 --- a/menu.c +++ b/menu.c @@ -2510,6 +2510,7 @@ void cMenuSetupBase::Store(void) class cMenuSetupOSD : public cMenuSetupBase { private: const char *useSmallFontTexts[3];
- const char *buttonColorTexts[4]; int osdLanguageIndex; int numSkins; int originalSkinIndex;
@@ -2560,12 +2561,20 @@ void cMenuSetupOSD::Set(void) useSmallFontTexts[0] = tr("never"); useSmallFontTexts[1] = tr("skin dependent"); useSmallFontTexts[2] = tr("always");
- 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 cMenuEditPrcItem( tr("Setup.OSD$Left (%)"),&data.OSDLeftP, 0.0, 0.5)); Add(new cMenuEditPrcItem( tr("Setup.OSD$Top (%)"),&data.OSDTopP, 0.0, 0.5)); Add(new cMenuEditPrcItem( tr("Setup.OSD$Width (%)"),&data.OSDWidthP, 0.5, 1.0));
diff --git a/skinclassic.c b/skinclassic.c index 64944de..2693036 100644 --- a/skinclassic.c +++ b/skinclassic.c @@ -291,16 +291,19 @@ void cSkinClassicDisplayMenu::SetTitle(const char *Title) 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 --git a/skinlcars.c b/skinlcars.c index 5937efe..f58b90b 100644 --- a/skinlcars.c +++ b/skinlcars.c @@ -1458,19 +1458,22 @@ void cSkinLCARSDisplayMenu::SetTitle(const char *Title)
void cSkinLCARSDisplayMenu::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}; const cFont *font = cFont::GetFont(fontSml); if (MenuCategory() == mcMain) {
DrawMainButton(Red, xd00, xd01, xd02, xd03, yd02, yd03, Theme.Color(clrButtonRedFg), Theme.Color(clrButtonRedBg), font);DrawMainButton(Green, xd04, xd05, xd06, xd07, yd02, yd03, Theme.Color(clrButtonGreenFg), Theme.Color(clrButtonGreenBg), font);DrawMainButton(Yellow, xd00, xd01, xd02, xd03, yd04, yd05, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font);DrawMainButton(Blue, xd04, xd05, xd06, xd07, yd04, yd05, Theme.Color(clrButtonBlueFg), Theme.Color(clrButtonBlueBg), font);
DrawMainButton(lutKeys[Setup.Button0], xd00, xd01, xd02, xd03, yd02, yd03, Theme.Color(lutFg[Setup.Button0]), Theme.Color(lutBg[Setup.Button0]), font);DrawMainButton(lutKeys[Setup.Button1], xd04, xd05, xd06, xd07, yd02, yd03, Theme.Color(lutFg[Setup.Button1]), Theme.Color(lutBg[Setup.Button1]), font);DrawMainButton(lutKeys[Setup.Button2], xd00, xd01, xd02, xd03, yd04, yd05, Theme.Color(lutFg[Setup.Button2]), Theme.Color(lutBg[Setup.Button2]), font);DrawMainButton(lutKeys[Setup.Button3], xd04, xd05, xd06, xd07, yd04, yd05, Theme.Color(lutFg[Setup.Button3]), Theme.Color(lutBg[Setup.Button3]), font); }
osd->DrawText(xb02, yb14, Red, Theme.Color(clrButtonRedFg), Theme.Color(clrButtonRedBg), font, xb03 - xb02, h, taLeft | taBorder);osd->DrawText(xb06, yb14, Green, Theme.Color(clrButtonGreenFg), Theme.Color(clrButtonGreenBg), font, xb07 - xb06, h, taLeft | taBorder);osd->DrawText(xb10, yb14, Yellow, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font, xb11 - xb10, h, taLeft | taBorder);osd->DrawText(xb14, yb14, Blue, Theme.Color(clrButtonBlueFg), Theme.Color(clrButtonBlueBg), font, xb15 - xb14, h, taLeft | taBorder);
osd->DrawText(xb02, yb14, lutKeys[Setup.Button0], Theme.Color(lutFg[Setup.Button0]), Theme.Color(lutBg[Setup.Button0]), font, xb03 - xb02, h, taLeft | taBorder);osd->DrawText(xb06, yb14, lutKeys[Setup.Button1], Theme.Color(lutFg[Setup.Button1]), Theme.Color(lutBg[Setup.Button1]), font, xb07 - xb06, h, taLeft | taBorder);osd->DrawText(xb10, yb14, lutKeys[Setup.Button2], Theme.Color(lutFg[Setup.Button2]), Theme.Color(lutBg[Setup.Button2]), font, xb11 - xb10, h, taLeft | taBorder);osd->DrawText(xb14, yb14, lutKeys[Setup.Button3], Theme.Color(lutFg[Setup.Button3]), Theme.Color(lutBg[Setup.Button3]), font, xb15 - xb14, h, taLeft | taBorder); }diff --git a/skinsttng.c b/skinsttng.c index d985538..49c94d4 100644 --- a/skinsttng.c +++ b/skinsttng.c @@ -571,6 +571,9 @@ void cSkinSTTNGDisplayMenu::SetTitle(const char *Title)
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 = 2 * Gap;
@@ -585,10 +588,10 @@ void cSkinSTTNGDisplayMenu::SetButtons(const char *Red, const char *Green, const 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)
On Mon, Jul 23, 2012 at 2:21 AM, oliver+list@schinagl.nl wrote:
VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort.
The ability to customize the order of the colored buttons is something I was hoping to see in the VDR reboot/redesign/next-generation/whatever, after 2.0 is released. If your patch is adopted before that, I don't think an altered button order should be displayed if the skin doesn't support it since it could cause confusion for the user -- more specifically the wives and kids in VDR world. :)
In other words, does the skin support button reorder? if yes, then reorder them in the osd if no, do not reorder them in the osd
On 08/11/12 23:48, VDR User wrote:
On Mon, Jul 23, 2012 at 2:21 AM,oliver+list@schinagl.nl wrote:
VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort.
The ability to customize the order of the colored buttons is something I was hoping to see in the VDR reboot/redesign/next-generation/whatever, after 2.0 is released. If your patch is adopted before that,
I would hope so, it is a rather trivial patch
I don't think an altered button order should be displayed if the skin doesn't support it since it could cause confusion for the user -- more specifically the wives and kids in VDR world. :)
Indeed :)
In other words, does the skin support button reorder? if yes, then reorder them in the osd if no, do not reorder them in the osd
It should exactly do that. Button order is stored in VDR, but the skin decides whether it uses it or not.
I patched the default 3 skins included in VDR to follow the reordering. 3rd party skins I have not patched and thus are not using the re-ording. It is fully optional for skin devs. That said, in the skin it is also very trivial to use :)
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 12.08.2012 00:04, Oliver Schinagl wrote:
On 08/11/12 23:48, VDR User wrote:
On Mon, Jul 23, 2012 at 2:21 AM,oliver+list@schinagl.nl wrote:
VDR currently assumes all remote controls have the same order of buttons. This is not always the case. This patch allows you to change the order of buttons in the UI.
This feature obviously only works on patched skins. Classic, lcars and sttng skins are patched. Unpatched skins will remain to work fine, but will ignore button order. Patching of the skin takes very minimum effort.
The ability to customize the order of the colored buttons is something I was hoping to see in the VDR reboot/redesign/next-generation/whatever, after 2.0 is released. If your patch is adopted before that,
I would hope so, it is a rather trivial patch
But is it really that necessary? I haven't seen any postings here actually supporting that idea. The "quasi standard" sequence of the color buttons *is* RGYB...
Klaus
But is it really that necessary?
I guess it depends on the point of view.
It is right not all remotes provide the same key order, but the master plan since over 10 years is "RGYB". So if a individual doesn't want to use a remote following VDR's standard, should find a way around by themself, at least from my point of view. But hence, functionality of the color buttons remains still the same, even ist "YBRG" or what ever, pretty sure users get used to it after a while ...
I haven't seen any postings here actually supporting that idea. The "quasi standard" sequence of the color buttons *is* RGYB...
Outside OSD the color buttons can be defined freely, but inside they is kind of fixed definitons fixed for these keys by source code. Maybe the target is to get a possibilty to change these now somewhat fixed mapping, that each individual can define ther what it want to have. Even the order, to match the order on the "non-VDR" remote ...
And yes, I remember 1 or 2 questions in vdr-portal regarding this ... ;-)
Regards fnu
On Sun, Aug 12, 2012 at 2:52 AM, fnu vdr@auktion.hostingkunde.de wrote:
But is it really that necessary?
I guess it depends on the point of view.
It is right not all remotes provide the same key order, but the master plan since over 10 years is "RGYB". So if a individual doesn't want to use a remote following VDR's standard, should find a way around by themself, at least from my point of view. But hence, functionality of the color buttons remains still the same, even ist "YBRG" or what ever, pretty sure users get used to it after a while ...
First, it's not true remote have followed some "master plan" for 10 years that's RGYB. You can buy several remotes right now, in 2012, which don't follow this. Some systems that come with remotes, don't follow this.
Next, good design accommodates as many users as possible -- that should be the "VDR standard", not telling people to buy different hardware, "get used to it", or create a workaround themselves (when probably 99.9% of VDR users are not coders).
If what Oliver said is true, that this type of functionality is easy to implement, what harm is being done by giving VDR users the ability to better customize their system to suit their needs?
For the record, I also have a remote with a different button order. I eventually would up spending extra money on one that matched VDR because it's too bizarre to have ffw on the left and rew on the right.
On 12.08.2012 11:52, fnu wrote:
... Outside OSD the color buttons can be defined freely, but inside they is kind of fixed definitons fixed for these keys by source code. Maybe the target is to get a possibilty to change these now somewhat fixed mapping, that each individual can define ther what it want to have. Even the order, to match the order on the "non-VDR" remote ...
I'm considering adopting the "Make RGYB buttons customizable" patch, but I don't think it would be a good idea to modify the actual functionality of these buttons For one, this would require some major changes in VDR's own code, and also any plugins that use color buttons. And it would also affect tools that issue key presses via the SVDRP command HITK. Any documentation that mentions the color keys would no longer apply if the keys don't result in the original commands. And finally, users could no longer simply say things like "to play the recording from the very beginning, press the green button now". They would have to know the color key sequence of the remote control in use in order to talk in terms of color keys.
So before I adopt this patch, I want to make it very clear that this is *not* going to be the first step towards a "babylonical" confusion... ;-)
Klaus
On Sunday 09 September 2012 - 13:20:24, Klaus Schmidinger wrote:
..., but I don't think it would be a good idea to modify the actual functionality of these buttons ... and it would also affect tools that issue key presses via the SVDRP command HITK.
So before I adopt this patch, I want to make it very clear that this is *not* going to be the first step towards a "babylonical" confusion... ;-)
Isn't that a big overkill?
The buttons already have the ability to get labeled and plugin-developers can assign individual actions ...
I think, nobody will start to redefine a red button to become magenta or pink. ... and if a remote control exists, that have all color keys being black - I guess nobody would redefine the color buttons to become black1, black2, ... So I don't see the necessity to really change core code.
The only agreed requirement is to be able to change the (visual) order of the buttons. The red button will stay red and a green button will continue being green. So there's no need to change SetHelp() call or the like. The order of the parameters of SetHelp() has very little in common with the visual representation - the parameter names of SetHelp() reflect the real button.
Only the visual order needs to be customizable. If that's already a skin issue, I guess very little has to be changed in core vdr.
cheers Gero
On 09.09.2012 14:10, Gero wrote:
On Sunday 09 September 2012 - 13:20:24, Klaus Schmidinger wrote:
..., but I don't think it would be a good idea to modify the actual functionality of these buttons ... and it would also affect tools that issue key presses via the SVDRP command HITK.
So before I adopt this patch, I want to make it very clear that this is *not* going to be the first step towards a "babylonical" confusion... ;-)
Isn't that a big overkill?
The buttons already have the ability to get labeled and plugin-developers can assign individual actions ...
I think, nobody will start to redefine a red button to become magenta or pink. ... and if a remote control exists, that have all color keys being black - I guess nobody would redefine the color buttons to become black1, black2, ... So I don't see the necessity to really change core code.
The only agreed requirement is to be able to change the (visual) order of the buttons. The red button will stay red and a green button will continue being green. So there's no need to change SetHelp() call or the like. The order of the parameters of SetHelp() has very little in common with the visual representation - the parameter names of SetHelp() reflect the real button.
Only the visual order needs to be customizable. If that's already a skin issue, I guess very little has to be changed in core vdr.
I'm not sure whether you understood what I meant. Of course "red" will remain "red" etc. But a red button that has, say, "Open" as its function will still have that function, even if it is no longer the leftmost button.
Anyway, I have attached a revised version of the patch. I have changed some variable names to better reflect the distinction between "keys" on the remote control and "buttons" displayed on the menus. I have also adjusted drawing the small rectangles to the left of each color button in the LCARS skin.
Please have a look an let me know if there's anything wrong with this.
Klaus
On Sunday 09 September 2012 - 14:53:42, Klaus Schmidinger wrote:
I'm not sure whether you understood what I meant.
Never mind ;)
Of course "red" will remain "red" etc. But a red button that has, say, "Open" as its function will still have that function, even if it is no longer the leftmost button.
You know, there's more than one way to skin a cat.
I sugested to leave the buttons and change their positions only, where as your patch changes all but the positions. I think, your way is the hard one, but the result for the user would be the same.
Additionally I don't think, the button order is prominent enuf to rise them to osd setup menu. Edit /etc/defaults (or similar files) would be fine for that (like remote.conf)
Just my 2c
cheers Gero
On 09.09.2012 17:39, Gero wrote:
... I sugested to leave the buttons and change their positions only, where as your patch changes all but the positions. I think, your way is the hard one, but the result for the user would be the same.
Ah, now I see what you mean. Something along the lines of
int h = yb15 - yb14; int lutX[] = { xb02, xb06, xb10, xb14 }; int lutW[] = { xb03 - xb02, xb07 - xb06, xb11 - xb10, xb15 - xb14 }; osd->DrawText(lutX[Setup.ColorKey0], yb14, Red, Theme.Color(clrButtonRedFg), Theme.Color(clrButtonRedBg), font, lutW[Setup.ColorKey0], h, taLeft | taBorder); osd->DrawText(lutX[Setup.ColorKey1], yb14, Green, Theme.Color(clrButtonGreenFg), Theme.Color(clrButtonGreenBg), font, lutW[Setup.ColorKey1], h, taLeft | taBorder); osd->DrawText(lutX[Setup.ColorKey2], yb14, Yellow, Theme.Color(clrButtonYellowFg), Theme.Color(clrButtonYellowBg), font, lutW[Setup.ColorKey2], h, taLeft | taBorder); osd->DrawText(lutX[Setup.ColorKey3], yb14, Blue, Theme.Color(clrButtonBlueFg), Theme.Color(clrButtonBlueBg), font, lutW[Setup.ColorKey3], h, taLeft | taBorder);
Well, either way is OK.
Additionally I don't think, the button order is prominent enuf to rise them to osd setup menu. Edit /etc/defaults (or similar files) would be fine for that (like remote.conf)
Strange. First the button order is so important and then it's not important enough to justify a setup menu option ;-) But since the code is already there...
Klaus
On Sun, Sep 9, 2012 at 8:39 AM, Gero geronimo013@gmx.de wrote:
Additionally I don't think, the button order is prominent enuf to rise them to osd setup menu. Edit /etc/defaults (or similar files) would be fine for that (like remote.conf)
OSD setup options are a matter of convenience. The more the user can do in the osd, the better. The more the user has to do by manually editing files, the worse.
On Sunday 09 September 2012 - 19:35:20, VDR User wrote:
OSD setup options are a matter of convenience.
Agree.
The more the user can do in the osd, the better. The more the user has to do by manually editing files, the worse.
Don't agree!
From my point of view, the setup options have to get divided into frontend- and backend-settings. Then all settings of each group should get divided into installation settings and user-changeable settings.
For me, all FHS-related settings are installation settings. Same is true for remote.conf and - of cause - the button order.
If you look at a possible multi-client installation, the button order is a frontend-setting, which is an installation setting. You only change it, when you buy a new remote control and then, the button order is not the only setting, that needs to get changed.
I consider it ridiculous, being able to change the video-driver by osd. That video driver is used by xine to render images to frontend, which possibly is on a different machine. This way it is possible to crash the vdr without possibility of recovery.
So moving a setup entry from osd to i.e. /etc/default/vdr may possibly decrease user flexibility, but may increase system stability and safety.
So from my point of view, osd-setup entries are user-changeable backend settings (well, currently the frontend user-changeable settings are stil mixed within). All other entries should be handled differently. But that issue will probabely pop up again after 2.0
cheers Gero
The majority of users I know are using VDR in a dedicated environment with only a remote control for input. Any maintenance is done via ssh. Even if that wasn't the case, I still believe the more configuration a user can do in one place, the better. It makes less sense to me that users be forced to change settings using different methods depending on what they want to change. Every user has access to the OSD and a way to use/navigate it, but not every user can easily go around manually editing different files.
As far as any potential problems that could arise from giving the user a more convenient & streamlined experience, that's where well thought out & proper design come into play. You want enough flexibility to either deal with those problems, or avoid them altogether.
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
yours, Jouni
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
Klaus
On 12.8.2012 15.32, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I have too.. Already for years (from 2005).. I have RGBY. It's "Silver Stone" -case with integrated IR remote.
On 12.8.2012 16.09, fnu wrote:
I have too.. Already for years (from 2005).. I have RGBY. It's "Silver
Stone" -case with integrated IR remote.
Well then you're already used to the "wrong" mapping. I guess you'll struggle if you get the correct order, isn't it ... ?
SCNR ... ;-)
Regards
fnu
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Actually, I have changed it in config file so that buttons are at same order than what they are at screen. Colors are in wrong order, but right most button on screen (blue) is right most button (yellow) on remote.
On 12.08.2012 15:46, JJussi wrote:
On 12.8.2012 15.32, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I have too.. Already for years (from 2005).. I have RGBY. It's "Silver Stone" -case with integrated IR remote.
Me too. RGBY
yours, Jouni
On 08/12/12 16:15, Jouni Karvo wrote:
On 12.08.2012 15:46, JJussi wrote:
On 12.8.2012 15.32, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I have too.. Already for years (from 2005).. I have RGBY. It's "Silver Stone" -case with integrated IR remote.
Me too. RGBY
Try the patch, see if it works for you :D
yours, Jouni
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 08/12/12 14:32, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
Yes, hence why I wrote the patch.
My remote is actually quite common, it's the one from iMon, supplied with many HTPC cases, such as silverstone cases.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, Aug 12, 2012 at 02:32:29PM +0200, Klaus Schmidinger wrote:
On 12.08.2012 14:28, Jouni Karvo wrote:
On 12.08.2012 12:23, Klaus Schmidinger wrote:
But is it really that necessary?
It is not necessary, but having a remote with different order of coulours, it is weird to have them in a different order on the OSD and in the remote. Plus the skip 1min forwards and 1min backwards during a replay of a recording - it would be nicer to have the buttons in the right order in the remote for this. But naturally these are not functional problems, they are usability issues (and not a very big issue for me).
Do you actually *have* a remote control with "non-standard" color keys?
My HTPC case came with a "non-standard" remote, but I solved the problem as a hardware issue and swapped the buttons on the remote.
All it took was scissors and a small piece of tape.
Still, I think configurable buttons is a good idea.
Tobi listaccount@e-tobi.net writes:
On 12.08.2012 14:32, Klaus Schmidinger wrote:
Do you actually *have* a remote control with "non-standard" color keys?
I use an UR-2400 - R/Y/B/G.
...but I got used to it.
Same here, RYBG. I'll give the patch a try this evening. Thanks
-
fnu -
Gero -
jjtt＠mbnet.fi -
JJussi -
Jouni Karvo -
Klaus Schmidinger -
Oliver Schinagl -
oliver+list＠schinagl.nl
-
syrius.ml＠no-log.org -
Tobi -
VDR User