Jump to content


Photo

Language assistance requested...


  • Please log in to reply
998 replies to this topic

Re: Language assistance requested... #601 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 1 September 2018 - 13:07

@Littlesat please re-read.

 

I did not say it's necessary that the end user is able to configure everything. I said "It is a sign of a good design when it is possible" (in a technical way). I.e. no hardcoded values. Separation of code and data. If you extract all the data from your source and put it e.g. into an xml file, the end user still can't change the values, but the code is definitely better. With the added bonus that if one would like to add configuration screens for some or all of the data, it will be a piece of cake.

 

Basic programming practice, code should be minimal and not be interleaved with data, less chance for bugs to creep in.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Language assistance requested... #602 WanWizard

  • PLi® Core member
  • 70,220 posts

+1,798
Excellent

Posted 1 September 2018 - 14:18

+1 :)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Language assistance requested... #603 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 04:40

Hi Littlesat,

 

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

 

I should also say that all of this "complication" in the configuration is never shown to the user.  These options enable a skin designer to adjust the VirtualKeyBoard to suit their design.  We have to trust that coders and skin designers have enough skill and knowledge to properly use the tools provided.

 

Regards,

Ian.



Re: Language assistance requested... #604 littlesat

  • PLi® Core member
  • 57,062 posts

+698
Excellent

Posted 2 September 2018 - 06:44

But now at least someone helped hete to learn the prameter part hexadecimal Numbers..... this part was intended by IMS and me for allowing creating 1920x1080 hd skins with avoiding if resolution x then do y in python code and never designed (before) to also finetune colors... it at least triggered an improvement of the parameter section of the skin...

Edited by littlesat, 2 September 2018 - 06:48.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Language assistance requested... #605 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 07:46

Hi All,

 

I believe I have the new NumericalTextInput ready for field testing.  While the code has been completely rewritten I believe that it should still be a drop in replacement for the existing code.

 

On line 193 you will find the following code:

# locale = LOCALES.get("ru_RU", None)  # Debugging code to force a locale for testing.

If you wish to test out a locale other than your own you can uncomment this line and force any of the currently coded locales.  (This line will not be present in the final code.)

 

To test this code just drop the attached code onto the receiver as /usr/lib/enigma2/python/Tools/NumericalTextInput.py.  Remember to take a backup of NumericalTextInput.pyo.  Also remove the source file after the new pyo is build so that you won't break any future firmware updates.

 

Please give me comments, feedback and bug reports so I can get the code to be optimal before it is submitted to the repository.  Over to you...

 

Regards,

Ian.

 

Attached Files



Re: Language assistance requested... #606 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 September 2018 - 08:31

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.

 
 

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.


diff --git a/skin.py b/skin.py
index e8d2f9d..7a04779 100644
--- a/skin.py
+++ b/skin.py
@@ -225,6 +225,19 @@ def parseColor(s):
                        raise SkinError("color '%s' must be #aarrggbb or valid named color" % s)
        return gRGB(int(s[1:], 0x10))

+def parseParameter(s):
+       """This function is responsible to parse parameters in the skin, in can parse html colors, hex integers, floats, named colors and integers"""
+       if s[0] == '#':
+               return int(s[1:], 16)
+       elif s[:2] == '0x':
+                return int(s, 16)
+       elif '.' in s:
+               return float(s)
+       elif s in colorNames:
+               return colorNames[s]
+       else:
+               return int(s)
+
 def collectAttributes(skinAttributes, node, context, skin_path_prefix=None, ignore=(), filenames=frozenset(("pixmap", "pointer", "seek_pointer", "backgroundPixmap", "selectionPixmap", "sliderPixmap", "scrollbarbackgroundPixmap"))):
        # walk all attributes
        size = None
@@ -586,7 +599,7 @@ 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)
+                               parameters[name] = "," in value and map(parseParameter, value.split(",")) or parseParameter(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex

Above should parse all variants of parameters reported. Can you please report if that's ok?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #607 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 08:48

Hi Athoik,

 

Nicely done!  I will add this to me test machine ASAP.

 

For the last "else" case would it make sense to check if the parameter is not a valid int and if it is not log the error.  This would warn skin developers that they may have an error in their skin.  (Skin developers do test their skin and fix any errors reported by Enigma2?  :P)

 

I can also foresee that in the future coders may want a parameter to be a type str.  ;)

 

