998 replies to this topic

[littlesat]

We only look in two folders and not scan many....
Long time ago Oe-a was first with 1920x1080 skins with if skin is true hd then do something else hardcoded in the code... we did avoid that years ago... and then we also defined that default pictures could be overwritten by the skin with a default_skin folder within the skin... I also think we should keep that mechanism.

Edited by littlesat, 25 August 2018 - 19:54.

[Taapat]

The next question.

What means "Title should only be used for screen titles!"? https://github.com/O...KeyBoard.py#L41

For example, I'm in my plugin youtube use the title to display the text there: https://github.com/T...beSearch.py#L21

In the header (or prompt after the changes) I am displaying suggestions.

Now it's no longer possible use the title because you have removed the self.setTitle .

 

Sorry, i made a mistake. The title was also fixed before, and it really does not matter whether it's set in a python file or in a skin file.

[Rob van der Does]

We only look in two folders and not scan many....
Long time ago Oe-a was first with 1920x1080 skins with if skin is true hd then do something else hardcoded in the code... we did avoid that years ago... and then we also defined that default pictures could be overwritten by the skin with a default_skin folder within the skin... I also think we should keep that mechanism.

As I told you many times before: there is no such thing as an OE-A image.

It was ViX that supplied the very first 1080-skin, not 'OE-A'.

And for images the ViX skin-engine looks at two places: the active skin folder is the first folder that's being looked into (so the path in the skin is only something like "pixmap="infobar/ico_txt_on.png"; this saves a lot of code in skins). If an image is not in there, it looks in the default E2 skin (the one in "usr/share/enigma2/skin_default").

[IanSav]

Hi,

 

Building on what Rob has correctly described for other images like OpenViX and Beyonwiz there is a new issue looming.  Now that we have 4K boxes it won't be long before we start to get 4K skins.  (Not that I think they are necessary, but I also think that many FHD skins are also overkill. )  We need to pre-empt these issues and come up with a better way of handling appropriate resolution image location in skins.

 

Following on from Rob's example we need a way to find images not only in the current skin but also from a common library of skin elements.  That is why on other images we look for the image path used in the skin within the current skin and then, if the image is not found, we look in the generic skin_default that also acts as a complete fall back skin if the selected skin can't load.

 

This was fine in the early days when there were only 720 resolution skins.  Now that we have 1080 and 720 skins there is an issue with this simple search in that we may find images that are inappropriate the the current operating resolution.  (This is a problem for VirtualKeyBoard to find the appropriate resolution images.)  We need a way to select images that will match or be compatible with the operating skin at the current resolution.  It would be preferred to find a way that will allow future expansion without requiring a massive rewrite of existing code and skins.

 

I propose that we extend the OpenViX etc model and enhance it to include an extra step that looks in a resolution appropriate library.  Let us assume your skin is a FHD or 1920 x 1080 resolution.  If so the search order should be, using Rob's example:

• Look in the current skin "/usr/share/enigma2/<skin>/infobar/ico_txt_on.png" (where "<skin>" is the name of the current skin).
• Look in the resolution appropriate library "/usr/share/enigma2/skin_1080/infobar/ico_txt_on.png" (where "skin_1080" is the proposed name for the 1920 x 1080 resolution images).
• Look in the fall back skin "/usr/share/enigma2/skin_default/infobar/ico_txt_on.png" (where "skin_default" is the fall back skin and the library of 1280 x 720 resolution images).

The first image that is found along the search path should be used.  The "/usr/share/enigma2/skin_default" is and should remain a 1280 x 720 resolution skin to be a safe fall back for ALL boxes. The library image folders would follow the form of "/usr/share/enigma2/skin_<resolution>" where resolution could be 1080, 2160, 4320, etc.  There is no need for a 720 directory as the existing "skin_default" would serve that purpose.

 

Having proposed the search protocol the next item is where should it be implemented.  I think the natural location is in the evaluation of the "SCOPE_CURRENT_SKIN" value.  This is a simple change that would allow all images to be able to fine tune the search algorithm to suit their specific needs WITHOUT requiring complicated changes to the Python and/or skin XML code.

 

