Forums

The 'grouping' you do only slightly reduces the amount of code-lines. The gain on that is there, but only very limited.

You can run E2 in console to see the huge number of skin errors due the the grouping (and hence not finding many items in over 50% of the screens). Of course a serial console is more convenient to read (and store).

Having said all that: I really don't know what the balance is regarding the use of resources and the resulting system performance: (slightly) less memory because of a smaller skin, bur more to do in the sense of looking for/not finding/reporting.

I tried to do the best balance in the OpenPLi-HD skin...

The 'grouping' you do only slightly reduces the amount of code-lines. The gain on that is there, but only very limited.

Agreed. However, keep in mind, that performance gains or losses in this case are not the reason I'm trying to do this. The main reason is maintainability and the ability to easily change something in the layout which propagates automatically to all screens.

You can run E2 in console to see the huge number of skin errors due the the grouping (and hence not finding many items in over 50% of the screens). Of course a serial console is more convenient to read (and store).

You mean, simply starting enigma2 from the command line? Do I need any commandline flags to make it report any problems to stderr?

Having said all that: I really don't know what the balance is regarding the use of resources and the resulting system performance: (slightly) less memory because of a smaller skin, bur more to do in the sense of looking for/not finding/reporting.

The impression I have so far is that the boxes usually have CPU to spare. In any case, the extra variable accesses I'm adding don't seem to amount to any significant slowdown (or speedup, for that matter).
Edited by BuGless, 23 October 2012 - 15:10.

You can run E2 in console to see the huge number of skin errors due the the grouping (and hence not finding many items in over 50% of the screens). Of course a serial console is more convenient to read (and store).

You mean, simply starting enigma2 from the command line? Do I need any commandline flags to make it report any problems to stderr?

Nevermind. Tried it, it works. Interesting. Thanks, this helps (a lot) in some cases to debug the skin.

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).

Looking at the newfound console output, it shows:

[Skin] SKIN ERROR in ChannelSelection: 'Button' object has no attribute 'connectDownstream'

which correlates with the other findings. Anyone any idea what a connectDownstream attribute means?

Agreed. However, keep in mind, that performance gains or losses in this case are not the reason I'm trying to do this. The main reason is maintainability and the ability to easily change something in the layout which propagates automatically to all screens.

That is absolutely true.

The impression I have so far is that the boxes usually have CPU to spare. In any case, the extra variable accesses I'm adding don't seem to amount to any significant slowdown (or speedup, for that matter).

I do think you're right there. Nevertheless it must have impact, noticeable or not.
But the enormous amount of error reports makes a serial log very difficult to read.

cos' you call a screen which uses *widget name=""* instead of *widget source=""*.

cos' you call a screen which uses *widget name=""* instead of *widget source=""*.

To whom/what are you replying?

referring to bugless's skin error.

cos' you call a screen which uses *widget name=""* instead of *widget source=""*.

Erm, yes, well, thanks, of course.
However, I think I knew that already. I was looking for a more in depth explanation that explains what the function of a connectDownstream attribute/method is.

How is progress going on?

i tried your skin.xml in Pli HD skin but i got some half picture and no channel list.

My Tv is set to 1080i and no overscan, but it seems the skin takes more space as available like in screenshot.
Edited by delagroov, 17 November 2012 - 10:00.

How is progress going on?

i tried your skin.xml in Pli HD skin but i got some half picture and no channel list.

I've transformed a lot more screens by now, not finished with all them yet though.
I discovered that the initial resolution I set the skin to (1920 x 1080) is not supported on all boxes.
The good news though is, that the skin will support changing the skin resolution to anything you want, the screens will scale accordingly. What type of STP have you tried it on?

The show stopper at the moment is figuring out what to add to the Button class so it behaves a bit more sane with respect to canvas sizes when invoked as a Source class. If I do this now, it blows up to full-size frames if undefined; ideally it should simply result in a canvas of 0x0 size if undefined.
Edited by BuGless, 17 November 2012 - 23:17.

I tested on Ultimo

But do you have already a plugin also..to change the settings then?

In one of the first lines in the skin.xml you can set the resolution...

Ultimo is indeed not capable to display an ODS of 1920x1080... Only ET boxes and probably the XP can.

I alo tested with,

<output id="0">
<resolution bpp="32" xres="1280" yres="720" />
</output>

but that didn't improve layout issue
Edited by delagroov, 18 November 2012 - 09:03.

In one of the first lines in the skin.xml you can set the resolution...

Ultimo is indeed not capable to display an ODS of 1920x1080... Only ET boxes and probably the XP can.

dreamboxes also can display 1080 res skin

dreamboxes also can display 1080 res skin

This is new to me.... since when??

Actually the 7025 is capable of displaying a 1920x1080 OSD, but the drivers don't support it. Not that it would be useful, because the 7025 doesn't have any output possibility for such a resolution. I guess it's the same for the other boxes - the hardware can do it, but the drivers need to support it. And you'll be sacrificing double the amount of RAM for the OSD.
Edited by MiLo, 18 November 2012 - 19:46.

I believe the dmm drivers do support it (though not for the 7025 I suppose)

dreamboxes also can display 1080 res skin

This is new to me.... since when??

probably since OPli3.0, because with 2.1 was impossible