Regards,

Ian.



Re: Language assistance requested... #608 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 September 2018 - 09:16

Hi All,
 
I believe I have the new NumericalTextInput ready for field testing.  While the code has been completely rewritten I believe that it should still be a drop in replacement for the existing code.
 
On line 193 you will find the following code:

# locale = LOCALES.get("ru_RU", None)  # Debugging code to force a locale for testing.
If you wish to test out a locale other than your own you can uncomment this line and force any of the currently coded locales.  (This line will not be present in the final code.)
 
To test this code just drop the attached code onto the receiver as /usr/lib/enigma2/python/Tools/NumericalTextInput.py.  Remember to take a backup of NumericalTextInput.pyo.  Also remove the source file after the new pyo is build so that you won't break any future firmware updates.
 
Please give me comments, feedback and bug reports so I can get the code to be optimal before it is submitted to the repository.  Over to you...
 
Regards,
Ian.


Hi,

Here some information that you probably find useful.

1. You removed public functions from old interface (eg nextKey) that is already used under Enigma2 (lib/python/Screens/LocationBox.py). Imagine how many plugins out there might still use this function.

2. There are no doc strings

3. Why we need so many MODES? Is really all users so "advanced" users and need all those types?

4. Why we need HEXFASTLOGICAL_UPPER and HEXFASTLOGICALUPPER ? To prevent user error or developer error? It's something new so why make error at first place?

