998 replies to this topic

[IanSav]

Hi Littlesat,

 

You proposal does not allow for substitutions to cope with different skin resolutions.  This feature may still be required even when we get SVG images.  You can't just find an image and use it particularly if you find an image in the wrong resolution first.

 

The code should also pay attention to the relative paths provided in the skin.  Many skins have multiple copies of some images that may NOT be the same.  Those skins should be cleaned up to eliminate or properly differentiate the images.

 

For performance I don't think you need to have such a complicated search plan.  I think that we only need to search in the skin relative path first and then in the resolution appropriate default path next.  If the image is not found after those two probes the the image should be classed as not found.

 

The default image folders should be "skin_default" for 1280x720 (HD) skins, "skin_default_1080" for 1920 x 1080 (FHD) skins, "skin_default_2160"  for 3840 x 2160 (4K) skins and  "skin_default_4320" for 7680 x 4320 (8K) skins.

 

Example 1:

 

skin = "PLi-FullNightHD"

resolution = 1920 x 1080
data = "/usr/share/enigma2"
image = "buttons/vkey_bg.png"

 

First look in "/usr/share/enigma2/PLi-FullNightHD/buttons/vkey_bg.png"

Next look in "/usr/share/enigma2/skin_default_1080/buttons/vkey_bg.png"

 

If the image is not in these two locations then fail.

 

Example 2:

 

skin = "OverlayHD"

resolution = 1280 x 720
data = "/usr/share/enigma2"
image = "buttons/vkey_bg.png"

 

First look in "/usr/share/enigma2/OverlayHD/buttons/vkey_bg.png"

Next look in "/usr/share/enigma2/skin_default/buttons/vkey_bg.png"

 

If the image is not in these two locations then fail.

 

Example 3:

 

skin = "PLi-FullNight4K"

resolution = 3840 x 2160
data = "/usr/share/enigma2"
image = "image.png"

 

First look in "/usr/share/enigma2/PLi-FullNightHD/image.png"

Next look in "/usr/share/enigma2/skin_default_2160/image.png"

 

If the image is not in these two locations then fail.

 

Example 4:

 

skin = "OverlayHD"

resolution = 1920 x 1080
data = "/usr/share/enigma2"
image = "image.svg"

 

First look in "/usr/share/enigma2/OverlayHD/image.svg"

Next look in "/usr/share/enigma2/skin_default/image.svg"

 

If the image is not in these two locations then fail.  In this case all .svg images don't have a resolution.  They are automatically scaled and positioned according to the "position=" and "size=" attributes so they can safely be stored in the base default skin image library.

 

Example 5:

 

skin = "PLi-FullNightHD"

resolution = 1920 x 1080
data = "/usr/share/enigma2"
image = "/tmp/image.svg"

 

Only look in "/tmp/image.svg"

 

If the image is not in this location then fail.  If the image is specified by an absolute path then no search should be performed.  Load the image as specified and fail if it is not found.

 

If any skins are disorganised or a mess then their maintainer should be encouraged and helped to clean up their skin.  If a skin has been abandoned by its author and no-one steps in to adopt the skin it should be deprecated and removed.

 

Regards,

Ian.

Edited by IanSav, 30 August 2018 - 17:39.

[zeros]

From outside skins, you may try
Full HD Glass 17 ver. 2.29
HD Glass 16 ver. 11.96
(I already tried)
If necessary, their developer could be given some hint (I can forward).

[IanSav]

Hi Zeros,

 

If skin maintainers want help to make adjustments to their skins get them to come here and ask for help.  I spent some time today helping an OpenViX skinner correct and update their skin.  The offer is open to anyone here as well.

 

By the way the person I was helping made me realise there is an error in the VirtualKeyBoard documentation.  I will submit an update shortly.

 

Regards,

Ian.

[zeros]

Thanks, that's a good idea, i'il let him know.

[athoik]

What data gUnmanagedSurface expects? Anyone knows? Or it's "enigma".

gUnmanagedsurface expects 32bit RGBA image, so it's exactly what nanosvg rasterizer creates on output

