465 replies to this topic

[littlesat]

I'm afraid that can't be done without changing python code all over the place.... And/Or to break compatibility with 'other' skins.... Unless someone finds an extreme smart 'trick'

 

staticText is running via a source object... Label() and Button() are direct widgets.

Edited by littlesat, 17 January 2018 - 10:56.

[Huevos]

Label() and Button() are direct widgets AND source objects.

 

Label and Button already write to source="key_...". Fixing them so SetText pushes new text to source="key_..." would not break anything in python or any current skin. It is completely forwards and backwards compatible.

 

SetText not pushing to source="key_..." is a bug. It needs fixing.

[littlesat]

Sorry what do I miss here.....? So you have the solution?

Edited by littlesat, 17 January 2018 - 11:19.

[littlesat]

As far I can see the Label() and Button() widgets do have a setText function... See the init stuff...So setText should be possible there.... 

 

class Button(VariableText, HTMLComponent, GUIComponent):
  def __init__(self, text="", onClick = [ ]):
    GUIComponent.__init__(self)
    VariableText.__init__(self)
    self.setText(text)
    self.onClick = onClick

Edited by littlesat, 17 January 2018 - 11:24.

[Huevos]

Yes you have missed the whole point of the discussion.

 

I said there was a bug. I didn't say there wasn't a function. I said the function isn't working.

 

SetText works with name="key...".

 

When you set a new text it arrives at name="key..." and goes to the display.

 

But the new text does not arrive at source="key..." and does not get to the display. This means the text displayed is the same text that was used when Label was instantiated.

 

SetText to source="key..." is the "bug" that needs fixing.

 

Something in the CPP code is blocking SetText arriving at source="key...".

 

I do not have a fix. I have been trying to locate the problem for several days but someone that understands the code better needs to look.

 

If I had a fix I would have already submitted it to PLi.

Edited by Huevos, 17 January 2018 - 12:14.

[IanSav]

Hi Littlesat,

Actually now we get to the 'point' and difficulty....
 
In the skin xml above we currently left with ButtonTemplateConditional and ButtonTemplateConditional_S... I would simply remove Conditional from the name of the template....

No, those two could also be combined into a single template.

If you add the control mechanism for the other buttons then they too could be folded into the single template. It could look something like:

	<screen name="ButtonTemplate">
		<panel name="ButtonTemplate_R" conditional="key_red"/>
		<panel name="ButtonTemplate_G" conditional="key_green"/>
		<panel name="ButtonTemplate_Y" conditional="key_yellow"/>
		<panel name="ButtonTemplate_B" conditional="key_blue"/>
		<panel name="KeyMenuTemplate" conditional="key_menu"/>
		<panel name="KeyInfoTemplate" conditional="key_info"/>
		<panel name="KeyZeroTemplate" conditional="key_zero"/>
		<panel name="KeyOkTemplate" conditional="key_ok"/>
		<panel name="KeyOneTemplate" conditional="key_one"/>
		<panel name="KeyTextTemplate" conditional="key_text"/>
		<panel name="KeyTextTemplateBlue" conditional="key_textblue"/>
		<panel name="KeyExit" conditional="key_exit"/>
	</screen>

where for, as an example, for the RED button you have:

	<screen name="ButtonTemplate_R">
		<ePixmap pixmap="PLi-FullNightHD/buttons/red.png" position="192,1032" size="34,34" alphatest="blend"/>
		<widget source="key_red" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
		<widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
	</screen>

This ONE button template panel could be used for ALL screens that require a standard button template.

 

In the example of the RED button above you should note that backward compatibility is maintained because all the Label(), Button() and StaticText() functions can and will be rendered on the screen.  Nothing should break if the code if fixed as per Huevos' requests. 

 

Regards,
Ian.
 

Edited by IanSav, 17 January 2018 - 13:21.

[IanSav]

Hi,
 
I just noticed that my quick compilation of the above RED sample there are two different "backgroundColor"s used (darkgrey and black).  In a real production version of the suggestion these should be the same colour.

 

Regards,

Ian.

[littlesat]

So this is not an issue...?

Nice to know....

    <screen name="ButtonTemplate_R">
        <ePixmap pixmap="PLi-FullNightHD/buttons/red.png" position="192,1032" size="34,34" alphatest="blend"/>
        <widget source="key_red" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
        <widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
    </screen>

Edited by littlesat, 17 January 2018 - 14:23.

[littlesat]

So we can also consider this..? When I add to conditional or a different parameter that can hide the button when the text is empty then I suppose we're done here....

    <screen name="ButtonTemplate">
        <ePixmap pixmap="PLi-FullNightHD/buttons/red.png" position="192,1032" size="34,34" alphatest="blend" conditional="key_red"/>
        <widget source="key_red" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left" conditional="key_red"/>
        <widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left" conditional="key_red"/>
 
        <ePixmap pixmap="PLi-FullNightHD/buttons/green.png" position="192,1032" size="34,34" alphatest="blend" conditional="key_green"/>
        <widget source="key_green" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left" conditional="key_green"/>
        <widget name="key_green" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/ conditional="key_green">
 
etc. etc...
 
    </screen>

Edited by littlesat, 17 January 2018 - 14:28.

[littlesat]

setText can't work for Label() and Button() because it is not a source object... it is a static label.... And there rare thing is staticText is not static at all...

[Huevos]

setText can't work for Label() and Button() because it is not a source object... it is a static label.... And there rare thing is staticText is not static at all...

Obviously you haven't done any testing because if you had you would know this statement is completely wrong.

 

I'll provide you with some code to help you understand the problem.

[littlesat]

Does this mean you already learned Button() and Label() having texts updated? 

 