5. Why you removed UTF-8 coding? (-# -*- coding: UTF-8 -*-). Why is better to use "abc\u0101\u010D2ABC\u0100\u010C" instead of "aābcč2AĀBCČ". The \uXXXX styntax seems so weird, when utf8 supported.
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #609 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 September 2018 - 09:17

For the last "else" case would it make sense to check if the parameter is not a valid int and if it is not log the error.  This would warn skin developers that they may have an error in their skin.


It was supported already, so I didn't bother changing it.

print "[Skin] Bad parameter", ex


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #610 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 09:44

Hi Athoik,

 

 

For the last "else" case would it make sense to check if the parameter is not a valid int and if it is not log the error.  This would warn skin developers that they may have an error in their skin.


It was supported already, so I didn't bother changing it.

print "[Skin] Bad parameter", ex

 

 

You should also be able to now delete the old "paramConvert()":

def paramConvert(val):
	return float(val) if '.' in val else int(val)

Regards,

Ian.



Re: Language assistance requested... #611 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 10:14

Hi Athoik,
 

Here some information that you probably find useful.

1. You removed public functions from old interface (eg nextKey) that is already used under Enigma2 (lib/python/Screens/LocationBox.py). Imagine how many plugins out there might still use this function.


Thank you for this bug report. I will fix this ASAP.
 

2. There are no doc strings


Do you mean documentation as an instruction file in /doc? If so, that will come when the code is more stable. I don't want to keep rewriting the documentation as the test results come in.
 

3. Why we need so many MODES? Is really all users so "advanced" users and need all those types?


Every time I talked about what I was developing people kept suggesting modes that they would like. It was easy to do so I included them. This is better than leaving them out and someone duplicating this code to add the extra options later.  The idea is that coders can ask users for HEX data and the format can be presented in different ways in the UI.

  • Some people may want the "ABC" to be associated with the "2" button and "DEF" to be associated with the "3" button.
  • Some may want to save button presses so have "A" with "1", "B" with "2", "C" with "3", "D" with "4", "E" with "5" and "F" with "6".
  • Logic purists or may want "A" with "0", "B" with "1", "C" with "2", "D" with "3", "E", with "4" and "F" with "5".

Coders can have the data displayed ANY way they want WITHOUT having to code up the display.
 
For the users the big change will be that when they are asked to enter a hex value they can now only be shown valid hex characters on the UI.
 

4. Why we need HEXFASTLOGICAL_UPPER and HEXFASTLOGICALUPPER ? To prevent user error or developer error? It's something new so why make error at first place?


The extra strings are to make it easier on developers to remember the mode names. If you are suggesting that I went a bit overboard then I will agree and offer to remove some of the duplicate options. If I am to remove the duplicates I will be removing the "_" versions as most of the code uses CamelCase variable names.
 

5. Why you removed UTF-8 coding? (-# -*- coding: UTF-8 -*-). Why is better to use "abc\u0101\u010D2ABC\u0100\u010C" instead of "aābcč2AĀBCČ". The \uXXXX styntax seems so weird, when utf8 supported.


Some editors don't co-operate with UTF-* data.  I have seen minor errors creep into UTF-8 files because someone used an editor that corrupted the data.  By using unicode this risk is totally eliminated.

 

Regards,

Ian.



Re: Language assistance requested... #612 ims

  • PLi® Core member
  • 13,764 posts

+214
Excellent

Posted 2 September 2018 - 10:30

5. Why you removed UTF-8 coding? (-# -*- coding: UTF-8 -*-). Why is better to use "abc\u0101\u010D2ABC\u0100\u010C" instead of "aābcč2AĀBCČ". The \uXXXX styntax seems so weird, when utf8 supported.


Some editors don't co-operate with UTF-* data.  I have seen minor errors creep into UTF-8 files because someone used an editor that corrupted the data.  By using unicode this risk is totally eliminated.

 

Regards,

Ian.

 

Excuse me, but due several stupid editors will we suffer much worse editing? It is very, very difficult anything change in national characters in this code...


Kdo nic nedělá, nic nezkazí!

Re: Language assistance requested... #613 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 10:59

Hi Ims,

 

Excuse me, but due several stupid editors will we suffer much worse editing? It is very, very difficult anything change in national characters in this code...

 

I would rather have a more difficult editing session than having subtle corruptions in the data.  :)

 

Please remember that I am in Australia and only use English.  Not all language fonts render in all locations.  By using unicode this issue can be avoided.  This problem was significantly highlighted while I was trying to maintain code with Persian and Thai.  On the receiver I needed to switch to the DejaVu fonts to see most of the glyphs.  My PC just made a mess of the characters.

 

I think we should be conservative to ensure maximum code protection.  Please keep in mind that this data is not regularly updated.  Once a language definition is done it should not need much maintenance.

 

Regards,

Ian.



Re: Language assistance requested... #614 ims

  • PLi® Core member
  • 13,764 posts

+214
Excellent

Posted 2 September 2018 - 11:03

Understand, but looking for typo in this is horror ... ;)


Kdo nic nedělá, nic nezkazí!

Re: Language assistance requested... #615 zeros

  • PLi® Contributor
  • 1,635 posts

+61
Good

Posted 2 September 2018 - 11:19

Hi IanSav!
I tested your file in post #605
Everything is correct for the Estonian keyboard.
But I have a question about whether the font size could stick to the same?
In the new situation, the font is smaller and it is difficult to understand the letters on the screen.

Attached Files


DM920UHD DVB-S2X TRIPLE tuner + Triple M.S tuner DVB-S2X, DVB-T2/T, QboxHD, QboxHD Mini, Icecrypt T2300HD,
Qviart Lunix3 4K, Raspberry Pi 4 Model B 4GB & 8GB

Vertex 4K60 4:4:4 600MHz


Re: Language assistance requested... #616 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 11:32

Hi Ims,

 

Understand, but looking for typo in this is horror ... ;)

 

I had a copy of the UI I was testing on the TV screen.  The code in one window on my PC, https://en.wikipedia...code_characters and http://www.ltg.ed.ac.uk/~richard/utf-8.cgi in browser windows and a magnifying glass to see if I was getting the correct glyphs.  Trust me this was not fun or easy.  ;)

 

Regards,

Ian.



Re: Language assistance requested... #617 ims

  • PLi® Core member
  • 13,764 posts

+214
Excellent

Posted 2 September 2018 - 11:43