Support for loading SVG in pixmaps was implemented here:

https://github.com/O...ae5c3515934f308

(that means you can start playing with SVG!)

Enjoy

[littlesat]

Does it mean it plays animations?

 

I also did some skin picture find stuff.... It might be 'extended' later when we get the resolution there in Directory.py to add also a search on an default resolution folder.

Edited by littlesat, 30 August 2018 - 19:47.

[athoik]

Does it mean it plays animations?
 
I also did some skin picture find stuff.... It might be 'extended' later when we get the resolution there in Directory.py to add also a search on an default resolution folder.

No, nanosvg "only renders flat filled shapes".

Animation is something that svg++ and cairo might be capable to perform, but going to cairo, is not fun anymore (at least for me). Anyone volunteer?


In any case, nanosvg is great enough to "setup / test" the idea of SVG. When nanosvg is not good enough for us, we can step on.

[IanSav]

Hi Taapat,
 
If someone wants to reclass VirtualKeyBoard to do their own thing that is fine.  VirtualKeyBoard was never a character interactive input system, it is a line buffered input system.  NumericalTextInput is the appropriate control to get individual characters from the user.  It has the callback needed to know when a character has been entered.  Groping the internals of VirtualKeyBoard to do something it is not meant to do and then blaming me when changes are made that conflict with this unintended use of the code are not fair.

 

By the way, I don't believe that the YouTubeVirtualKeyBoard code is catching all the text changes that VirtualKeyBoard is capable of making.  It is only detecting when the processSelect() method is triggered.  There are other ways that the text can change that are not being detected!  Are you aware of this problem in the YouTubeVirtualKeyBoard code?

 

That aside, there is already a YouTubeVirtualKeyBoard skin.  It can use whatever skin variables are required.  I have "prompt" in VirtualKeyBoard.  YouTubeVirtualKeyBoard can have "header" or anything else desired.  I simply take the prompt text given to VirtualKeyBoard and display it.  I never reference it or manipulate it.  For YouTubeVirtualKeyBoard usage it appears that the prompt text to be dynamic.  Fair enough but don't blame me because dynamic usage is not required for VirtualKeyBoard.  This whole issue should not have occurred given an appropriate skin is available to work with the modified operation of the reclassed code.
 
Instead of renaming the YouTubeVirtualKeyBoard method to match the VirtualKeyBoard processSelect() method the VirtualKeyBoard was changed thus creating merge issues and potential problems for the other users of this code.  OpenPLi is NOT the master copy of this code.  When pull requests are made for code that is managed elsewhere it would be appropriate to add the author as a reviewer so that they can review the changes and check that they don't create issues in the master copy or for other users of the code.

 

Before I submitted the new VirtualKeyBoard code I discussed the changes in this forum and also provided samples of the code.  It is not possible for me to test all the plugins in all the repositories out there.  Having made the pull request I would have appreciated being told about the specifics of any issues rather than having the code reverted or changed without notice or discussion.  I would like to remind readers that when I found issues with the title translation in a recent code change I didn't jump in and rewrite the code I posted a report of the problem and asked the author if they wanted assistance to address the problem.  I consider this to be appropriate, respectful and courteous when working with a group of people.

 

There is an implication that there are other plugins that also grope into the insides of VirtualKeyBoard, can I please have some other examples?  I am curious if they too are trying to make VirtualKeyBoard into NumericalTextInput or in some other way trying to make VirtualKeyBoard be something else.

 

Earlier you posted:

 

You have forgotten that you are not the only developer.

You can not ignore other developers and users.

 

The fact that you have created something different in OpenViX and Beyonwiz is not an argument to break everything into OpenPLi.

 

I would respectfully point out that I don't think there are many other developers who are directly developing core code for three different images simultaneously.  When changing something in one instance of common code there is a lack of consideration that things could be broken for other developers in other images.  The OpenPLi copy of VirtualKeyBoard is not the master copy.  As much of my code as possible is written and implemented identically in OpenPLi, OpenViX and Beyonwiz.  This is deliberately done to minimise merge issues for the various repository maintainers.  The assertion that I do things differently for each image is simply wrong.

 

