465 replies to this topic

[MiLo]

@Milo,
 
produceHTML exists in the following python files:
...
Must be dead code. Nothing uses that code anywhere in enigma or plugins.

Maybe in the WebInterface? Cannot imagine that, but you never know...

[Huevos]

Either way, can something be added to Label() and Button() so that "source" is updated on calling setText().

 

E.g. when I do this:

self.["key_yellow"].setText("New text")

With "source" in the skin, not "name"... e.g.:

<widget source="key_yellow" render="label" position="50,385" size="500,80" font="Regular;18" halign="center" valign="top" transparent="0" zPosition="1"/>

I want the display to update. Currently that is broken and does not update. Can anyone fix this as it is beyond me how to repair it.

Edited by Huevos, 15 January 2018 - 20:00.

[MiLo]

I've removed the HTMLComponent stuff locally, let's see what happens...
Nothing bad, so good riddance. WebInterface also still works.

Edited by MiLo, 15 January 2018 - 20:11.

[MiLo]

Either way, can something be added to Label() and Button() so that "source" is updated on calling setText().
 
E.g. when I do this:

self.["key_yellow"].setText("New text")

With "source" in the skin, not "name"... e.g.:

<widget source="key_yellow" render="label" position="50,385" size="500,80" font="Regular;18" halign="center" valign="top" transparent="0" zPosition="1"/>

I want the display to update. Currently that is broken and does not update. Can anyone fix this as it is beyond me how to repair it.

Hmm, 's been a while since I dug into the skinning stuff. Might be an easy fix, will see...

[Huevos]

 

Either way, can something be added to Label() and Button() so that "source" is updated on calling setText().
 
E.g. when I do this:

self.["key_yellow"].setText("New text")

With "source" in the skin, not "name"... e.g.:

<widget source="key_yellow" render="label" position="50,385" size="500,80" font="Regular;18" halign="center" valign="top" transparent="0" zPosition="1"/>

I want the display to update. Currently that is broken and does not update. Can anyone fix this as it is beyond me how to repair it.

 

Hmm, 's been a while since I dug into the skinning stuff. Might be an easy fix, will see...

 

But it is not a problem in the skin. It is a bug in the Python code.

 

Anyway thanks for taking the time to have a look.

[IanSav]

Hi MiLo,

 

Thank you for investigating this issue.  On the Beyonwiz build (Beyonwiz is an Australian manufacturer of Enigma2 based PVRs for the Australian and New Zealand markets - I am one of the Beyonwiz coders and a skin designer) we put some code in place to try and address this but it would be FAR better if the problem was properly fixed for everyone.  Beyonwiz is mostly based on OpenViX.  OpenViX draws code from OpenPLi.  A fix in OpenPLi should flow to both forks.  )

 

Regards,

Ian.

[Rob van der Does]

.....we put some code in place to try and address this but it would be FAR better if the problem was properly fixed for everyone......

This has been addressed in Python (Button & Label)? If so it might help if you publish that code here?

[IanSav]

Hi Rob,

 

I won't post the code as some testing I have just performed with Huevos shows that it hides the problem on selected skins but does not fix it.  The code suppresses the "source=" text so that the duplication doesn't look duplicated.  To be a true fix both the "name=" and "source=" versions should actually be displaying the same text!

 

A couple of us spent the day digging into the code and couldn't find an explanation for the problem or a solution.  This will probably require people with a more intimate knowledge of this code to investigate.

 

I can supply the Beyonwiz code if people are interested but I am concerned that it may just confuse the issue.

 

Regards,

Ian.

[Huevos]

I agree, please do not post that code. It does not fix the problem so would just be a distraction.

[Huevos]

Hi MiLo,

 

Thank you for investigating this issue.  On the Beyonwiz build (Beyonwiz is an Australian manufacturer of Enigma2 based PVRs for the Australian and New Zealand markets - I am one of the Beyonwiz coders and a skin designer) we put some code in place to try and address this but it would be FAR better if the problem was properly fixed for everyone.  Beyonwiz is mostly based on OpenViX.  OpenViX draws code from OpenPLi.  A fix in OpenPLi should flow to both forks.  )

 

Regards,

Ian.

Well PLi aren't worried about that. Most important thing for them is their own image gets fixed. That way skinning for everyone is going to get a whole lot simpler, instead of trying to find crazy workarounds in the skin for broken code in enigma.

[Huevos]

E.g. look at PLi Skins. The colour button bar code is duplicated and applied on a screen by screen basis. How inefficient is that because this bug exists. Pli can probably shorten its skins by 1000 lines by fixing this.

[littlesat]

Can you give an example.... T

 

The basic skin uses templates and per screen the buttons are only one line of xml code. There is almost 'nothing' to shorten. And it was Milo from OpenPLi who invent these templates years ago avoiding adding all these lines for png and text for the four colors. And it was me using it years ago in our 'basic' skins.

 

