465 replies to this topic

[MiLo]

Looking at the sources, "StaticText" is not a GUI component, it's a "Converter". So it's supposed to supply text to a GUI thingamajig, it's not something that's visible by itself.

Button and Label are GUI components, they have different C++ GUI classes underneath. There isn't much difference in the Python code for them.

[Huevos]

L [...] Button and Label are GUI components, they have different C++ GUI classes underneath. There isn't much difference in the Python code for them.

Problem is Button and Label don't update "source" when sending self["key_red"].SetText().

 

Can this be fixed?

[littlesat]

Which bug fix!
What exactly does condition do, where can I find it in the code... does it give false if a button/lable text is an empty string? Or could we better renane it to exist?

Edited by littlesat, 16 January 2018 - 20:51.

[Huevos]

Why would you want to rename something and break everyone's skins? Conditional checks the variable is assigned, not an empty string. Buttons are assigned in the _init_ but might contain an empty string. In these cases the button shows.

 

As I said above this is nothing to do with the bug. The bug is Label() and Button() only update "name", not "source" on sending "SetText". That means when sending new text to the display, the old text remains and the new text doesn't arrive at the display.

[littlesat]

What I want to add is something if amdictionary key e.g.
Key_red does not exists and if it exists and the object has a text and the text is empty you hide the label or widget...
So you can hide the button png when it does not exist....
Sounds we’re ‘tuned’ on different frequenties.... note
That the settext bug does not save lines in skins...

Edited by littlesat, 16 January 2018 - 22:04.

[Huevos]

W [...] That the settext bug does not save lines in skins...

Yes it does because you need twice as many templates. You just need to look at your own template file to see this. But also it is a skinners nightmare because they need to know the object type they are skinning. People creating a skin should be able to do so with just a list of names. They should not need to know the object types.

 

Anyway even if you don't agree about how much space could be saved in the skin file that doesn't detract from the fact that the bug exists and skinners have to work around it (again look at PLi template file).

[littlesat]

Sorry I don't get it! You still need to hide the red, green, yellow, blue 'dot', 'dash' png thing.... how do you do that with your suggestion?

Edited by littlesat, 16 January 2018 - 22:51.

[littlesat]

I found this in skin.py

 

This arranges that stuff is skipped while rendering the skin when a key mentioned within the conditional parameter(s) (delimited by ,) does not exist in a skin... 

 

Sounds like the conditional argument is critical...and sounds like we can remove all those RGYB RGY RG R etc... stuff when we use that conditional stuff....

On another place the conditional parameter is fully skipped...

 

But it cannot conditional hide a png when the referred widget has an empty sting to hide the png...

        def process_screen(widget, context):
                for w in widget.getchildren():
                        conditional = w.attrib.get('conditional')
                        if conditional and not [i for i in conditional.split(",") if i in screen.keys()]:
                                continue
                        p = processors.get(w.tag, process_none)
                        try:
                                p(w, context)
                        except SkinError, e:
                                print "[Skin] SKIN ERROR in screen '%s' widget '%s':" % (name, w.tag), e

Edited by littlesat, 16 January 2018 - 23:23.

[Huevos]

 

I found this in skin.py

 

This arranges that stuff is skipped while rendering the skin when a key does not exist in a skin... 

 

Sounds like the conditional argument is critical...and sounds like we can remove all those RGYB RGY RG R etc... stuff when we use that conditional stuff....

 

But it cannot conditional hide a png when the referred widget has an empty sting to hide the png...

        def process_screen(widget, context):
                for w in widget.getchildren():
                        conditional = w.attrib.get('conditional')
                        if conditional and not [i for i in conditional.split(",") if i in screen.keys()]:
                                continue
                        p = processors.get(w.tag, process_none)
                        try:
                                p(w, context)
                        except SkinError, e:
                                print "[Skin] SKIN ERROR in screen '%s' widget '%s':" % (name, w.tag), e

Correct. You cannot hide the png if the key is assigned but only contains an empty string. So yes you can get rid of most of those templates.

 

But the SetText bug still requires you to have 2 templates where otherwise one would be sufficient. And you have to add those on a screen by screen basis in your skin.xml file (hours of unnecessary work for the skinner). If the SetText bug was fixed you wouldn't need to call the button template at all from the skin.xml file because the button template would be part of your main template. That alone costs you around 100 lines in your skin file.

Edited by Huevos, 16 January 2018 - 23:31.

[Huevos]

Also, say you write a plugin and it has 2 colour buttons. Later you add another colour button for a new function. The new button appears "by magic" without anyone needing to update the skin.