Indeed I'm just looking to the code as at this moment I have limited time to do some real testing. And for me staticText is a 'source' and Label()/Button() is something 'static'.... Button() was once made to put an action function behind it, but as far I can see this was never used... (could we consider to make this equivalent to Label?)

Edited by littlesat, 17 January 2018 - 16:46.

[Huevos]

Littlesat, I have made a simple plugin so you can see what happens at object creation and what happens on sending setText().

 

This is object creation.

 1.jpg   81.69KB   4 downloads

 

This is what happens on sending setText().

 2.jpg   67.14KB   4 downloads

 

This is what happens on sending setText() again.

 3.jpg   119.18KB   3 downloads

 

So, the bug fix that is needed is that all those texts remain synchronized whenever setText() is sent.

 

 ButtonTexts.zip   2.26KB   4 downloads

Edited by Huevos, 18 January 2018 - 00:33.

[birdman]

Button() and Label()...

 

...For example in setup.py the buttons use Label(). Why is this allowed?

That looks like a bug in the handling code.

Surely a Label is a piece of text while a Button is something that will, when selected and "acted upon", will carry out an action.

So a Button that can use a Label is actually a Label, as it can't have an action.

[Huevos]

 

Button() and Label()...

 

...For example in setup.py the buttons use Label(). Why is this allowed?

That looks like a bug in the handling code.

Surely a Label is a piece of text while a Button is something that will, when selected and "acted upon", will carry out an action.

So a Button that can use a Label is actually a Label, as it can't have an action.

 

I think historically they had different uses but now everyone uses them interchangeably. Core enigma code is a right mess. People just do what they like. Just looking for a way forward where all outputs remain in sync.

 

Easiest thing would be fix one properly and map the other 2 to the one that works properly. Discard the other two.

Edited by Huevos, 18 January 2018 - 01:44.

[IanSav]

Hi Littlesat,

 

So this is not an issue...?

Nice to know....

    <screen name="ButtonTemplate_R">
        <ePixmap pixmap="PLi-FullNightHD/buttons/red.png" position="192,1032" size="34,34" alphatest="blend"/>
        <widget source="key_red" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
        <widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
    </screen>

It works perfectly apart from the bug which causes the text from the two methods to become different and this results in overlapping DIFFERENT text on the screen.  This is the bug we are trying to get fixed.

 

Regards,

Ian.

[IanSav]

Hi Littlesat,
 

So we can also consider this..? When I add to conditional or a different parameter that can hide the button when the text is empty then I suppose we're done here....

    <screen name="ButtonTemplate">
        <ePixmap pixmap="PLi-FullNightHD/buttons/red.png" position="192,1032" size="34,34" alphatest="blend" conditional="key_red"/>
        <widget source="key_red" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left" conditional="key_red"/>
        <widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left" conditional="key_red"/>
 
        <ePixmap pixmap="PLi-FullNightHD/buttons/green.png" position="192,1032" size="34,34" alphatest="blend" conditional="key_green"/>
        <widget source="key_green" render="Label" position="242,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left" conditional="key_green"/>
        <widget name="key_green" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/ conditional="key_green">
 
etc. etc...
 
    </screen>

Yes, that simplification will work fine. I left the individual panels available in my proposal above so that skin developers can still access individual buttons should they so desire. In my OverlayHD skin I am hoping to condense the buttons down to a single panel. That is, once this bug is fixed.

Regards,
Ian.

[IanSav]

Hi Littlesat,

Does this mean you already learned Button() and Label() having texts updated? 
 
Indeed I'm just looking to the code as at this moment I have limited time to do some real testing. And for me staticText is a 'source' and Label()/Button() is something 'static'.... Button() was once made to put an action function behind it, but as far I can see this was never used... (could we consider to make this equivalent to Label?)

In my opinion the Button() and Label() objects are effectively identical. The original intent for Button() to generate HTML code has long since been abandoned. I believe that we could achieve code simplification if the two were folded into one. For legacy support Button() can become a re-class of Label(). All the underlying code can be simplified / condensed into a single code path via the Label() code.

Regards,
Ian.

[IanSav]

Hi Birdman,

Button() and Label()...
 
...For example in setup.py the buttons use Label(). Why is this allowed?

That looks like a bug in the handling code.
Surely a Label is a piece of text while a Button is something that will, when selected and "acted upon", will carry out an action.
So a Button that can use a Label is actually a Label, as it can't have an action.

It appears that Button() was intended to generate HTML code for a never completed HTML implementation. These days Button() and Label() do effectively the same thing. The HTML component of Button() is dead code that does nothing.

If it is decided that StaticText() should also be folded into Label(), as well as Button(), then so be it. We just need to make sure that all the screen widgets that use either "name=" or "source=" and "render=" definitions are properly populated.

Regards,
Ian.

[IanSav]

Hi Huevos,

Littlesat, I have made a simple plugin so you can see what happens at object creation and what happens on sending setText().
 
This is object creation.
1.jpg
 
This is what happens on sending setText().
2.jpg
 
This is what happens on sending setText() again.
3.jpg
 
So, the bug fix that is needed is that all those texts remain synchronized whenever setText() is sent.
 
ButtonTexts.zip

This is a very clean and succinct example of the problem.

In my button skin fragment people should see that if the "name=" and "source=" implementations are stacked on top of each other with a transparency in effect then the text will appear overlapped on the screen. This is the visual effect of this bug.

If the Label(), Button() and StaticText() objects are combined then the overlapped "name=" and "source=" would not be required.  Either version of the should be enough for the correct display of the information.  If both the "name=" and "source=" versions of the widget get the same and updated text then no skins should need to be corrected when the code fix is implemented.

Regards,
Ian.