To maximise legacy compatibility with existing OpenPLi skins the revised "SCOPE_CURRENT_SKIN" evaluation can look for any hard coded "skin_default/" image requests and strip this off the image path and then use the new search system to find the best / most appropriate image.

 

@Rob: Does this match your thoughts?

 

@Everyone: Does this explain why I coded VirtualKeyBoard in the way that I did?  On OpenViX and Beyonwiz the images are found by the search and the skin developer is none the wiser.

 

This proposal does away with the ridiculously long image paths (/usr/share/enigma2/<skin>/skin_default/infobar/ico_txt_on.png" that currently infest OpenPLi skins.  This proposal will also allow users the share skin image elements among skins reducing image duplication as raised earlier in this thread.  The proposal is also future looking and will cope with current and future skin resolutions (1280 x 720, 1920 x 1080, 3840 x 2160, 7680 x 4320, etc)

 

Have I missed anything?  Can anyone see any issues with my proposal?  Should we give it a try?

 

Regards,

Ian.

 

[Taapat]

I think you missed the most important thing.

You have already implemented a path that calls GSOD in the hope that the SCOPE_CURRENT_SKIN logic will be changed on OpenPLi.

I think, that until nothing has changed in SCOPE_CURRENT_SKIN, this GSOD must be fixed and need to change the path in virtual keybord.

[IanSav]

Hi Taapat,

 

I am not "causing" the crash.  I am a victim of people not following my instructions.  I will take your comment on board and see about hardening the code.

 

Mind you changing Directories.py to fix SCOPE_CURRENT_SKIN is probably just as easy and will have further reaching benefits.

 

Regards,

Ian.

[littlesat]

The issue here is vix did something with a fork of openpli and had different thoughts then we have here and somehow never merged things back and compromise. Still both methods are good...
Now we can do different things..
1. Keep it as is and deviate the vk code
2. Change the skin stuff as vix is doing it
3. Change the picture scan so it can understand to both methods.

Maybe we should go for 3... this is the most compatible and flexible method... and also vix (and other oe-a images) can adapt...

[IanSav]

Hi,

 

I suspect that I have not been understanding / comprehending some of the comments being made to me.  After I posted my last reply to Taapat I thought about the situation and realised that there are two problems.

 

First is the problem that VirtualKeyBoard crashes if the "vkey_sel.png" image is not found.  I have now hardened the code to protect against this.  If fact ALL the VirtualKeyBoard images can now be missing and the code will NOT crash.  It won't look correct but it won't crash!

 

The second problem is locating the image files so that they can be shared by skins within an image / build and also so that coders can make safe assumptions about how to write their code and expect the required images to be found on different images.  (Very important for plugins!)

 

I have fixed the crash issue now to focus on making images easier to find.

 

Regards,

Ian.

[littlesat]

You do not need to change the code for it when we ensure the pictures is always there via the skin_default directory... when you arrange in your code that the size is auto adjusting (like we do for picons) we can just put the image in default_skin in e2 and totally remove them from the skin... when a skin wants to put totally different pictures they can overrule via an own skin_defaukt with the skin. All pictures that are mandatory should be in skin_default!

[IanSav]

Hi Taapat,

 

Why have you changed my function name?  This function is triggered by more than the OK button.  I chose the name carefully to reflect that fact.  In you commit note you say you made the change to keep compatibility.  What compatibility have I broken in this code?

 

The function name you changed broke my build / test system! 

 

I will rebuild my development system to address the change so I can put in the crash fix but in future please discuss changes in my active development code before making changes.

 

Regards,

Ian.

[IanSav]

Hi Littlesat,

 

You do not need to change the code for it when we ensure the pictures is always there via the skin_default directory... when you arrange in your code that the size is auto adjusting (like we do for picons) we can just put the image in default_skin in e2 and totally remove them from the skin... when a skin wants to put totally different pictures they can overrule via an own skin_defaukt with the skin. All pictures that are mandatory should be in skin_default!

 

Can you please provide a detailed example on how this works.  Use an example like that provided by Rob.

 

Regards,

Ian.

[athoik]

Why not use svg for default skin?

So you could have one set of "images" and use what ever resolution you like.

[IanSav]

Hi Athoik,

 

Why not use svg for default skin?

So you could have one set of "images" and use what ever resolution you like.

 

Does Enigma2 support SVG images, that is, does it have a SVG renderer?  I didn't think it did.

 

Regards,

Ian.

Edited by IanSav, 26 August 2018 - 10:40.

[athoik]

No it doesn't (yet)

But why not discuss how it should be fixed properly?

I guess we need an svg rendered, will add it as #1 priority for next major release

[zeros]

The file from blzr in post #431
https://forums.openp...-22#entry924423
(Screenshot on post #427)
is correct for Estonian SMS Type keyboard. Sorry for the delayed answer, but I wanted to check this out also with my box. So I confirm, it is OK and it could be added!

Edited by zeros, 26 August 2018 - 11:07.

[Taapat]

Hi Taapat,

 

Why have you changed my function name?  This function is triggered by more than the OK button.  I chose the name carefully to reflect that fact.  In you commit note you say you made the change to keep compatibility.  What compatibility have I broken in this code?

 

The function name you changed broke my build / test system! 

 

I will rebuild my development system to address the change so I can put in the crash fix but in future please discuss changes in my active development code before making changes.

 

Regards,

Ian.

 

Why do you want to others follow your changes in the enigma, but you do not do it yourself?

 

The reason I already wrote in commit.

I am using this feature in my plugin and maybe someone else uses it. https://github.com/T...beSearch.py#L32

And I want to let my plugin use it the same way as before, on all, not just on your images.

 

I already added an unnecessary code to keep up compatibility for "promt", which could also be unchanged: https://github.com/T...5a702bafecae325

 

Because if resolve the GSOD problem with images, change the "promt" back to the "header", in the HD skins should not be changed anything.

Now, for example, it's not possible to use the same skin on release-6.2 and on develop.

[IanSav]

Hi Taapat,

 

My point is you changed something that I was in the middle of editing.  Couldn't you have waited until I submitted the fix that I told everyone I was coding?  I spent quite a while trying to find how I broke the code when I first filed the pull request and there were unexpected differences.  Like everyone I sometimes make mistakes I am very careful to test everything and make sure that all the code is consistent and cross checks within by test and build system.  This unexpected change completely threw everything out of sync.

 

As for the new method name, I think it is a bad choice.  The function is triggered by more than OK.  In fact the keymap can be changed so that OK has nothing to do with that function.  It is the keymap that links buttons to functions and not the code.  I try to write my code so that it is durable and still makes sense long after it was written.  This change is contrary to that philosophy.  Just because your plugin uses other names doesn't imply that my code must use your names.  All my code is internally consistent.  You have broken that.

 

I will resist the urge to revert the change but I will ask you if you put as much thought into the function name as I had done?

 

Regards,

Ian.

Edited by IanSav, 26 August 2018 - 11:47.

[littlesat]

Why not make it in the code that it doesn’t care anymore where these pictures are... vix adapt it and everyone happy...

Edited by littlesat, 26 August 2018 - 11:59.

[IanSav]

Hi Littlesat,

 

You haven't posted the OpenPLi example in the same format that Rob and I posted so that we can compare notes.

 

When Pull Request #1694 is merged the crash issue will be gone.

 

Regards,

Ian.

[ims]

Hi Ian,

 

It would be a big problem for you - until it is done some "complex" intergalactic solution - use for this png paths something as ?

import os
prefix = 'skin_default' if os.path.exists('/usr/share/enigma2/skin_default') else 'buttons'
self.key_bg = LoadPixmap(path=resolveFilename(SCOPE_CURRENT_SKIN, "%s/vkey_bg.png" % prefix))
...

then it will works for Pli and for other images too.