Originally at DMM time the buttons were just surfaces with a red, green, yellow or blue background. It was 'one' thing... But the latest skin do have a (colored) png with the text behind it. So by definition they have two parts... The png thing and the text thing...

Edited by littlesat, 16 January 2018 - 13:26.

[IanSav]

Hi,

 

In my opinion the problem we have here is a documentation and legacy issue.

 

If everyone agreed on the same way to display a colour button in the UI then all the skins would use the widget definition in the skin and there would be no problem.  The problem is that over time some people use Button(), some use Label() and others use StaticText().  If there was some basic programmer and skinner documentation this could all be avoided.

 

The sort things out now I think that programs could be written to scan the code and skins to find any instances of old style code or definitions and make corrections.  If this bug is fixed the changes could be made manually over time as all the existing code should work.  The ideal would be to encourage everyone to agree on the correct way to do things moving forward.

 

Regards,

Ian.

[Huevos]

Well for example in skin.xml you have stuff like this,

<panel name="ButtonTemplate_RG"/>

When this is fixed you won't need that any more. There will be one button template and it will be imported as part of your basic template.

 

At the moment though that is not possible because currently which button template is used depends on which object type was used to create the buttons in the python file.

 

And that is just a small example of the problems this bug is causing.

Edited by Huevos, 16 January 2018 - 14:57.

[littlesat]

You can't do that (currently) as some screens have more buttons then other screens... and the biggest 'sj*t' is that you need to keep stuff somehow backwards compatible....

(this might mean I also have to consider a separate screen for FlashImage as older skins are not compatible anymore)...

And actual please do not call it a 'bug'... this was something 'we' should cleanup years and years ago... This was how enigma2 was 'offered' to us..

When we have a way to enable/disable 'buttons/statictexts/lables/the pngs' when the 'label' is created in E2 it would be nice... But also here again sometimes a button is assigned to a source... so you endup still with two different stuff... and when you fixed it in enigma2 you have to keep backwards compatible support for all those plugins. Including 3rd party plugins. Which makes it an endless 'job'.

Edited by littlesat, 16 January 2018 - 15:45.

[Huevos]

Littlesat, fixing this bug doesn't break backwards compatibility. It just makes skinners lives simpler because they don't need to know what type of object created the text field. They only need to know what it is called.

 

As for the differing number of buttons that is not a problem. That can already be handled dynamically from within the skin.

 

https://github.com/O...s.xml#L150-L155

Edited by Huevos, 16 January 2018 - 16:51.

[Rob van der Does]

You can't do that (currently) as some screens have more buttons then other screens... and the biggest 'sj*t' is that you need to keep stuff somehow backwards compatible....

 
 

Littlesat, fixing this bug doesn't break backwards compatibility. It just makes skinners lives simpler because they don't need to know what type of object created the text field. They only need to know what it is called.
 
As for the differing number of buttons that is not a problem. That can already be handled dynamically from within the skin.
 
https://github.com/O...s.xml#L150-L155

Exactly, and that's also where the gain is for Pli: just one button template that's within the generic screen template. never worry about buttons again, don't even think about buttons at all (whether there are nil or four buttons in a screen).
So that saves thinking, coding and code.

[littlesat]

Please explain... probably I don’t understand it fully.... what bug do you try to fix? Or what smart ‘trick’ are you thinking of?
Where is that conditional parameter handled?
Why do you stil need buttons1’and buttons2 (not really good choosen)?
Could we also find a trick to fix the source/label stuf

For now you only try to reduce the rgyb stuff...

Edited by littlesat, 16 January 2018 - 18:00.

[Huevos]

Littlesat, the conditional is nothing to do with the bug. It is just used to discover which buttons a screen is using. That happens automatically.

 

But you need buttons 1 and buttons 2 because Label(), Button() and StaticText() are broken. If they weren't broken buttons 1 and buttons 2 would not be necessary. PLi has the equivalent to buttons 1 and buttons 2 in skin_template.xml but in the case of PLi instead of using 1 and 2 PLi uses an "S" suffix in the panel description. If the bug is fixed that will no longer be necessary and the button creation can be completely automatic. And also your number of templates can be halved.

 

The bug affects all text fields but only really shows when pushing text to the display. The problem is the functions are very similar and most coders are unaware of the bug so use them interchangeably. For more info on the differences in behaviour see post #7.

 

Ideally they should work all like this:

1. displays from name
2. displays from source
3. updates from name
4. updates from source

Fixing them will not break any current skin. It is completely backwards compatible. But means that after the bug fix skins can be simplified.

Edited by Huevos, 16 January 2018 - 19:14.

[Huevos]

Also, sometimes coders uses StaticText() for one button and Label() for another button. Doing so is completely incompatible with PLi button templates. With a bugfix it would be fine.