Edited by Huevos, 16 January 2018 - 23:39.

[IanSav]

Hi MiLo,

Looking at the sources, "StaticText" is not a GUI component, it's a "Converter". So it's supposed to supply text to a GUI thingamajig, it's not something that's visible by itself.

Button and Label are GUI components, they have different C++ GUI classes underneath. There isn't much difference in the Python code for them.

From your look at the code, what purpose does the Button() control actually serve?  Given that the TV screen is not a touch surface and the HTML code functionality is not used in Enigma2 it would appear that Button() is actually an abandoned development path.  If this is so, wouldn't it make sense to delete all the code behind Button() and simply make Button() an alias for Label() for backward compatibility?  Removing obsolete and dead code is a good maintenance task.  Less cod, less chance for bugs and more memory for newer developments, etc.

 

Regards,

Ian.

[IanSav]

Hi Littlesat,

Which bug fix!
What exactly does condition do, where can I find it in the code... does it give false if a button/lable text is an empty string? Or could we better renane it to exist?

The trigger is not on the value of the setting.  The trigger is on the presence of the variable itself.  The content is effectively irrelevant.

 

Regards,

Ian.

[IanSav]

Hi Huevos,

But the SetText bug still requires you to have 2 templates where otherwise one would be sufficient. And you have to add those on a screen by screen basis in your skin.xml file (hours of unnecessary work for the skinner). If the SetText bug was fixed you wouldn't need to call the button template at all from the skin.xml file because the button template would be part of your main template. That alone costs you around 100 lines in your skin file.

Not only is the skin simplified, it is smaller, faster and consumes less memory.

 

Another benefit is that it simplified skin creation and will be MUCH easier for new people to pick up, learn and understand.

 

Regards,

Ian.

[IanSav]

 
Hi Littlesat,

But it cannot conditional hide a png when the referred widget has an empty sting to hide the png...

I am experimenting with this at the moment.

I am proposing that if a coder uses a syntax like:

self["key_menu"] = Button(_("MENU"));

in the screen code then a skinner can use code like:

<ePixmap pixmap="buttons/button_block_menu.png" position="50,670" size="50,35" alphatest="blend" conditional="key_menu" transparent="1" />

If the Button definition is not in the code then the skin will not display the button.  The skin definition of the MENU button can now become part of the global template but the button will only display if it is defined to be available.

The use of the text "MENU" in the button definition comes in handy for those skinners who don't want to use a graphical button but would rather define a text based button.

Regards,
Ian.

[Huevos]

 
Hi Littlesat,

But it cannot conditional hide a png when the referred widget has an empty sting to hide the png...

I am experimenting with this at the moment.

I am proposing that if a coder uses a syntax like:

self["key_menu"] = Button(_("MENU"));

in the screen code then a skinner can use code like:

<ePixmap pixmap="buttons/button_block_menu.png" position="50,670" size="50,35" alphatest="blend" conditional="key_menu" transparent="1" />

If the Button definition is not in the code then the skin will not display the button.  The skin definition of the MENU button can now become part of the global template but the button will only display if it is defined to be available.

The use of the text "MENU" in the button definition comes in handy for those skinners who don't want to use a graphical button but would rather define a text based button.

Regards,
Ian.

After giving this some thought it actually means you end up with more code rather than less, i,e, it is declared once in the scan but has to be declared everywhere in python (although it is optional). But declaring it in the skin is harmless and it means the coder (who might not have access to  the skin to edit)  can still make a button appear and disappear.

[littlesat]

I still think we cannot add the buttons on each screens... if zo the should appear on the same position for all screens and you take the positioning out of control of the skinners. So I still think for each screen you want these automatic button stuff you have to add the template... also think about some weird plugins where suddenly buttons pop up on rare places...
In our standard skin the template of course could be added to the bottom template which still avoids it appears on each screen...
There is no real bug, but we have to get rid of the difference between source and non source button text widgets... that is why I add S in the skin instead of calling it 1 and 2 saying nothing. I have no idea for now to solve this in an easy matter (also think about blugins)

Edited by littlesat, 17 January 2018 - 08:05.

[Huevos]

We are comparing with your current template system. When plugins have buttons that appear in weird places in your current system these need skinning individually and can't use templates. Same now, same with a conditional button bar.

 

The reason you need the "S" and non "S" versions in your current system is because SetText is broken for Label() and Button() objects.

 

