998 replies to this topic

[Pr2]

If you want to know what happens during build you can check my script:

 

https://github.com/O.../updateallpo.sh

 

It does exactly what is performed during building the po and pot files.

For the xml file the build process or my script is calling this python file:

https://github.com/O...op/po/xml2po.py

 

If you have some doubt, before building you need to use:

 

./configure --with-po

 

Then start the normal build process.

[Huevos]

@PR2, what I am trying to explain is that the string for translation comes from the repo being built. I doesn't come from other repos. If it did it would be a hack.

[IanSav]

Hi Littlesat,
 

On all other locations the color parcing is done in hex... so I don’t understand that issue...

I think I am pushing the boundaries of what the parameters were originally coded to do.  The code in skin.py specifically expects the parameters to only be of type int or float!  In reality I would like to use the skin based "#" colour codes or even better the colour names.  The parameter code should be expanded to accept all data types.  The data should then be available to the code that looks for the parameter to interpret and process the data provided by the skin.

 

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

Had Taapat talked to me about what he is doing then I could have offered a simple solution.  Rather than his hacking through my code with a huge sledgehammer, and breaking other systems, I could have used a fine scalpel and simply added:

	def okClicked(self):  # Deprecated legacy interface to new processSelect used by YouTubeVirtualKeyBoard
		self.processSelect()

The other point I am trying to make is that groping into VirtualKeyBoard in this unorthodox way is not doing what I think Taapat expects.  In VirtualKeyBoard if the user enters "BCD <PREV> A <NEXT> <BACKSPACE> then the user will see "ABC" but YouTubeVirtualKeyBoard will see "BCDA".  Is that really what is wanted?

 

Again talking to me rather that being confrontational could have had a simple fix and a potential plugin issue could be investigated.  By the way, I believe that NumericalTextInput may be a better way to capture characters being entered by the use in real time.

 

Regards,

Ian.

[IanSav]

Hi Taapat,
 

@IanSav I have never asked to do anything for me.
I am asking follow changes in sources.

No, but I did offer to help and you and investigate the problem but you ignored me.
 

But your problem is that you do not offer changes.

Rubbish, the corrections to the Polish keymap were done by someone else and fully accepted by me. They submitted the change and explained exactly what they did and why. They simply corrected a mistake and made no changes that broke other things.  Your changes broke things.
 

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

Yes, if those changes are ill considered and break other things they will be reverted. This can happens in any repository at any time.  If the commit notes provided accurate information of exactly what was broken and why them much of what followed could have been avoided.  Similarly adding me as a reviewer when changing code I recently wrote and am still tweaking to address teething problems would have helped alert me to problems.  Discussing the problems here would have also resulted in the fixes you wanted.  You chose to not talk to me an any productive way.  That is not my fault.
 

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

I am no GIT expert but I have no problems with day to day GIT usage. However OpenPLi is NOT the master repository for my work. I make pull requests here because, to my knowledge, no-one from OpenPLi ever fetches code from other repositories.

 

You need to remember that I actively code for three images.  I am trying to offer compatible improvements to all those images without creating merge problems between them.  It is not easy.  Poorly considered and ill conceived changes only make the job even more difficult.

 

Regards,

Ian.

[Taapat]

If you used a cherry pick then there would be no problem.

But I see that git is a problem for you.

You change the files and it is wrong if you maintain multiple imiages.

I see that others have also paid attention to your mistakes: https://github.com/O...65f81d863560dac

I hope that it will change your habits.

[IanSav]

Hi Taapat,

 

If you used a cherry pick then there would be no problem.

But I see that git is a problem for you.

You change the files and it is wrong if you maintain multiple imiages.

I see that others have also paid attention to your mistakes: https://github.com/O...65f81d863560dac

I hope that it will change your habits.

 

Please read what I write and not reply to things I didn't say.

 

I am interested that you think that everything I do is a mistake.  Am I doing anything right?  Don't bother answering.  I know what you will say.  "No!"

 

What a shame that many of my changes fix things and actually make Enigma2 much better for users.  I guess that is a mistake too.

 

