998 replies to this topic

[littlesat]

In resolve filename with SCOPE CURRENT SKIN it should be arrange that when the picture is not found in default_skin it removes this dir and try again without the default_skin... and then first in the skin dir and then without the skin dir...
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.

[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.

[IanSav]

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.

[Taapat]

@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/

[Pr2]

Or improve the skin to support .svg format so problem is solved once for all.

[Rob van der Does]

 

@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)..

[IanSav]

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.

[IanSav]

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.

[IanSav]

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.

[athoik]

Are there any developers interested in making this happen?

Yes I am interesting adding the rendered!

[IanSav]

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.

[littlesat]

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)..

what is wrong about it?

[Pr2]

@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

[IanSav]

Hi Pr2,

 

Excellent.  When I finish adapting NumericalTextInput.py to support multiple locales properly I will look at modifying "resolveFilename" to address our immediate needs.

 

Regards,

Ian.

[ims]

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.

[IanSav]

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.

 

[ims]

Why this reaction ? I just mentioned only, that code in Pli is not bw compatible with Pli, but with other images. That's all...  no derogatory tone...

 

 

 

Edited by ims, 26 August 2018 - 15:38.

[IanSav]

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.

[athoik]

@IanSav,


Please note that international members of PLi (like me) are not native English speakers.

So sometimes we might lost in translation.

Don't be afraid of discussion, even though "it seems" like they/we are attacking you.


Enigma2 codebase is mess, taking steps to make it better is very welcomed.

Enigma2 codebase is out several years, so even small changes can cause huge errors/issues.

Enigma2 codebase is "Enigma" ...


So, keep up with the good work, I am sure that at the end all problems will be solved. That's why we have develop branch and we do not break everybody's receiver.

Edited by athoik, 26 August 2018 - 15:59.

[IanSav]

Hi Athoik,

 

Thank you for your kind words.  The level of English in here is usually so good that I often forget that English is not most people's first language.  I think you are quite correct and perhaps I have misread the intention behind the words.

 

Regards,

Ian.