When I load the latest Enigma-v0.4-pre2, I get the following error in my syslog:
Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data
This error seems to come from parser.c in text2skin/xml. I tried testing the skin with T2S_EXT="true" and T2S_EXT="false" but it did not seem to make any difference. If I just comment out the ERROR in parser.c, then everything seems to work without problems. Although, I dont like to mask problems. Does anyone have a better idea what would be causing that error message?
BTW, I didnt think it was possible, but this skin just keeps getting better and better each time I look at it. Great Job so far!
Best Regards,
On Monday 17 October 2005 12:43, C.Y.M wrote:
When I load the latest Enigma-v0.4-pre2, I get the following error in my syslog:
Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data
This error seems to come from parser.c in text2skin/xml. I tried testing the skin with T2S_EXT="true" and T2S_EXT="false" but it did not seem to make any difference. If I just comment out the ERROR in parser.c, then everything seems to work without problems. Although, I dont like to mask problems. Does anyone have a better idea what would be causing that error message?
BTW, I didnt think it was possible, but this skin just keeps getting better and better each time I look at it. Great Job so far!
Best Regards,
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Could you please post the URL to get this version 0.4-pre2?
Thanks,
Alex
On Monday 17 October 2005 14:06, Alexw wrote:
On Monday 17 October 2005 12:43, C.Y.M wrote:
When I load the latest Enigma-v0.4-pre2, I get the following error in my syslog:
Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data
This error seems to come from parser.c in text2skin/xml. I tried testing the skin with T2S_EXT="true" and T2S_EXT="false" but it did not seem to make any difference. If I just comment out the ERROR in parser.c, then everything seems to work without problems. Although, I dont like to mask problems. Does anyone have a better idea what would be causing that error message?
BTW, I didnt think it was possible, but this skin just keeps getting better and better each time I look at it. Great Job so far!
Best Regards,
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Could you please post the URL to get this version 0.4-pre2?
Thanks,
Alex
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Answering myself:
Hi List!
First off: Sorry that I dind't announced the testing activities with Enigma here, but I thought there were only a few fixes and things to implement. But I was wrong and there was great feedback and good ideas, so the development of v0.4 takes more time than expected. I will of course announce the final release of the skin, but you are also all welcome to make any suggestion ... ;-) It is no problem to write your statement in English on the vdr-portal-Thread. It woul really be easier fo me if this all takes place at one forum/ml ... but I will also look into the ml from time to time if you prefer this list.
C.Y.M schrieb:
When I load the latest Enigma-v0.4-pre2, I get the following error in my syslog:
Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data
This error seems to come from parser.c in text2skin/xml. I tried testing the skin with T2S_EXT="true" and T2S_EXT="false" but it did not seem to make any difference. If I just comment out the ERROR in parser.c, then everything seems to work without problems. Although, I dont like to mask problems. Does anyone have a better idea what would be causing that error message?
Maybe Sascha can say something about it, but I will also have a look at it. Someone at the VDR-Portal also pointed out this Bug.
BTW, I didnt think it was possible, but this skin just keeps getting better and better each time I look at it. Great Job so far!
Thank you very much. :-)
Andreas Brugger wrote:
Hi List!
First off: Sorry that I dind't announced the testing activities with Enigma here, but I thought there were only a few fixes and things to implement. But I was wrong and there was great feedback and good ideas, so the development of v0.4 takes more time than expected. I will of course announce the final release of the skin, but you are also all welcome to make any suggestion ... ;-) It is no problem to write your statement in English on the vdr-portal-Thread. It woul really be easier fo me if this all takes place at one forum/ml ... but I will also look into the ml from time to time if you prefer this list.
C.Y.M schrieb:
When I load the latest Enigma-v0.4-pre2, I get the following error in my syslog:
Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data Oct 16 23:40:00 sid vdr[5851]: ERROR: Bad character data
This error seems to come from parser.c in text2skin/xml. I tried testing the skin with T2S_EXT="true" and T2S_EXT="false" but it did not seem to make any difference. If I just comment out the ERROR in parser.c, then everything seems to work without problems. Although, I dont like to mask problems. Does anyone have a better idea what would be causing that error message?
Maybe Sascha can say something about it, but I will also have a look at it. Someone at the VDR-Portal also pointed out this Bug.
Thanks, sorry for reporting twice. I noticed someone did mention the same problem on vdrportal as well. My online translators dont seem to work very well sometimes. :) At first I thought it was a missing case in this code block:
--SNIP--
if (end - start + 1 > 0) { //Dprintf("context: %s\n", context[context.size() - 1].c_str()); if (context[context.size() - 1] == "text" || context[context.size() - 1] == "marquee" || context[context.size() - 1] == "blink" || context[context.size() - 1] == "scrolltext") { if (!object->mText.Parse(text.substr(start, end - start + 1))) return false; } else esyslog("ERROR: Bad character data"); } return true;
--SNIP--
BTW, I didnt think it was possible, but this skin just keeps getting better and better each time I look at it. Great Job so far!
Thank you very much. :-)
Not to change the subject about the issue above, but would it also be possible to add the left/right scrolling back to the new menu display items (ie; current recordings and next timer)?
And thanks again, Andreas.
Best Regards,
Hi!
C.Y.M schrieb:
Thanks, sorry for reporting twice. I noticed someone did mention the same problem on vdrportal as well. My online translators dont seem to work very well sometimes. :)
No problem. This online translators are really bad most of the time. I also get confused if I try to translate french text for example using google ... but that's quite OT. ;-)
At first I thought it was a missing case in this code block:
--SNIP--
if (end - start + 1 > 0) { //Dprintf("context: %s\n", context[context.size() - 1].c_str()); if (context[context.size() - 1] == "text" || context[context.size() - 1] == "marquee" || context[context.size() - 1] == "blink" || context[context.size() - 1] == "scrolltext") { if (!object->mText.Parse(text.substr(start, end - start
- 1))) return false; } else esyslog("ERROR: Bad character data"); } return true;
--SNIP--
Why a missing case?
Not to change the subject about the issue above, but would it also be possible to add the left/right scrolling back to the new menu display items (ie; current recordings and next timer)?
I don't think that is too nice to look at ... especially if you have 2 or more recordings which are srolling in all directions (due to the different length of the text). And an additional keypress to go into the timers-menu if it is unclear what is getting recorded seemes not too tiresome to me. Don't you agree?
And thanks again, Andreas.
Thanks for the feedback.
At first I thought it was a missing case in this code block:
--SNIP--
if (end - start + 1 > 0) { //Dprintf("context: %s\n", context[context.size() -1].c_str()); if (context[context.size() - 1] == "text" || context[context.size() - 1] == "marquee" || context[context.size() - 1] == "blink" || context[context.size() - 1] == "scrolltext") { if (!object->mText.Parse(text.substr(start, end
- start
- 1))) return false; } else esyslog("ERROR: Bad character data"); } return true;
--SNIP--
Why a missing case?
You are right, I misread the code. It seems that one of the four context types is not parseable. Since I only get two "Bad character data" error messages during the initial startup of VDR, I am guessing the problem has to do with the skin.
Not to change the subject about the issue above, but would it also be possible to add the left/right scrolling back to the new menu display items (ie; current recordings and next timer)?
I don't think that is too nice to look at ... especially if you have 2 or more recordings which are srolling in all directions (due to the different length of the text). And an additional keypress to go into the timers-menu if it is unclear what is getting recorded seemes not too tiresome to me. Don't you agree?
IMHO, I think that if any text on the screen is cut off, it is better to allow scrolling. Text that is cut off just does not appear aesthetic to me. Does scrolling increase CPU usage very much?
Regards,
C.Y.M schrieb:
Why a missing case?
You are right, I misread the code. It seems that one of the four context types is not parseable. Since I only get two "Bad character data" error messages during the initial startup of VDR, I am guessing the problem has to do with the skin.
I think so too, but haven't looked into the code yet.
Not to change the subject about the issue above, but would it also be possible to add the left/right scrolling back to the new menu display items (ie; current recordings and next timer)?
I don't think that is too nice to look at ... especially if you have 2 or more recordings which are srolling in all directions (due to the different length of the text). And an additional keypress to go into the timers-menu if it is unclear what is getting recorded seemes not too tiresome to me. Don't you agree?
IMHO, I think that if any text on the screen is cut off, it is better to allow scrolling. Text that is cut off just does not appear aesthetic to me. Does scrolling increase CPU usage very much?
Maybe I will try it and see if it looks good to me. But if I don't include it, it isn't really hard for the user to change this few lines. I don't think that there is a to big drawback if it would scroll ... I think the skin wouldn't be very much slower. But there is still some potential in the patch I added, because now the timerstatus is checked every time you hit a key in the main menu, so it slows down scrolling. I will fix that for the next realease.
Talking of scrolling text: What would you think of scrolling text (in general not only in this case), if it would only scroll in one direction? I think there is no big benefit in scrolling back, as most of us only read in one direction. ;-) On the other side it would be a little more disturbing, as the text would jump back to the beginning ...
Bye, Andreas
Andreas Brugger wrote:
Talking of scrolling text: What would you think of scrolling text (in general not only in this case), if it would only scroll in one direction? I think there is no big benefit in scrolling back, as most of us only read in one direction. ;-) On the other side it would be a little more disturbing, as the text would jump back to the beginning ...
I would prefer this. If you have a long timername and you missed the beginning: it takes very long to realize the timer.
Andreas
/hgm.bg
IMHO, I think that if any text on the screen is cut off, it is better to allow scrolling. Text that is cut off just does not appear aesthetic to me. Does scrolling increase CPU usage very much?
Maybe I will try it and see if it looks good to me. But if I don't include it, it isn't really hard for the user to change this few lines. I don't think that there is a to big drawback if it would scroll ... I think the skin wouldn't be very much slower. But there is still some potential in the patch I added, because now the timerstatus is checked every time you hit a key in the main menu, so it slows down scrolling. I will fix that for the next realease.
Talking of scrolling text: What would you think of scrolling text (in general not only in this case), if it would only scroll in one direction? I think there is no big benefit in scrolling back, as most of us only read in one direction. ;-) On the other side it would be a little more disturbing, as the text would jump back to the beginning ...
I do like the idea you suggest about "scrolltext" instead of using "marquee". One directional might be better on the eyes. What ever method you do decide on, it would be very helpful to just place strategic comments into the template so a person that wants to modify the code can easily find the code blocks. Or, if we want to get really crazy, we could fix the template to use a variable which can be configured by UpdateEnigma.sh. We could have a different variable for different areas of the skin (ie; Menu, Channel Info, Timers, etc..)
--SNIP--
# defines preferred display method in skin ("text" or "scrolltext" or "marquee") MENU_DISPLAY="scrolltext" CHAN_DISPLAY="marquee" TIMER_DISPLAY="scrolltext"
--SNIP--
Best Regards,
I do like the idea you suggest about "scrolltext" instead of using "marquee". One directional might be better on the eyes. What ever method you do decide on, it would be very helpful to just place strategic comments into the template so a person that wants to modify the code can easily find the code blocks. Or, if we want to get really crazy, we could fix the template to use a variable which can be configured by UpdateEnigma.sh. We could have a different variable for different areas of the skin (ie; Menu, Channel Info, Timers, etc..)
--SNIP--
# defines preferred display method in skin ("text" or "scrolltext" or "marquee") MENU_DISPLAY="scrolltext" CHAN_DISPLAY="marquee" TIMER_DISPLAY="scrolltext"
--SNIP--
Here are some more changes required for the substitution method.
--SNIP--
# substitute display settings cat $SKIN_TEMPLATE \ | sed -e "s/%MENU_DISPLAY%/"$MENU_DISPLAY"/" \ | sed -e "s/%CHAN_DISPLAY%/"$CHAN_DISPLAY"/" \ | sed -e "s/%TIMER_DISPLAY%/"$TIMER_DISPLAY"/" \
$SKIN_TMP
--SNIP--
With attached changes to the template. This code is untested, but I'm sure it would work.
Best Regards,
C.Y.M wrote:
I do like the idea you suggest about "scrolltext" instead of using "marquee". One directional might be better on the eyes. What ever method you do decide on, it would be very helpful to just place strategic comments into the template so a person that wants to modify the code can easily find the code blocks. Or, if we want to get really crazy, we could fix the template to use a variable which can be configured by UpdateEnigma.sh. We could have a different variable for different areas of the skin (ie; Menu, Channel Info, Timers, etc..)
--SNIP--
# defines preferred display method in skin ("text" or "scrolltext" or "marquee") MENU_DISPLAY="scrolltext" CHAN_DISPLAY="marquee" TIMER_DISPLAY="scrolltext"
--SNIP--
Here are some more changes required for the substitution method.
Here is a tested and working patch for UpdateEnigma.sh. This patch in conjunction with the previous attachment (enigma-4pre2-display.diff) seems to work fine. The final stage of this patch is now to decide what areas of the skin are going to be substituted and made configurable.
Best Regards,
C.Y.M wrote:
C.Y.M wrote:
I do like the idea you suggest about "scrolltext" instead of using "marquee". One directional might be better on the eyes. What ever method you do decide on, it would be very helpful to just place strategic comments into the template so a person that wants to modify the code can easily find the code blocks. Or, if we want to get really crazy, we could fix the template to use a variable which can be configured by UpdateEnigma.sh. We could have a different variable for different areas of the skin (ie; Menu, Channel Info, Timers, etc..)
--SNIP--
# defines preferred display method in skin ("text" or "scrolltext" or "marquee") MENU_DISPLAY="scrolltext" CHAN_DISPLAY="marquee" TIMER_DISPLAY="scrolltext"
Hehe.. oops. "scrolltext" is not what I thought it was :) Of course "scrolltext" can be replaced with the appropriate identifier.
Best Regards.
Here are some more changes required for the substitution method.
Here is a tested and working patch for UpdateEnigma.sh. This patch in conjunction with the previous attachment (enigma-4pre2-display.diff) seems to work fine. The final stage of this patch is now to decide what areas of the skin are going to be substituted and made configurable.
Hmm, I sure did that the hard way. :) Here is a better, more simplified patch for UpdateEnigma.sh.
C.Y.M schrieb:
Here are some more changes required for the substitution method.
Here is a tested and working patch for UpdateEnigma.sh. This patch in conjunction with the previous attachment (enigma-4pre2-display.diff) seems to work fine. The final stage of this patch is now to decide what areas of the skin are going to be substituted and made configurable.
Hmm, I sure did that the hard way. :) Here is a better, more simplified patch for UpdateEnigma.sh.
diff -ruN Enigma.orig/scripts/UpdateEnigma.sh Enigma/scripts/UpdateEnigma.sh --- Enigma.orig/scripts/UpdateEnigma.sh 2005-10-21 15:55:16.000000000 -0700 +++ Enigma/scripts/UpdateEnigma.sh 2005-10-21 15:57:16.000000000 -0700 @@ -7,7 +7,9 @@ T2S_EXT="false" # defines if the switchonly-patch by LightYear is installed ("true" or "false") SW_ONLY="false"
+# defines preferred display method in skin ("text" or "scrolltext" or "marquee") +MENU_DISPLAY="marquee" +CHAN_DISPLAY="marquee"
# don't edit beyond here SKIN_TEMPLATE="$SKINPATH/Enigma.skin.template" @@ -71,6 +73,8 @@ | sed -e "s/%BLUE_R%/"$b_r"/" \ | sed -e "s/%BLUE_R_T%/"`expr $b_r + 0`"/" \ | sed -e "s/%BLUE_R_M1%/"`expr $b_r - 1`"/" \ +| sed -e "s/%MENU_DISPLAY%/"$MENU_DISPLAY"/g" \ +| sed -e "s/%CHAN_DISPLAY%/"$CHAN_DISPLAY"/g" \
$SKIN_TMP
# we have to avoid ',' in m4 so we replace it with ';'
I also thought about a configurable scrolling-mode. But I would rather make it dependend on the menu-element, which is much easier to implement:
MAIN_MENU_ITEM="text" # main menu entries SUB_MENU_ITEM="marquee" # entries in the sub-menu (timer and so on) SIDEBAR_ITEM="marquee" # Info in the main-menu (next timer, current recording and so on)
maybe also:
REPLAY_BAR="marquee" # title of the replay
Does it really make sense to use both, a marquee (btw, scrolltext token is already used for text wich goes over more lines) which scrolls in one direction and a marquee that scrolls in both directions? I would think this is a user-opinion which is best and the user would always use either of those. So it would be best to make this configurable in text2skin. Therefore the upper lines in UpdateEnigma.sh could also look like this:
SCROLL_MAIN_MENU_ITEM="false" # true or false SCROLL_ SUB_MENU_ITEM="true" SCROLL_ SIDEBAR_ITEM="false" SCROLL_ REPLAY_BAR="true"
What do you think about that?
I also thought about a configurable scrolling-mode. But I would rather make it dependend on the menu-element, which is much easier to implement:
MAIN_MENU_ITEM="text" # main menu entries SUB_MENU_ITEM="marquee" # entries in the sub-menu (timer and so on) SIDEBAR_ITEM="marquee" # Info in the main-menu (next timer, current recording and so on)
maybe also:
REPLAY_BAR="marquee" # title of the replay
Making the scrolling configurable with UpdateEnigma.sh is the best overall solution. I like how you have divided it up by menu elements.
Does it really make sense to use both, a marquee (btw, scrolltext token is already used for text wich goes over more lines) which scrolls in one direction and a marquee that scrolls in both directions? I would think this is a user-opinion which is best and the user would always use either of those. So it would be best to make this configurable in text2skin. Therefore the upper lines in UpdateEnigma.sh could also look
I doubt anyone will want to mix marquee with one-directional scrolling. Making this a configure option in text2skin should be fine.
like this:
SCROLL_MAIN_MENU_ITEM="false" # true or false SCROLL_ SUB_MENU_ITEM="true" SCROLL_ SIDEBAR_ITEM="false" SCROLL_ REPLAY_BAR="true"
Is the space after "SCROLL_ " on purpose?
What do you think about that?
Its great. Thanks!
C.Y.M schrieb:
like this:
SCROLL_MAIN_MENU_ITEM="false" # true or false SCROLL_ SUB_MENU_ITEM="true" SCROLL_ SIDEBAR_ITEM="false" SCROLL_ REPLAY_BAR="true"
Is the space after "SCROLL_ " on purpose?
Oh, this was a failure. There shouldn't be a space between
What do you think about that?
Its great. Thanks!
I will try to work this in. The TODO has become quite long now ... haven't thought that there was so much to do and there are so much ideas out there. ;-)
-
Alexw -
Andreas Brugger -
C.Y.M -
hgm.bg