I am happy to change habits when there is a justifiable reason to do so.  Will you be changing any of your bad habits?

 

Regards,

Ian.

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

[WanWizard]

The point I think Taapat is referring to is that you copy entire files, instead of working with diffs. This means that any change the image devs themselfs make in the file are deleted the next time you copy an update in from your local system.

 

You can only do that if you (and you only) are in full control of the file, which is this case you are not.

 

What Taapat is hinting at, and what I think must happen, is host the upstream of this in a separate repo (where you do have full control), and from which the different images can either build (if they don't want or have own changes/additions) or pull (if they do).

[Huevos]

The point I think Taapat is referring to is that you copy entire files, instead of working with diffs. This means that any change the image devs themselfs make in the file are deleted the next time you copy an update in from your local system.

No I don't think so. Ian regularly sends us PRs and they are always against the latest copy. He obviously sent those revert changes because he doesn't agree with them.

 

It is PLi's repo so they can do what they like but it is very frustrating for a developer doing a major reform on some code and someone else comes along and starts breaking it before the reform is even complete. From Taapat's changes it is clear that he doesn't understand how Ian's code works.

[littlesat]

Why making the shift colors configurable by the skin in the first place? Making too much configurable is asking for complications...

[Erik Slagter]

I don't agree. Making everything configurable (and having it working too) is a sign of good code design. It doesn't that Joe Average needs to see all the options.

[littlesat]

Not agree... a good design does not need tons of customs tweaking possibilities. In addition every thing that can be adapted makes it more complicated to get to a good code design... for a good code design you first need to set a proper scope.

In this case when changing these colors is in scope it should be in hex and not decimal.

when a skin can change the color it does not help at all... eg someone reports here the green button does not work, while with an other skin it is blue... might this feature make support more complicated? so should it be in scope in the first place? When it is just intended to get the colors in the skin style and basically they are the same I agree it should be in scope, but when it is intended to change green to blue or so then not

Edited by littlesat, 1 September 2018 - 09:23.

[IanSav]

Hi Littlesat,

 

The text font colour in VirtualKeyBoard can not be changed in the skin.  The need to specify the colours as decimal in the skin is a fault / deficiency of the code in skin.py and is outside the scope of the code for VirtualKeyBoard.

 

(The problematic code in skin.py that only allows the data in parameters to be int or float is currently being reviewed.)

 

Regards,

Ian.

[littlesat]

Wierd as on all other location of the skin.xml the colors are in hex.... but I see here the parameter part is used and it was never intended to use it for colors.

[ims]

 I see here the parameter part is used and it was never intended to use it for colors.

yes, it was never intended for hex values (colors)...

[athoik]

So add support for it?

diff --git a/skin.py b/skin.py
index e8d2f9d..5434e42 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x[1:], 16) if x[0] == "#" else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex

[littlesat]

Yes please...

[athoik]

Support for load svg in ePixmap was implemented here: https://github.com/O...740b823ac2ea0f1

So now using the following in skins should work.

<ePixmap pixmap="skin_default/buttons/green.svg" position="140,0" size="140,40" alphatest="on" />

[athoik]

This adds support for both "#ff000000" and 0xff000000. Both parsed as hex numbers with base 16.

diff --git a/skin.py b/skin.py
index e8d2f9d..3f6e357 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x.replace('#', '0x'), 16) if (x[0] == "#" or x[:2] == "0x") else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex

@IanSav, can you confirm it's ok? Or you have another, better approach?

[Huevos]

This adds support for both "#ff000000" and 0xff000000. Both parsed as hex numbers with base 16.

 

diff --git a/skin.py b/skin.py
index e8d2f9d..3f6e357 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x.replace('#', '0x'), 16) if (x[0] == "#" or x[:2] == "0x") else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex

@IanSav, can you confirm it's ok? Or you have another, better approach?

 

Is it possible to add colours to that? i.e. "red, orange, etc" like in other places in the skin.

[IanSav]

Hi Athoik,

 

This should be okay to start.

 

One small problem, we also need the preserve the data type float that also already exists in parameters.  That is, if there is a "." in the parameter try to cast the value as float.

 

Regards,

Ian.