IanSav

Hi,

Is there anyone else who wants to improve or add any languages for the VirtualKeyBoard?

Regards,

Ian.

Hi Persian Prince,

Thank you for such a fantastic correction report.  It made the fix so easy and was very much appreciated.

Corrections made and here for your review.

I just need my Greek and Spanish reviews to come in and then I will submit the code.  All other languages can be upgraded or added at any time though I will add or make changes before submission if anyone offers me the information needed.

Regards,

Ian.

Hi,

I am currently rewriting the NumericalTextInput.py and VirtualKeyBoard.py Python code to improve functionality and presentation.

I am based in Australia and only know English.  I do not require any coding assistance as the new code is mostly already written.  I would like some assistant to improve the languages processed by these two Enigma2 modules.

For starters I would like to know what languages should be supported?  I would then like the assistance of any volunteers to add / correct the data tables for those languages.

The following languages are defined and have varying levels of support / accuracy:

• Arabic - United Arab Emirates : ar_AE
• Czech - Czechia : cs_CZ
• English - Australian : en_AU
• English - Various : en_EN
• Finnish - Finland : fi_FI
• French - France : fr_FR
• German - Germany : de_DE
• Greek (Modern) - Greece : el_GR
• Latvian - Latvia : lv_LV
• Persian - Iran, Islamic Republic : fa_IR
• Polish - Poland : pl_PL
• Russian - Russian Federation : ru_RU
• Slovak - Slovakia : sk_SK
• Spanish - Spain : es_ES
• Swedish - Sweden : sv_SE
• Thai - Thailand : th_TH
• Ukrainian - Ukraine : uk_UA

self.english = [
	[
		[u"`", u"1", u"2", u"3", u"4", u"5", u"6", u"7", u"8", u"9", u"0", u"-", u"=", u"BACKSPACE"],
		[u"FIRST", u"q", u"w", u"e", u"r", u"t", u"y", u"u", u"i", u"o", u"p", u"[", u"]", u"\\"],
		[u"LAST", u"a", u"s", u"d", u"f", u"g", u"h", u"j", u"k", u"l", u";", u"'", u"BLANK", u"ENTER"],
		[u"SHIFT", u"z", u"x", u"c", u"v", u"b", u"n", u"m", u",", u".", u"/", u"BLANK", u"BLANK", u"SHIFT"],
		[u"EXIT", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"BLANK", u"SPACE"]
	], [
		[u"~", u"!", u"@", u"#", u"$", u"%", u"^", u"&", u"*", u"(", u")", u"_", u"+", u"BACKSPACE"],
		[u"FIRST", u"Q", u"W", u"E", u"R", u"T", u"Y", u"U", u"I", u"O", u"P", u"{", u"}", u"|"],
		[u"LAST", u"A", u"S", u"D", u"F", u"G", u"H", u"J", u"K", u"L", u":", u"\"", u"BLANK", u"ENTER"],
		[u"SHIFT", u"Z", u"X", u"C", u"V", u"B", u"N", u"M", u"<", u">", u"?", u"BLANK", u"BLANK", u"SHIFT"],
		[u"EXIT", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"BLANK", u"SPACE"]
	]
]

self.german = [
	[
		[u"^", u"1", u"2", u"3", u"4", u"5", u"6", u"7", u"8", u"9", u"0", u"\u00DF", u"'", u"BACKSPACE"],
		[u"FIRST", u"q", u"w", u"e", u"r", u"t", u"z", u"u", u"i", u"o", u"p", u"\u00FC", u"+", u"BLANK"],
		[u"LAST", u"a", u"s", u"d", u"f", u"g", u"h", u"j", u"k", u"l", u"\u00F6", u"\u00E4", u"#", U"ENTER"],
		[u"SHIFT", u"<", u"y", u"x", u"c", u"v", u"b", u"n", u"m", u",", ".", u"-", u"BLANK", u"SHIFT"],
		[u"EXIT", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"BLANK", u"SPACE"]
	], [
		[u"\u00BA", u"!", u"\"", u"\u00A7", u"$", u"%", u"&", u"/", u"(", u")", u"=", u"?", u"`", u"BACKSPACE"],
		[u"FIRST", u"Q", u"W", u"E", u"R", u"T", u"Z", u"U", u"I", u"O", u"P", u"\u00DC", u"*", u"BLANK"],
		[u"LAST", u"A", u"S", u"D", u"F", u"G", u"H", u"J", u"K", u"L", u"\u00D6", u"\u00C4", u"'", U"ENTER"],
		[u"SHIFT", u">", u"Y", u"X", u"C", u"V", u"B", u"N", u"M", u";", u":", u"_", u"BLANK", U"SHIFT"],
		[u"EXIT", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"BLANK", u"SPACE"]
	], [
		[u"BLANK", u"BLANK", u"\u00B2", u"\u00B3", u"BLANK", u"BLANK", u"BLANK", u"{", u"[", u"]", u"}", u"\\", u"BLANK", u"BACKSPACE"],
		[u"FIRST", u"@", u"BLANK", u"\u20AC", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"~", u"BLANK"],
		[u"LAST", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"ENTER"],
		[u"SHIFT", u"|", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"\u00B5", u"BLANK", u"BLANK", u"BLANK", u"BLANK", u"SHIFT"],
		[u"EXIT", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"BLANK", u"SPACE"]
	]
]

