Hi,
Updates have been submitted to the repository for wider testing and acceptance.
Regards,
Ian.
Posted 7 September 2018 - 07:29
Your changes significantly diverge from ALL the documented standards.
Posted 7 September 2018 - 08:21
I've just took a look at updated Polish layout in pull request - it's a complete mess, sorry...
none of newly added ã, é, ë, ò, ô, ù is actual Polish character, g, h and i are missing
correct layout:
"pl_PL": ( (None, None, None), (None, None, None), (u"abc\u0105\u01072ABC\u0104\u0106", u"ABC\u0104\u01062", u"abc\u0105\u01072"), (u"def\u01193DEF\u0118", u"DEF\u01183", u"def\u01193"), (u"ghi4GHI", u"GHI4", u"ghi4") (u"jkl\u01425JKL\u0141", u"JKL\u01415", u"jkl\u01425"), (u"mno\u0144\u00F36MNO\u0143\u00D3", u"MNO\u0143\u00D36", u"mno\u0144\u00F36"), (u"pqrs\u015B7PQRS\u015A", u"PQRS\u015A7", u"pqrs\u015B7"), (u"tuv8TUV", u"TUV8", u"tuv8"), (u"wxyz\u017A\u017C9WXYZ\u0179\u017B", u"WXYZ\u0179\u017B9", u"wxyz\u017A\u017C9") )
Edited by blzr, 7 September 2018 - 08:35.
Posted 7 September 2018 - 08:56
I just looked at the code in the PR...
current PL layout is correct and complete in regard of national characters, however ghi4GHI and tuv8TUV are missing (lines #119, #123)
https://github.com/O...xtInput.py#L116
Edited by blzr, 7 September 2018 - 08:56.
Posted 7 September 2018 - 09:30
Hi,
By arrow I mean the one around the OK button.
When the field an input field is pre-filled (for editing for exemple) the word is fully selected.
So I am used to press the right arrow to have the cursor at the end of the selection (to add chars at the end), today when pressing the right arrow I am at the very beginning of the word.
I need to press the left arrow to be set at the end of the string.
So I think that this should behave like this (like before):
When an edit field is pre filled, pressing the right arrow places the cursor at the end of the string.
Pressing the left arrow place the cursor at the beginning of the string.
Tested in OscamStatus plugin when editing an OScam server entry.
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 7 September 2018 - 11:40
@blzr maybe I'm wrong, but None means that is used the default (English) mapping.In your case, this is the same, and therefore there is no separate for the Polish.
yep, you're right, I missed that...
in this case, it looks that the Polish layout is ok, as it is now in repo
Posted 7 September 2018 - 13:16
Hi Guys,
The VirtualKeyBoard and NumericalTextInput code now use keymaps that are calculated. Simply looking at the code without understanding what the code is doing will not explain what will be seen on the screen. As Taapat indicated, "None" in a higher level overlay means use the data from the next lower level.
Please run the code and check it while running in your environment before submitting bug reports or feedback.
Regards,
Ian.
Posted 7 September 2018 - 13:37
Hi Pr2,
By arrow I mean the one around the OK button.
When the field an input field is pre-filled (for editing for exemple) the word is fully selected.
So I am used to press the right arrow to have the cursor at the end of the selection (to add chars at the end), today when pressing the right arrow I am at the very beginning of the word.
I need to press the left arrow to be set at the end of the string.
So I think that this should behave like this (like before):
When an edit field is pre filled, pressing the right arrow places the cursor at the end of the string.
Pressing the left arrow place the cursor at the beginning of the string.
Tested in OscamStatus plugin when editing an OScam server entry.
I don't think I am able to address these issues as yet. There are massive inconsistencies and code errors in the config.py / ConfigList.py / Setup.py code. I am well advanced in correcting and unifying the navigation and control of all screen based on this code. The reality is that VirtualKeyBoard and NumericalTextInput are actually some of the code I needed fixed and working first so that the config.py code could be corrected to work predictably.
To ease people into my code changes I thought I would publish VirtualKeyBoard.py and NumericalTextInput.py first. Unfortunately the efforts to get these two modules accepted have delayed the rest of my coding efforts by about three months. Hopefully this code is now acceptable or at least close to acceptable so I can return to the higher level code development. When it is complete you should find the UI navigation significantly more predictable and controllable.
For the record, pressing LEFT when the text field is highlighted should deselect the text and move the cursor to the left margin. Pressing RIGHT when the text field is highlighted should deselect the text and move the cursor to the right margin. If the text is not selected then LEFT and RIGHT move the cursor one character left or right respectively. PREV will jump the cursor to the left margin and NEXT will jump the cursor to the right margin. Pressing BACK and STOP will delete the character to the left of the cursor. Pressing PLAY will delete the character under the cursor. OK toggles if the text is selected or deselected. INFO toggles if new text overwrites the existing text or inserts text at the current cursor position. There are a lot more options that will become apparent when the code is released. All the button options are documented in the new HELP screens that are also coming as part of the code. I should also mention that most of these commands are also replicated onto a physical keyboard (wired or wireless) if one is connected to the receiver.
Stay tuned for more updates as the code gets closer to completion.
Regards,
Ian.
Posted 7 September 2018 - 13:43
Hi,
OK so this is a bug you are aware of since it doesn't behaves like you describe:
"Pressing RIGHT when the text field is highlighted should deselect the text and move the cursor to the right margin. "
And indeed your description is the way it should work.
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 7 September 2018 - 13:47
Hi Pr2,
Do you have any examples in the UI that don't relate to Satellites or Card Access systems? I would like to see the problem myself so I can be sure that my new code will work to fix the problem. My hardware only has DVB-T users. (No readily available satellite or cable capabilities in Australia.)
Regards,
Ian.
Posted 7 September 2018 - 15:22
Hi,
Install OScamStatus create a fake server entry then modify it. You don't need to have a running OScam to run the plugin and test.
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 7 September 2018 - 17:01
Hi,
Can all users please test the latest version of NumericalTextInput that has just been merged. I now suspect / believe that the reference document (ETSI, EU 202 130) may have been an inaccurate source of data for some of my recent changes. Please don't read the code but actually try the screen. I want to be sure that everything is correct in actual use.
If your language is not correct then please document what needs to be fixed and I will try my best to get things right. Please check your change requests carefully as I really don't want to be correcting this data for the rest of my life.
It would be appreciated if people can also confirm that their language is correct if that is now the case.
Regards,
Ian.
Edited by IanSav, 7 September 2018 - 17:02.
Posted 7 September 2018 - 17:14
none of newly added ã, é, ë, ò, ô, ù is actual Polish character
Please run the code and check it while running in your environment before submitting bug reports or feedback.
Regards,
Ian.
here you go:
please revert latest changes to pl_PL, previous version was ok
Posted 7 September 2018 - 17:54
If your language is not correct then please document what needs to be fixed and I will try my best to get things right. Please check your change requests carefully as I really don't want to be correcting this data for the rest of my life.
It would be appreciated if people can also confirm that their language is correct if that is now the case.
Regards,
Ian.
well, 'original' Pli numerical text input layouts for given languages were created by their native users, hence one could assume that they knew exactly which national characters are used in their language,
to not add / remove any 'national' characters to these old layouts might have been not the worst idea in the first place (?)
just saying...
0 members, 5 guests, 0 anonymous users