So when it starts with default_skin
Search in skinpath + default skin
Search in skinpath
Search in default.skin
When doing the same in vix everything is cross compatible...
Edited by littlesat, 26 August 2018 - 12:09.
Posted 26 August 2018 - 12:08
Edited by littlesat, 26 August 2018 - 12:09.
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Posted 26 August 2018 - 12:25
Posted 26 August 2018 - 12:28
Hi Ims,
You are missing my point. Individual code should not have to worry about the image directory structure. The module "Directories.py" was created to abstract the exact location of images. Individual code modules and plugins should not be replicating "Directories.py". Further, all the code and plugins should not be making up for deficiencies in the current "Directories.py".
Bloating all the code across Enigma2 to address the image location issue is not the best way to move forward. Like many problems with Enigma2 the issue should be fixed at its cause and not by applying band-aids where things go wrong.
In the case of "VirtualKeyBoard.py" I made a mistake by not protecting the code from crashing on missing images. This is my fault. It is an error that I didn't think would happen. It is a mistake that I have now corrected. On the other hand VirtualKeyBoard.py" should not have patch code added to help "resolveFilename" do its job and get around its deficiencies.
If everyone has to apply band-aids to correct "resolveFilename" then why keep that code? It is my proposal that "resolveFilename" be improved to provide the extra functionality that is available in other images and allow it to address the issues created by having skins that operate at different resolutions.
Am I making myself clear? Do you understand the meaning of my proposal? Please ask for clarification if there is anything you don't follow. It is important that we get this right.
Regards,
Ian.
Posted 26 August 2018 - 12:34
Or improve the skin to support .svg format so problem is solved once for all.
NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.
Wanna help with OpenPLi Translation? Please read our Wiki Information for translators
Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)
AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
Posted 26 August 2018 - 12:42
@littlesat no, it seems to me, it's already written by IanSav.Logic must be:So when it starts with skinpath/<folder>In not exist search in default_skin/<folder>In not exist search in default_skin/
Please be aware that AFAIK PLi is the only brand that uses a default skin folder within the skin folder (on top of the standard E2 default skin)..
Posted 26 August 2018 - 12:47
Hi Taapat,
@IanSav as I wrote in coomit:
Maybe the new name (your processClick) is better, but I do not think that it needs to be changed.I have not created okClicked. I only use it. And I do not see a very serious reason to change it.When you offer a change, you will remember that in this constructor as is enigma, the code can be used very differently. Not just in plugins, screens and skins that you use yourself.Therefore, I am convinced that compatibility is more important than a more precise name.
I do not fully agree with your comment. When someone writes a module of code it is important that the code be consistent and logical within itself. It should also fit well within Enigma2 as a whole. When I patch someoneelse's code I don't change structure, variables or functions trivially. I try to follow the existing style though I do try to implement PEP8 style corrections along the way. One of the reasons that Enigma2 is the mess it is now is because people don't follow styles or make changes without thinking about the bigger picture. When I completely rewrite a module of code, like I did for "VirtualKeyBoard.py" and many other modules, is when I take the opportunity to do a major cleanup and modernise.
A major example of the poor choice and use of names is in the use of "KEY_*" variable names in ConfigList.py and config.py. These variables have NOTHING to do with the "KEY_*" variables in "keyids.py"!!! Needless to say that has been changed in my rewrite of "ConfigList.py" and "config.py". This is one example of creating variables without thinking about this part of code within the Enigma2 whole.
When you changed my function name, what purpose did it serve? How did it improve the code or the readability of the code? By using the name "ok" in the function name there is now a presumed link to the OK button. This is not true or correct. I think that your change was a bad choice. The association to the OK button is in the keymap not in VirtualKeyBoard. Having engaged with you in this discussion I now believe that it is appropriate to restore the names as I originally had them. Do you have a reason for me to not use the context appropriate original names?
Regards,
Ian.
Posted 26 August 2018 - 12:49
Hi Rob,
@littlesat no, it seems to me, it's already written by IanSav.Logic must be:So when it starts with skinpath/<folder>In not exist search in default_skin/<folder>In not exist search in default_skin/
Please be aware that AFAIK PLi is the only brand that uses a default skin folder within the skin folder (on top of the standard E2 default skin)..
You have FAR more experience with Enigma2 skins than I but I believe that you are correct. OpenPLi is the odd one out in the Enigma2 world.
Regards,
Ian.
Posted 26 August 2018 - 13:04
Hi Pr2,
Or improve the skin to support .svg format so problem is solved once for all.
Are there any developers interested in making this happen?
Even if this does come to fruition I still think there will be advantage in having an improved "resolveFilename". It is certainly a fix that can be quickly implemented.
Regards,
Ian.
Posted 26 August 2018 - 13:41
Hi Athoik,
Are there any developers interested in making this happen?
Yes I am interesting adding the rendered!
That sounds great. Please keep us informed of your progress.
Please try to make the code portable to other images. This could be a valuable addition to Enigma2.
Regards,
Ian.
Posted 26 August 2018 - 14:19
@IanSav,
Of course a solution needs to be found for today skins to retrieve the proper graphics. So a "folder" based solution is needed.
I have created a feature in devtools to keep in mind the .svg idea.
https://devtools.ope....org/issues/353
Pr2
NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.
Wanna help with OpenPLi Translation? Please read our Wiki Information for translators
Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)
AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
Posted 26 August 2018 - 14:39
You have done a lot of work. But - it was better to insert code into non PLI images and to offer it PLi only.
Sorry, but create it in PLi as "backwards compatible" if it is/was backward compatible with everything, just not PLi?
A "size" error is only the result of this incompatibility. Incompatibility means that each one skin for PLi needs to have a full set of images now.
Btw - I want not to have an "eintopf" image in the future. A notice as "Please be aware that AFAIK PLi is the only brand that uses a default skin folder within the skin folder (on top of the standard E2 default skin)..." is not relevant argument for me.
Posted 26 August 2018 - 15:13
Hi Ims,
Your comment is very strange. I hear lots of complaints from OpenPLi team members that no external developers feed code back to OpenPLi. My response is to start making contributions directly to OpenPLi. What do I get in return? I get asked, in what I believe to be a derogatory tone, why are you contributing to OpenPLi!!! Is your opinion shared by others in the OpenPLi team? What about OpenPLi users?
The fact is that OpenPLi is officially or unofficially the upstream repository for many / most other Enigma2 images. By feeding contributions in here I am helping improve OpenPLi and all the images that derive code from it.
By the way, all the code I submit here is also going to OpenViX. I believe they have it in a private dev build while all the skins are being modified and tested before it goes to wider distribution.
The size error was, as I posted above, an error I made in my code! It is now fixed and has little to do with the image location discussion.
I find it odd that any attempts to suggest improvements to OpenPLi are met with such anger, frustration and resistance. You do know that there are people outside of the OpenPLi team who do have positive things to contribute? Sometimes change can be good. I certainly feel that my contributions are welcomed by at least some of the OpenPLi users.
Regards,
Ian.
Posted 26 August 2018 - 15:48
Hi Ims,
It appears that I have misunderstood the intention of your post. Sorry for the contextually inappropriate overreaction.
I still contend that the way OpenPLi handles image location management can be improved. Also, I think it can be done to maintain backwards compatibility AND be useful for other images.
Regards,
Ian.
Edited by IanSav, 26 August 2018 - 15:49.
Posted 26 August 2018 - 15:58
Edited by athoik, 26 August 2018 - 15:59.
0 members, 18 guests, 0 anonymous users