Hi,
 
One of the Beyonwiz devs has suggested that I add the alternate syntax for setting the object values.  That is, as well as:

self["key_red"].setText(_("Close")

the following is equally acceptable:

self["key_red"].text = _("Close")

I have updates the documentation to reflect the additional syntax.

Proposal for Standardised and Uniform Buttons in Enigma2
--------------------------------------------------------
 
Written by IanSav - 12-Feb-2018
Updated by IanSav - 13-Feb-2018
 
INTRODUCTION:
=============
 
Enigma2 is a massive open source project that has many contributors and 
add-ons.  Over time a number of approaches to performing common tasks have 
evolved.  This document proposes to nominate some conventions that can be 
adopted by all developers, contributors and skin authors to ensure that 
everyone can work independently but still achieve results that work together 
interchangeably.
 
The purpose of this document is to propose some standard variable names 
together with code and skin coding conventions to make the task of creating 
code that works more universally with skins easier.
 
Button names should be drawn from the current button definitions in 
"keyids.py".  The names used should be the lower-case version of the button 
names in this file.  For example, if you wish to define a button for the RED 
button on the remote control then use a variable name of "key_red".  In 
Enigma2 the four colour buttons should be named "key_red", "key_green", 
"key_yellow" and "key_blue".
 
As an example, let us look at how the red button should be defined in the 
Python code and how it can be rendered in a skin.
 
COLOUR BUTTONS:
===============
 
In the Python code to define a RED button to be available in the skin simply 
add the following to your code:
 
from Components.Sources.StaticText import StaticText
 
self["key_red"] = StaticText(_("Cancel"))
 
The text should be language translated with the _("text") syntax.  The text 
itself should be as short as practical but clear enough to convey the 
meaning of the button.
 
During the execution of the code the meaning of the button can easily be 
changed by using the .setText() method.  For example:
 
self["key_red"].setText(_("Close")
or
self["key_red"].text = _("Close")
 
If you want to temporarily suppress the display of the button use the 
following syntax:
 
self["key_red"].setText("")
or
self["key_red"].text = ""
 
NOTE: Never translate an empty string, _(""), as this causes the translation 
system to output translation engine information and NOT a blank string as 
some may expect.
 
Now that the code is RED button enabled we need to code the skin to match.  
Here is a skin fragment that supports the code above:
 
<screen name="TemplateButtonRed">
<widget source="key_red" render="Pixmap" \
pixmap="buttons/button_red.png" position="10,10" \
size="200,30" alphatest="blend" conditional="key_red" \
transparent="1">
  <convert type="ConditionalShowHide" />
  </widget>
<widget source="key_red" render="Label" position="10,10" \
size="200,30" backgroundColor="ButtonRed" \
font="ButtonFont;20" foregroundColor="ButtonText" \
halign="center" conditional="key_red" transparent="1" \
valign="center" zPosition="+1" />
</screen>
 
The first widget checks if the variable "key_red" is defined in this screen 
via the "conditional" attribute.  If "key_red" is defined and not blank the 
image "buttons/button_red.png" is displayed on the screen.  The next widget 
also checks for the existence of "key_red" and then displays the button text 
over the image background.  Please note that a button image background is 
common but it is NOT required.  This is a design choice available to the 
skin author.
 
This sample would work well if all the code in Enigma2 was uniform and 
co-ordinated.  Unfortunately, we aren't there yet.  A more real-world example 
of how to define the button in a skin would be:
 
<screen name="TemplateButtonRed">
<ePixmap pixmap="buttons/button_red.png" position="10,10" \
size="200,30" alphatest="blend" \
objectTypes="key_red,Button,Label" transparent="1" />
<widget source="key_red" render="Pixmap" \
pixmap="buttons/button_red.png" position="10,10" \
size="200,30" alphatest="blend" \
objectTypes="key_red,StaticText" transparent="1">
  <convert type="ConditionalShowHide" />
  </widget>
<widget name="key_red" position="10,10" size="200,30" \
backgroundColor="ButtonRed" font="ButtonFont;20" \
foregroundColor="ButtonText" halign="center" \
objectTypes="key_red,Button,Label" transparent="1" \
valign="center" zPosition="+1" />
<widget source="key_red" render="Label" position="10,10" \
size="200,30" backgroundColor="ButtonRed" \
font="ButtonFont;20" foregroundColor="ButtonText" \
halign="center" objectTypes="key_red,StaticText" \
transparent="1" valign="center" zPosition="+1" />
</screen>
 
The difference here is that the button background image and the button 
text is defined twice.  This allows all legacy code that uses either 
Button(), Label() or StaticText() objects to define the code will still 
work in this proposed skin fragment.  The data from each of the object 
types is displayed overlapped on the screen.  To make this work without 
actually overlapping the data recent builds of OpenViX, OpenPLi and 
Beyonwiz firmware have added a new attribute to the skin parser.  This 
new attribute is "objectTypes".
 
The "objectTypes" attribute has a value consisting of a comma separated list 
of keywords.  Note that spaces around the comma(s) are NOT permitted.  The 
first value in the list must be the variable being checked, in this case 
"key_red".  This item is mandatory.  The following values are object type 
definitions of which this variable can be defined for this widget to be 
used.  The list can have zero or more object types listed.
 
The first value, the variable name, is processed in the same way as the 
conditional attribute.  If the variable is defined in the code then this 
screen widget is enabled and available for use.  If the variable is not 
defined in the code then this widget is ignored.
 
The following values arguments are a list of object types, like Button, 
Label or StaticText, the variable name's definition type is checked against 
the supplied list.  If the variable is not defined by one of the types in 
the list then that widget is ignored.  If there is a type match then the 
widget is enabled and available for use.  If no object types are listed then 
the "objectTypes" attribute works exactly the same as the "conditional" 
attribute.
 
IMPORTANT NOTE: The latter form of the skin XML code should be used to 
maintain backward compatibility with all existing Python code.  At some 
point in the future when all code is updated to support and comply with 
this proposal then the former, and simpler, version of the skin definition 
can be used as backward compatibility would no longer be an issue.
 
ACTION BUTTONS:
===============
 
Just like the colour buttons there are a number of standard action or 
functional buttons used.  For example, MENU, INFO, TEXT, HELP etc. 
Typically, these buttons are manually added / defined by skin writers 
in the various screens for which they are used.  This requirement places 
a heavy burden on skin writers who have to explore the Python code to 
determine when the various action buttons are defined and available for 
use.  If the buttons are defined then there should be definitions for those 
buttons in their skin.
 
As with the colour buttons it is quite easy to automate the inclusion of 
these standard action buttons in both the Python code and skin.
 
Let us use the example of the MENU button on the remote control let us look 
at how the red button should be defined in the Python code and how it can be 
rendered in a skin.
 
The Python code is exactly the same as that used by the colour button 
example above.  In the Python code to define a MENU button to be available 
in the skin simply add the following to your code:
 
from Components.Sources.StaticText import StaticText
 
self["key_menu"] = StaticText(_("MENU"))
 
The text for each action button should be language translated with the 
_("text") syntax.  The text itself should be as short as practical but clear 
enough to convey the meaning of the button.
 
If you want to temporarily suppress the display of the button use the 
following syntax:
 
self["key_menu"].setText("")
or
self["key_menu"].text = ""
 
NOTE: Never translate an empty string, _(""), as this causes the translation 
system to output translation engine information and NOT a blank string as 
some may expect.
 
Now that the code is MENU button enabled we need to code the skin to match.  
There are two ways a skin designer may choose to display the action buttons.  
They may wish to use a graphical image or they may choose to use a text 
based representation.
 
Here is a skin fragment that supports the code above to display a graphical 
MENU button:
 
<screen name="TemplateButtonMenu">
<widget source="key_menu" render="Pixmap" \
pixmap="buttons/button_menu.png" position="0,0" \
size="50,30" alphatest="blend" conditional="key_menu" \
transparent="1">
  <convert type="ConditionalShowHide" />
  </widget>
</screen>
 
In this example the widget checks if the variable "key_menu" is defined in 
this screen via the "conditional" attribute.  If "key_menu" is defined and 
not blank the image "buttons/button_menu.png" is displayed on the screen.
 
Here is a skin fragment that supports the code above to display a textural 
MENU button:
 
<screen name="TemplateButtonMenu">
<widget source="key_menu" render="Label" position="0,0" \
size="50,30" backgroundColor="ButtonBackground" \
font="ButtonFont;20" foregroundColor="ButtonText" \
halign="center" conditional="key_menu" transparent="1" \
valign="center" zPosition="+1" />
</screen>
 
This works the same way as the previous example except that instead of an 
image being displayed on the screen the translated text defined in the Python 
code is displayed on the screen.
 
CONCLUSION:
===========
 
For all the Enigma2 builds there is a significant legacy of code and skins 
that needs to be preserved and protected. The proposal outlined what I 
believe to be a conservative approach to making a significant but beneficial 
change in unifying and standardising the display of action and colour buttons 
across the Enigma2 UI.
 
---END---

 
Regards,
Ian.

Hi Nautilus7,

Nice Guide IanSav!

 

Regarding setText usage... Is 

setText()

 and 

setText("")

 exactly the same?

No, these are NOT the same. The first sets a null value while the second sets a blank string value.  While I suspect that this will work, it is not my intention.  The .setText() method should be dealing with strings so it should always be given a string as an argument.  This is an error in the document.  I have corrected the code sample to be .setText("") and this will be what I end up submitting to the doc directory in the repository.

Thank you for pointing out my error.

Regards,

Ian.

Hi,
 
This thread has been quiet for a while so I thought I would take this opportunity to post a document I am proposing to add to the doc directory to assist code and skin writers in using colour and action buttons in Enigma2.
 

Proposal for Standardised and Uniform Buttons in Enigma2
--------------------------------------------------------

Written by IanSav - 12-Feb-2018
Updated by IanSav - 13-Feb-2018

INTRODUCTION:
=============

Enigma2 is a massive open source project that has many contributors and 
add-ons.  Over time a number of approaches to performing common tasks have 
evolved.  This document proposes to nominate some conventions that can be 
adopted by all developers, contributors and skin authors to ensure that 
everyone can work independently but still achieve results that work together 
interchangeably.

The purpose of this document is to propose some standard variable names 
together with code and skin coding conventions to make the task of creating 
code that works more universally with skins easier.

Button names should be drawn from the current button definitions in 
"keyids.py".  The names used should be the lower-case version of the button 
names in this file.  For example, if you wish to define a button for the RED 
button on the remote control then use a variable name of "key_red".  In 
Enigma2 the four colour buttons should be named "key_red", "key_green", 
"key_yellow" and "key_blue".

As an example, let us look at how the red button should be defined in the 
Python code and how it can be rendered in a skin.

COLOUR BUTTONS:
===============

In the Python code to define a RED button to be available in the skin simply 
add the following to your code:

	from Components.Sources.StaticText import StaticText

	self["key_red"] = StaticText(_("Cancel"))

The text should be language translated with the _("text") syntax.  The text 
itself should be as short as practical but clear enough to convey the 
meaning of the button.

During the execution of the code the meaning of the button can easily be 
changed by using the .setText() method.  For example:

	self["key_red"].setText(_("Close")

If you want to temporarily suppress the display of the button use the 
following syntax:

	self["key_red"].setText()

NOTE: Never translate an empty string, _(""), as this causes the translation 
system to output translation engine information and NOT a blank string as 
some may expect.

Now that the code is RED button enabled we need to code the skin to match.  
Here is a skin fragment that supports the code above:

	<screen name="TemplateButtonRed">
		<widget source="key_red" render="Pixmap" \
			pixmap="buttons/button_red.png" position="10,10" \
			size="200,30" alphatest="blend" conditional="key_red" \
			transparent="1">
 			<convert type="ConditionalShowHide" />
 		</widget>
		<widget source="key_red" render="Label" position="10,10" \
			size="200,30" backgroundColor="ButtonRed" \
			font="ButtonFont;20" foregroundColor="ButtonText" \
			halign="center" conditional="key_red" transparent="1" \
			valign="center" zPosition="+1" />
	</screen>

The first widget checks if the variable "key_red" is defined in this screen 
via the "conditional" attribute.  If "key_red" is defined and not blank the 
image "buttons/button_red.png" is displayed on the screen.  The next widget 
also checks for the existence of "key_red" and then displays the button text 
over the image background.  Please note that a button image background is 
common but it is NOT required.  This is a design choice available to the 
skin author.

This sample would work well if all the code in Enigma2 was uniform and 
co-ordinated.  Unfortunately, we aren't there yet.  A more real-world example 
of how to define the button in a skin would be:

	<screen name="TemplateButtonRed">
		<ePixmap pixmap="buttons/button_red.png" position="10,10" \
			size="200,30" alphatest="blend" \
			objectTypes="key_red,Button,Label" transparent="1" />
		<widget source="key_red" render="Pixmap" \
			pixmap="buttons/button_red.png" position="10,10" \
			size="200,30" alphatest="blend" \
			objectTypes="key_red,StaticText" transparent="1">
 			<convert type="ConditionalShowHide" />
 		</widget>
		<widget name="key_red" position="10,10" size="200,30" \
			backgroundColor="ButtonRed" font="ButtonFont;20" \
			foregroundColor="ButtonText" halign="center" \
			objectTypes="key_red,Button,Label" transparent="1" \
			valign="center" zPosition="+1" />
		<widget source="key_red" render="Label" position="10,10" \
			size="200,30" backgroundColor="ButtonRed" \
			font="ButtonFont;20" foregroundColor="ButtonText" \
			halign="center" objectTypes="key_red,StaticText" \
			transparent="1" valign="center" zPosition="+1" />
	</screen>

The difference here is that the button background image and the button 
text is defined twice.  This allows all legacy code that uses either 
Button(), Label() or StaticText() objects to define the code will still 
work in this proposed skin fragment.  The data from each of the object 
types is displayed overlapped on the screen.  To make this work without 
actually overlapping the data recent builds of OpenViX, OpenPLi and 
Beyonwiz firmware have added a new attribute to the skin parser.  This 
new attribute is "objectTypes".

The "objectTypes" attribute has a value consisting of a comma separated list 
of keywords.  Note that spaces around the comma(s) are NOT permitted.  The 
first value in the list must be the variable being checked, in this case 
"key_red".  This item is mandatory.  The following values are object type 
definitions of which this variable can be defined for this widget to be 
used.  The list can have zero or more object types listed.

The first value, the variable name, is processed in the same way as the 
conditional attribute.  If the variable is defined in the code then this 
screen widget is enabled and available for use.  If the variable is not 
defined in the code then this widget is ignored.

The following values arguments are a list of object types, like Button, 
Label or StaticText, the variable name's definition type is checked against 
the supplied list.  If the variable is not defined by one of the types in 
the list then that widget is ignored.  If there is a type match then the 
widget is enabled and available for use.  If no object types are listed then 
the "objectTypes" attribute works exactly the same as the "conditional" 
attribute.

IMPORTANT NOTE: The latter form of the skin XML code should be used to 
maintain backward compatibility with all existing Python code.  At some 
point in the future when all code is updated to support and comply with 
this proposal then the former, and simpler, version of the skin definition 
can be used as backward compatibility would no longer be an issue.

ACTION BUTTONS:
===============

Just like the colour buttons there are a number of standard action or 
functional buttons used.  For example, MENU, INFO, TEXT, HELP etc. 
Typically, these buttons are manually added / defined by skin writers 
in the various screens for which they are used.  This requirement places 
a heavy burden on skin writers who have to explore the Python code to 
determine when the various action buttons are defined and available for 
use.  If the buttons are defined then there should be definitions for those 
buttons in their skin.

As with the colour buttons it is quite easy to automate the inclusion of 
these standard action buttons in both the Python code and skin.

Let us use the example of the MENU button on the remote control let us look 
at how the red button should be defined in the Python code and how it can be 
rendered in a skin.

The Python code is exactly the same as that used by the colour button 
example above.  In the Python code to define a MENU button to be available 
in the skin simply add the following to your code:

	from Components.Sources.StaticText import StaticText

	self["key_menu"] = StaticText(_("MENU"))

The text for each action button should be language translated with the 
_("text") syntax.  The text itself should be as short as practical but clear 
enough to convey the meaning of the button.

If you want to temporarily suppress the display of the button use the 
following syntax:

	self["key_menu"].setText()

NOTE: Never translate an empty string, _(""), as this causes the translation 
system to output translation engine information and NOT a blank string as 
some may expect.

Now that the code is MENU button enabled we need to code the skin to match.  
There are two ways a skin designer may choose to display the action buttons.  
They may wish to use a graphical image or they may choose to use a textural 
representation.

Here is a skin fragment that supports the code above to display a graphical 
MENU button:

	<screen name="TemplateButtonMenu">
		<widget source="key_menu" render="Pixmap" \
			pixmap="buttons/button_menu.png" position="0,0" \
			size="50,30" alphatest="blend" conditional="key_menu" \
			transparent="1">
 			<convert type="ConditionalShowHide" />
 		</widget>
	</screen>

In this example the widget checks if the variable "key_menu" is defined in 
this screen via the "conditional" attribute.  If "key_menu" is defined and 
not blank the image "buttons/button_menu.png" is displayed on the screen.

Here is a skin fragment that supports the code above to display a textural 
MENU button:

	<screen name="TemplateButtonMenu">
		<widget source="key_menu" render="Label" position="0,0" \
			size="50,30" backgroundColor="ButtonBackground" \
			font="ButtonFont;20" foregroundColor="ButtonText" \
			halign="center" conditional="key_menu" transparent="1" \
			valign="center" zPosition="+1" />
	</screen>

This works the same way as the previous example except that instead of an 
image being displayed on the screen the translated text defined in the Python 
code is displayed on the screen.

CONCLUSION:
===========

For all the Enigma2 builds there is a significant legacy of code and skins 
that needs to be preserved and protected. The proposal outlined what I 
believe to be a conservative approach to making a significant but beneficial 
change in unifying and standardising the display of action and colour buttons 
across the Enigma2 UI.

---END---

What do people think?

Regards,
Ian.

Hi,

I am exploring writing some code to try and make all StaticText(), Label() and Button() objects automatically populate both the "name=" and "source-" widgets.  If I can get this working All code and all skins can be made to keep working while we all work on cleaning up both the code and skins.

My concept is that why do Python coders need to think about, decide or force a coding style for skinners.  That is, why differentiate the StaticText(), Label() and Button() objects.  Each of these objects is simply trying to display some text on the UI.  Similarly skinners should be able to use both "name=" and "source=" widgets interchangeably.  If they want a simple text display use the "name=" form widget.  If they want to feed the text through some converters, like ConditionalShowHide, TextCase, etc then use the "source=" style widget.

If this concept is acceptable then all three of StaticText(), Label() and Button() objects can be condensed down to a single object.  The process of creating the pipeline for the converter chain should be moved to skin.py or somewhere similarly closer to the actual display process.  Thus, for any text data object the skin.py process can prepare both static and pipeline data structures to feed both the "name=" and "source=" widgets as required or desired by the skinner.

By the nature of this concept proposal all legacy skins will become supported and workable moving into the future.  The skins can be optimised and improved, if required, but they should work as is.  Similarly all Python code can slowly be cleaned up to simply use a single object for all text displays.  Let us say the Label() becomes the chosen object type then all occurrences of StaticText() and Button() can be changed to Label() WITHOUT causing any issues, or forcing any changes, to all existing skins.  Once all StaticText() and Button() objects are renamed then all the old code supporting these deprecated objects can be removed from Enigma2.  This will simplify and clean up the code and make it easier for developers to write future code.  (Instead of guessing which object to use there will only be one and it will work, transparently, with both "name=" and "source=" widgets.)

This area of code is not something I know or understand well.  I am trying to work out how the code works so I can try and develop the code changes required to support the concept above.  If people understand and agree with my proposal and want to code the solution I would welcome the effort and won't mind if my code never gets finished or accepted (assuming I work out how to code it).  The important objective is that we have a clean and compatible solution with which we can all move forward. 

What do people think?

Regards,

Ian.

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.