I strongly dispute that I have broken "everything in OpenPLi".  To my knowledge, none of the uses of VirtualKeyBoard via the normal access methods is having any issues.  The fact this case is using VirtualKeyBoard to do something that it was not intended to do is not my fault.  Not being told about the problem or being involved in discussion about problems is inappropriate.

 

I think I have made my feelings about the way this is being handled clear.  How can we work together to ensure that this situation is resolved?

 

Regards,

Ian.

 

[IanSav]

Hi Athoik,

 

(that means you can start playing with SVG!)

 

Some of us will need learn how to build and maintain SVG files first. 

 

Regards,

Ian.

[Taapat]

How can we work together to ensure that this situation is resolved?

 

Just leave the function name unchanged.

The old name also explains what this function does.

I already wrote in commit that maybe the new name is better, but I do not think that it needs to be changed.

I return the name of this function because it's not the most important thing.

 

Of course I can use the hasattr() in my plugin, but I do not want to use this hack if can not change the name of the function.

[IanSav]

Hi Taapat,

 

The current change has created merge issues.  The old name is not correct.  If you refactor code to fix it you don't keep the bits that are broken.  What about my other questions and observation?

 

What is wrong with hasattr()?  I protects against changes in other code.  It is far better than restraining code from improving.

 

Regards,

Ian.

Edited by IanSav, 31 August 2018 - 03:03.

[Taapat]

I do not see what to answer on the other questions.

 

There is only proof of what I wrote here before.

You use YouTubeVirtualKeyBoard in one way and you can not imagine that it can be used differently. Therefore, you think it should not be uset differently.

 

Here is the next proof that your philosophy is correct by breaking the title translation in the example: https://github.com/O...65f81d863560dac

 

While you ignore others, I have nothing to discuss with you.

[littlesat]

The skin color parameter should NOT be decimaal as anywhere else it is hexadecinal and in hexadecinal it is more clear an Logic as you recognize ttrrggbb... sounds like parcing should be changed... in addition you can’t change ‘wrong’ funtion names without ‘charm’ as it Will/can break stuff that uses that class... but what plug-ins does it break? When it is just one (or a few) plugin(s) we can also consider to adapt the plugin additionally so hasattr is not in scope. But this is still something that should be discussed....
From one point taapat is right. There are good intentions to change and improve thinks... but we get code without a discussion before what you are planning to do so there is no discussion in forehand...

Edited by littlesat, 31 August 2018 - 07:17.

[IanSav]

Hi Taapat,

 

I asked for examples of other code or plugins that I broke with the new VirtualKeyBoard.  None have been provided.  I indicated a potential problem with your plugin by using VirtualKeyBoard in this way but you chose to ignore the report.  I asked why changes to the code that cause me problems are not discussed with me first and I am ignored.  I explain that this code is mastered and shared elsewhere and it is implied that only OpenPLi matters.  I am trying to engage you in discussion to understand the issues and find a way forward but I am ignored or fobbed off.

 

There has been another change made to the code by another author.  While that person didn't alert me to the change it was a correction that was fully explained and documented.  That change was welcomed and has been replicated to the master and other copies.  I do not object to changes but they should be fixes or changes for the better and properly documented.  I am not a mind reader so document what you are doing and why.  Don't expect me to work hard to try and work out what the change is all about.

 

I feel that you choose to insult me, ignore me and simply tell me what to do as though I was a paid worker who is working FOR you.  I am not paid and I don't work for you.  I feel insulted and this treatment is not acceptable to me.

 

I this is your idea of co-operation and discussion then I perhaps I have nothing to discuss with you either.

 

Regards,

Ian.

[athoik]

It would be lovely to have a "meta-plugins" repo with ALL code used in PLi as submodules.

Then "grepping" that repo for "problems" caused with function renames would be easy.

Regarding using skin titles, it's nice, but how translators will find strings to translate? They have to seek on skins?

Maybe a dummy python file translations.py required, where all titles should be put there. Then generating po files will contain those.

