260 replies to this topic

[BuGless]

Indeed.

c. In some other skin I see reference to a Picon2 widget, which does not seem to work in standard OpenPLi; do I need a plugin installed for that?
d. I read somewhere that one can add supporting .py files to a skin; does anyone have an example or documentation on how this is to be accomplished?

UTSL reveals that a lot of these GraphMultiEPG variations (and some skins) seem to install extra .py files to provide for functions which are already provided for in the existing enigma2 (case in point: the Picon2 widget is both buggy and redundant; the same redundancy applies to some of the CoolGuide supporting .py files).

Also I now see how other skins add the supporting .py files; they are bluntly dropped into the filesystem.

[pieterg]

Also I now see how other skins add the supporting .py files; they are bluntly dropped into the filesystem.

indeed. And guess who get the blame, for the crashes

[BuGless]

I find that when using the <applet> directive, one can refer to widgets that carry a name="list" attribute using something like:

self["list"].instance.move(ePoint(0, textsize[1]))

Does anybody know if there is a way to access a widget which carries a source= attribute, but not a name= attribute?
What happens when several widgets carry the same name? (Or is that forbidden?)

Edited by BuGless, 21 October 2012 - 08:18.

[Rob van der Does]

You mean 'source="attribute" render="Label" '?

[BuGless]

You mean 'source="attribute" render="Label" '?

Yes, more specifically, I'm trying to solve the following issue:
In an effort to use as few templates as possible (ideally a single one) for a standard screen layout which includes legends for function buttons at the bottom in predefined places, I use the following code snippet to draw a red square, followed by a space, followed by the function description attached to the red button in that screen:

<panel position="right" size="50%,*">
  <ePixmap pixmap="PLi-HD/buttons/red.png" position="left" size="26,*"
	alphatest="on" />
  <panel position="left" font="Body" size="1w,*" />
  <widget name="red" position="fill" backgroundColor="black"
   font="Body" halign="left" valign="top" />
  <widget name="key_red" position="fill" backgroundColor="black"
   font="Body" halign="left" valign="top" />
  <widget name="red_text" position="fill" backgroundColor="black"
   font="Body" halign="left" valign="top" />
  <widget name="canceltext" position="fill" backgroundColor="black"
   font="Body" halign="left" valign="top" />
</panel>

This works as a charm, because only one of those widgets actually expands into a visible frame with the assigned text in it at anytime.
However, in some screens, there is yet another incantation for this string, and it is called up using:

  <widget render="Label" source="key_red" position="fill"
   backgroundColor="black" font="Body" halign="left" valign="top" />

This piece of code, however, comes into conflict with:

  <widget name="key_red" position="fill" backgroundColor="black"
   font="Body" halign="left" valign="top" />

If I place them together in the first snippet I showed above, then whenever the name="key_red" is filled, the source="key_red" blows up into something that fills the whole screen (which, in theory, is not even possible, because of the bounding panel box around it, but apparently that *is* what happens; possibly due to a rendering bug somewhere).

So the idea is, to actually retrofit and force the source="key_red" using some applet code to become zero sized whenever it is empty.
This however, is only possible if I can pinpoint it in the applet code.

P.S. The <panel> directive, is it only supported in OpenPLi, or is it supported on all distributions?

[littlesat]

And then this works only for the icon of the red button.... there is also a text field... en then the trouble really starts... That is why I made saperate templates for that...

[Rob van der Does]

P.S. The <panel> directive, is it only supported in OpenPLi, or is it supported on all distributions?

Only in PLi(based) images.

[littlesat]

This is one of the special OpenPLi features....

[BuGless]

And then this works only for the icon of the red button.... there is also a text field... en then the trouble really starts... That is why I made saperate templates for that...

Well, actually, my solution *solves* the text field problem. I'm only having trouble with the <widget source="key_red">, all the others work allright in a single template.

This is one of the special OpenPLi features....

Hmmm..., meaning that, in this case, I might as well fix the source="key_red" widget to play nice with the rest, instead of trying to kludge around it in the skin.xml? I mean, there is no "upstream" image to fix as well to make use of a skin using <panel>s?

[littlesat]

I'm only having trouble with the <widget source="key_red">

And the other one that is using widget source......
So did not made "merge" templates......