Good pages are this. You can write whole line, convert and copy/paste converted code


Edited by ims, 2 September 2018 - 11:44.

Kdo nic nedělá, nic nezkazí!

Re: Language assistance requested... #618 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 11:53

Hi Zeros,

 

I tested your file in post #605
Everything is correct for the Estonian keyboard.
But I have a question about whether the font size could stick to the same?
In the new situation, the font is smaller and it is difficult to understand the letters on the screen.

 

This is a complete surprise to me.  The code should not be doing anything with the skin or fonts.

 

Could this be an issue because of all the extra data now displayed on the "0" button?  You can test this out by editing NumericalTextInput.py and removing some of the characters from the "PUNCTUATION0" definition, restarting the GUI and checking out the screen.  If this changes the font size then the skin may not be allowing enough space for all the new characters on the "0" button.  If this is the case I can try and move some of the characters onto the "1" button.

 

Regards,

Ian.



Re: Language assistance requested... #619 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 2 September 2018 - 11:58

Hi Ims,

 

Good pages are this. You can write whole line, convert and copy/paste converted code

 

That page is FANTASTIC.  Thank you so much for the link.  That will make future language work MUCH easier.  :D

 

Regards,

Ian.



Re: Language assistance requested... #620 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 2 September 2018 - 12:46

Do you mean documentation as an instruction file in /doc? If so, that will come when the code is more stable. I don't want to keep rewriting the documentation as the test results come in.


No, I mean python doc string. Unfortunately enigma2 completely miss doc strings.

See: https://www.python.o...-is-a-docstring


For the users the big change will be that when they are asked to enter a hex value they can now only be shown valid hex characters on the UI.

 

Something like this was doing the "hex" job (the old times...).

class HexKeyBoard(VirtualKeyBoard):
        def __init__(self, session, title="", **kwargs):
                VirtualKeyBoard.__init__(self, session, title, **kwargs)
                self.skinName = "VirtualKeyBoard"
                self.keys_list = [[u"EXIT", u"1", u"2", u"3", u"4", u"5", u"6", u"7", u"8", u"9", u"0", u"BACKSPACE"],
                                        [u"OK", u"A", u"B", u"C", u"D", u"E", u"F", u"OK", u"LEFT", u"RIGHT", u"ALL", u"CLEAR"]]
                self.shiftkeys_list = []
                self.keyImages =  { "BACKSPACE": self.key_backspace, "ALL": self.key_all, "EXIT": self.key_esc,
                                        "OK": self.key_ok, "LEFT": self.key_left, "RIGHT": self.key_right, "CLEAR": self.key_clr }
                self.nextLang = None
                self.lang = None
                self["country"] = Label()

def setHexCallback(session, hex):
        print "hex:", hex

def hexmenu(session, service=None, *args, **kwargs):
         session.openWithCallback(boundFunction(setHexCallback, session), HexKeyBoard,
                 title=_("Please enter new hex:"), text="", maxSize=20, visible_width=20)

def Plugins(**kwargs):
        return [PluginDescriptor(name = "Test" , description = "Test", icon="plugin.png",
                where = [PluginDescriptor.WHERE_EXTENSIONSMENU, PluginDescriptor.WHERE_PLUGINMENU],
                fnc = hexmenu, needsRestart = False)]
Now, i really don't know if above still works, or how easy is to get a hex input with keyboard without making custom screens.

On the other hand, an example would be nice.



The extra strings are to make it easier on developers to remember the mode names. If you are suggesting that I went a bit overboard then I will agree and offer to remove some of the duplicate options. If I am to remove the duplicates I will be removing the "_" versions as most of the code uses CamelCase variable names.


Keep only what they need to remember, more options means more things to remember, so get rid of duplicates. 


Some editors don't co-operate with UTF-* data.  I have seen minor errors creep into UTF-8 files because someone used an editor that corrupted the data.  By using unicode this risk is totally eliminated.


What editor today doesn't properly handle unicode? :)

Uninstall it and use one that makes your like simpler!
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916


14 user(s) are reading this topic

0 members, 14 guests, 0 anonymous users