465 replies to this topic

[littlesat]

I fully agree... but it is hart to solve it as when we solve it all 'not under our controlled' skins are fully incomparable...... All skins need to change from name= to source= on all screens. And not actually only skins. Also (3rd party) plugins.

The level we have it know is better then it was - but it is still a compromise between 'odd and eval'... at least all color button stuff are now controlled by python code if they should appear or not (based on the dictionary key name and class type), with one single kind of templates within the skin with just a small impact on the existing skins and plugins...

Edited by littlesat, 31 January 2018 - 13:38.

[nautilus7]

Why did you closed https://github.com/O...igma2/pull/1236 ?

 

This is similar to what you did some days ago with osd3dsetup plugin, as I explain in the comments.

[littlesat]

Sorry I thought I merged it... looks like I closed it by accident.

Edited by littlesat, 31 January 2018 - 15:10.

[nautilus7]

OK, thanks. Don't forget to merge this https://github.com/l...-PLiHD/pull/570 to fix the skin as well.

[littlesat]

Done.

[IanSav]

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.

[nautilus7]

!00% with you. Good luck.

[Rob van der Does]

 but it is hart to solve it as when we solve it all 'not under our controlled' skins are fully incomparable...... All skins need to change from name= to source= on all screens. And not actually only skins. Also (3rd party) plugins.

That's why new skin-code should be backwards compatible.

 

The functionality is already 95% perfect and now you can have a fully automatic button bar.

Only for the color-buttons. Should also work for commonly used buttons like Menu, Info, Text.

[Rob van der Does]

.........
What do people think?
 
Regards,
Ian.

Not being a coder, but just a skinner: this looks fine to me.
Especially the 'backwards compatible' part of such a change.

But I do indeed realize: easy saying for me, as I won't have to invent a single line of code

[nautilus7]

@littlesat, a commit you did some days ago in the "HarddiskSetup" is totally wrong. Look here: https://github.com/O...ma2/issues/1241

[littlesat]

Should also work for commonly used buttons like Menu, Info, Text.

 

Step 2... we (or probably you) can check if we can simply switch to a dictionary key check for these? Note key_menu and so on should exist in python code...

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

[IanSav]

Hi Littlesat,

 

Should also work for commonly used buttons like Menu, Info, Text.

 

Step 2... we (or probably you) can check if we can simply switch to a dictionary key check for these? Note key_menu and so on should exist in python code...

 

If people don't want to add a dictionary item like self["key_menu"] = Label(_("MENU")) to their code to control the other buttons it *MAY* be possible to automatically trigger these buttons by looking at the current ActionMap to see what buttons are being processed.

 

I don't know if this will be easy or even possible but i thought it worth putting the idea on the table.

 

Regards,

Ian.

[MCelliotG]

Quick question! Are the new buttons changes incompatible with the classic skin format? Will the screens begin to crash now?

Any examples on how we can write the new template on a skin.xml?

[nautilus7]

No, they are not. Changes are required to a few screens that the button names changed. For example few screens used a button named "cancel" and this changed to "key_red".

 

 

 

If you want to automate your code and not have to think about buttons again, you can use the new feature. Look here how to use it: https://github.com/l...mplates.xml#L87

 

If you don't use png icons for your buttons, you can just put something like the following into your skin templates, and remove all buttons from each screen you have.

    <screen name="Buttons">
        <widget objectTypes="key_red,Button,Label" name="key_red" position="0,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_green,Label,Button" name="key_green" position="320,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_yellow,Label,Button" name="key_yellow" position="640,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_blue,Label,Button" name="key_blue" position="960,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>

        <widget objectTypes="key_red,StaticText" source="key_red" render="Label" position="0,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_green,StaticText" source="key_green" render="Label" position="320,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_yellow,StaticText" source="key_yellow" render="Label" position="640,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
        <widget objectTypes="key_blue,StaticText" source="key_blue" render="Label" position="960,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
    </screen>

Edited by nautilus, 1 February 2018 - 00:37.

[MCelliotG]

So if I want to create a template for any reason that includes three buttons all I do is create a new template and remove one of the objectypes that I don't want?

For instance

<screen name="RGYButtons">
<widget objectTypes="key_red,Button,Label" name="key_red" position="0,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
<widget objectTypes="key_green,Label,Button" name="key_green" position="320,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
<widget objectTypes="key_yellow,Label,Button" name="key_yellow" position="640,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>

<widget objectTypes="key_red,StaticText" source="key_red" render="Label" position="0,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
<widget objectTypes="key_green,StaticText" source="key_green" render="Label" position="320,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
<widget objectTypes="key_yellow,StaticText" source="key_yellow" render="Label" position="640,810" size="320,70" backgroundColor="transpBA" font="Button" halign="center" valign="center" zPosition="1" transparent="1"/>
</screen>

or that is not necessary anymore? Because what I see now is only the text of the buttons and not the pngs! How can we make these conditional, when no text is given then the png won't appear either?

[nautilus7]

The screens that have new button names/styles are "HarddiskSetup", "HarddiskSelection", "TimerEntry/List/Edit", "Satfinder", "Hotkey", "FastScan", "Osd3dSetup". I think these are all.

 

These had "problems" anyway, from the point of view, that required special buttons anyway. Now they use the common "key_red", "key_green", "key_yellow", "key_blue" naming scheme.

[nautilus7]

No, you will create one button template, containing all 4 buttons. And you will put it into your basic screen template. Then you can use this template for creating any screen you want, without caring how many it actually has.

 

The button will show in a conditional way, without any debug errors.

 

 

EDIT: For conditional pngs, you have to deal on a per screen basis. afaik. Because, conditional pngs with buttons, don't work for all types of buttons. This is what I asked a few posts above.

Edited by nautilus, 1 February 2018 - 00:49.

[MCelliotG]

Could something like this work with conditional png's?

    <widget objectTypes="key_red,Button,Label"  render="Pixmap" pixmap="GlamourAuraFHD2/buttons/aura_red.png" position="515,425" size="180,180" transparent="1" alphatest="on" zPosition="5">
      <convert type="ConditionalShowHide" />
    </widget>

[nautilus7]

In skin-PliHD this is how littlesat did it: 

  <screen name="ButtonRed">
    <widget objectTypes="key_red,StaticText" source="key_red" render="Pixmap" pixmap="PLi-FullHD/buttons/red.png" position="192,1032" size="34,34" zPosition="1" alphatest="blend">
      <convert type="ConditionalShowHide"/>
    </widget>
    <ePixmap objectTypes="key_red,Button,Label" pixmap="PLi-FullHD/buttons/red.png" position="192,1032" size="34,34" zPosition="1" alphatest="blend"/>
  </screen>

As far I understand, the conditional png only works with StaticText() buttons, but this is not something new.

 

You only need to fix the specific screens that I mentioned on post 276.

 

Anything more is about simplifying your code and including your buttons into your templates, instead of every screen separately, and automate the new screen creation process.

Edited by nautilus, 1 February 2018 - 01:14.

[MCelliotG]

OK, got it! I am going to try it on my skin now, presumably only OpenPLI has these changes as of yet!