Edited by littlesat, 22 October 2012 - 11:09.

[Rob van der Does]

This works as a charm, because only one of those widgets actually expands into a visible frame with the assigned text in it at anytime.

Does this have a (negative) influence on the performance of the box?
After all the system now looks in many screens for a number of items that don't exist, and expresses an error for each one that hasn't been found.

[MiLo]

This works as a charm, because only one of those widgets actually expands into a visible frame with the assigned text in it at anytime.

Does this have a (negative) influence on the performance of the box?
After all the system now looks in many screens for a number of items that don't exist, and expresses an error for each one that hasn't been found.

And it will also kindly ask the user to go complain to the skin maker, for each of those...

[BuGless]

This works as a charm, because only one of those widgets actually expands into a visible frame with the assigned text in it at anytime.

Does this have a (negative) influence on the performance of the box?
After all the system now looks in many screens for a number of items that don't exist, and expresses an error for each one that hasn't been found.

Because the memory footprint of the skin actually becomes smaller, there is a slight chance that the performance actually will go up due to better cache locality. In any case, in practice (in using the skin), there is no noticeable performance impact (neither positive, nor negative).

Edited by BuGless, 22 October 2012 - 21:37.

[Rob van der Does]

This works as a charm, because only one of those widgets actually expands into a visible frame with the assigned text in it at anytime.

Does this have a (negative) influence on the performance of the box?
After all the system now looks in many screens for a number of items that don't exist, and expresses an error for each one that hasn't been found.

Because the memory footprint of the skin actually becomes smaller, there is a slight chance that the performance actually will go up due to better cache locality. In any case, in practice (in using the skin), there is no noticeable performance impact (neither positive, nor negative).

The memory 'footprint' of the skin is smaller thanks to the use of templates, not thanks to the grouping you did. And a footprint is static. But on opening of every screen that holds such a grouped-template the system does (relatively, I know I'm a bit exaggerating here) a lot of needless work. And reading a log (serial output) is a crime with the huge amount of reported errors.

[mirakels]

But on opening of every screen that holds such a grouped-template the system does (relatively, I know I'm a bit exaggerating here) a lot of needless work.

Could you please elaborate on this? Please explain this process and show what needless work is done...

[BuGless]

The memory 'footprint' of the skin is smaller thanks to the use of templates, not thanks to the grouping you did.

My grouping reduces the number of templates from about ten down to one, so that really reduces the memory footprint.

And a footprint is static.

A footprint uses a dynamic amount of cache at any point in time. If it fits in the cache, it becomes blazingly fast (factor 100 faster sometimes).

But on opening of every screen that holds such a grouped-template the system does (relatively, I know I'm a bit exaggerating here) a lot of needless work. And reading a log (serial output) is a crime with the huge amount of reported errors.

Where can I see the serial log output to check if accessing widgets that are not defined generate verbose error messages? (I have an ET9500, so I don't think I have an accessible serial console somewhere, at least not a physical one).

Edited by BuGless, 23 October 2012 - 09:11.

[littlesat]

so that really reduces the memory footprint.

That seems so... but isn't true....

[BuGless]

so that really reduces the memory footprint.

That seems so... but isn't true....

Because they are stored permanently in an expanded state?

[BuGless]

Incidentally, it seems like I have found the reason things go haywire when rendering a <widget source="key_red"> whilst the only definition available is a <widget name="key_red">. It seems that in the cases where the "source" one blows up, beyond the enclosing bounding box, the "name" one had been assigned an instance of Button instead of StaticText. Still need to figure out how to compensate in the Button class (any hints would be appreciated).

Edited by BuGless, 23 October 2012 - 12:36.

[MiLo]

My grouping reduces the number of templates from about ten down to one, so that really reduces the memory footprint.

But that one template is 10x larger than the other ones.

As for performance, template lookup uses a hash table (unlike the original DMM code which does a linear search through several lists), whereas each element in your template is traversed and resolved every time it's instantiated. Which makes it about 10x slower than have 10 separate templates for each case.

We're running Python on a MIPS, so you really don't have to worry about the CPU cache. Accessing a variable means finding its name in a string table, then follow the pointer in that table to the object it points to, and then usually call some method...