[IanSav]

Hi Littlesat,
 

The skin color parameter should NOT be decimaal as anywhere else it is hexadecinal and in hexadecinal it is more clear an Logic as you recognize ttrrggbb... sounds like parcing should be changed...

You are absolutely correct. I was quite frustrated when someone tested the code to change some colours and the hex values didn't work.  The problem is that skin.py only accepts parameters as int or float.  I thought that the hex would be automatically converted to int.  When the fault was reported I noticed that the parameters are of type string.  When fed to int() a string of "123" is properly converted to an int.  That is, int("123") like int(123) becomes 123, but int("0x123") generates an error and does NOT convert while int(0x123) works!
 

in addition you can’t change ‘wrong’ funtion names without ‘charm’ as it Will/can break stuff that uses that class... but what plug-ins does it break? When it is just one (or a few) plugin(s) we can also consider to adapt the plugin additionally so hasattr is not in scope. But this is still something that should be discussed....

I have been trying to engage in discussions but I am being ignored. The way that VirtualKeyBoard is being misused is part of this problem.
 

From one point taapat is right. There are good intentions to change and improve thinks... but we get code without a discussion before what you are planning to do so there is no discussion in forehand...

Sorry but I DID discuss my changes in this thread before the code was submitted. I even provided samples of the code to show what I was intending. No one complained about the sample code. There was plenty of time and opportunity to discuss what I proposed.  You then asked me to submit the code to the repository for testing. I did as you suggested. The code was then changed without any discussion.  I consider that rude and unhelpful.

 

I have a suggestion to address the problem but if people don't want to talk to me I have no way to discuss the options.

 

Regards,
Ian.

[IanSav]

Hi Athoik,
 

It would be lovely to have a "meta-plugins" repo with ALL code used in PLi as submodules.

Then "grepping" that repo for "problems" caused with function renames would be easy.

Please remember that I am developing code that crosses over a number of images. However suggestions like this can very much help.
 

Regarding using skin titles, it's nice, but how translators will find strings to translate? They have to seek on skins?

I think some build systems do search the skin XML files looking to "title=" and "text=" attributes to create language translation entries in the PO files.
 

Maybe a dummy python file translations.py required, where all titles should be put there. Then generating po files will contain those.

A good design to harvest the data from skins and create such a file for all skin repositories would be a great idea.

Regards,
Ian.

[littlesat]

On all other locations the color parcing is done in hex... so I don’t understand that issue...
Indeed it would be helpfull taapat gives us an example of the plugin cullpit... but still renaming stuff in e2 is always at risk. Even when the names are not fully right you have to do it with care...

Edited by littlesat, 31 August 2018 - 08:28.

[Taapat]

@IanSav I have never asked to do anything for me.

I am asking follow changes in sources.

 

But your problem is that you do not offer changes.

You offer your files instead of changes, which revert all other changes.

 

I feel that you have problems using git, so I already asked if you have heard about "git cola".

Edited by Taapat, 31 August 2018 - 08:47.

[Huevos]

Hi Athoik,
 

It would be lovely to have a "meta-plugins" repo with ALL code used in PLi as submodules.

Then "grepping" that repo for "problems" caused with function renames would be easy.

Please remember that I am developing code that crosses over a number of images. However suggestions like this can very much help.
 

Regarding using skin titles, it's nice, but how translators will find strings to translate? They have to seek on skins?

I think some build systems do search the skin XML files looking to "title=" and "text=" attributes to create language translation entries in the PO files.
 

Maybe a dummy python file translations.py required, where all titles should be put there. Then generating po files will contain those.

A good design to harvest the data from skins and create such a file for all skin repositories would be a great idea.

Regards,
Ian.

 

I think some build systems do search the skin XML files looking to "title=" and "text=" attributes to create language translation entries in the PO files.

 

Yes we search the xml files on build and the output goes in the .po file. But that can only happen where the search is done on the same repo.

 

i.e. for the translation to appear in enigma2.po the string for translation must come from the enigma2 repo, not the skins repo.