A conditional button template for your current skin would look like this (PLi FullNightHD):

	<!-- Start: these are used by the conditional button bar -->
	<screen name="ButtonTemplate_R"> <!-- This is used where the object type is Label() or Button(). When SetText() is fixed this will no longer be required -->
		<panel name="ButtonRed"/>
		<widget name="key_red" position="242,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
	</screen>

	<screen name="ButtonTemplate_G"> <!-- This is used where the object type is Label() or Button(). When SetText() is fixed this will no longer be required -->
		<panel name="ButtonGreen"/>
		<widget name="key_green" position="678,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
	</screen>

	<screen name="ButtonTemplate_Y"> <!-- This is used where the object type is Label() or Button(). When SetText() is fixed this will no longer be required -->
		<panel name="ButtonYellow"/>
		<widget name="key_yellow" position="1114,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
	</screen>

	<screen name="ButtonTemplate_B"> <!-- This is used where the object type is Label() or Button(). When SetText() is fixed this will no longer be required -->
		<panel name="ButtonBlue"/>
		<widget name="key_blue" position="1550,1030" size="370,38" backgroundColor="black" zPosition="1" transparent="1" font="Regular;34" halign="left"/>
	</screen>
	
	<screen name="ButtonTemplate_RS"> <!-- This is used where the object type is StaticText(). When SetText() is fixed this can be used for Label() and Button() objects also -->
		<panel name="ButtonRed"/>
	 <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"/>
	</screen>

	<screen name="ButtonTemplate_GS"> <!-- This is used where the object type is StaticText(). When SetText() is fixed this can be used for Label() and Button() objects also -->
		<panel name="ButtonGreen"/>
		<widget source="key_green" render="Label" position="678,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
	</screen>

	<screen name="ButtonTemplate_YS"> <!-- This is used where the object type is StaticText(). When SetText() is fixed this can be used for Label() and Button() objects also -->
		<panel name="ButtonYellow"/>
		<widget source="key_yellow" render="Label" position="1114,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
	</screen>

	<screen name="ButtonTemplate_BS"> <!-- This is used where the object type is StaticText(). When SetText() is fixed this can be used for Label() and Button() objects also -->
		<panel name="ButtonBlue"/>
		<widget source="key_blue" render="Label" position="1550,1030" size="370,38" backgroundColor="darkgrey" zPosition="2" transparent="1" foregroundColor="grey" font="Regular;34" halign="left"/>
	</screen>
	
	<screen name="ButtonTemplateConditional"> <!-- This is used where the object type is Label() or Button(). When SetText() is fixed this will no longer be required -->
		<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"/>
	</screen>
	
	<screen name="ButtonTemplateConditional_S"> <!-- This is used where the object type is StaticText(). When SetText() is fixed this can be used for Label() and Button() objects also -->
		<panel name="ButtonTemplate_RS" conditional="key_red"/>
		<panel name="ButtonTemplate_GS" conditional="key_green"/>
		<panel name="ButtonTemplate_YS" conditional="key_yellow"/>
		<panel name="ButtonTemplate_BS" conditional="key_blue"/>
	</screen>
	
	<!-- End: these are used by the conditional button bar -->

 skin_templates.xml   29.12KB   1 downloads

Edited by Huevos, 17 January 2018 - 09:02.

[littlesat]

In short... could we make from Label() and Button() the same thing somehow to solve it gerally...

 

StaticText()? instead of 'fixing' what you called a bug? It might be an issue as StaticText has source="key_..." and "render=
"Label"... (that was why I added the S for source, static_text years ago)....

 

Label() and Button has name="key_..."

 

Due to source and render vs. name differences you cannot simply 'fix' this historical 'drama'.... One is running via a source object and the other are direct 'templates'.... and they are therefore more static then staticText...

 

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

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

[Huevos]

In short... could we make from Label() and Button() the same thing somehow to solve it gerally...

 

StaticText()? instead of 'fixing' what you called a bug? It might be an issue as StaticText has source="key_..." and "render=
"Label"... (that was why I added the S for source, static_text years ago)....

 

Label() and Button has name="key_..."

Let me just quickly tell you about Label() and Button() again.

 

When you send SetText to Label/Button, the new text appears in name="key_...". But the old text still remains in source="key_..." and "render="Label". So now the content of the two are different.

 

So Label and Button need fixing so that SetText also arrives at source="key_..." and "render="Label". The content must stay synchronized. At the moment it does not. That is the "bug".

 

Once fixed, the new text will arrive at both name="key_..." and source="key_...". That way it is completely backwards and forwards compatible.

[Huevos]

But you can't simply copy StaticText() because that does not send content to name="key_..." so backwards compatibility would be lost.

 

Label/Button need to display and update both name="key_..." and source="key_...". That way you have a proper backwards compatible solution.

Edited by Huevos, 17 January 2018 - 10:41.