998 replies to this topic

[IanSav]

Hi,

 

Updates have been submitted to the repository for wider testing and acceptance.

 

Regards,

Ian.

[Taapat]

Your changes significantly diverge from ALL the documented standards.

 

You are not right.

My changes have been made according to the proposed changes in ETSI DES 202 130: http://www.likit.lt/...i_comments.html

The difference is that this document proposes changes to the Lithuanian language with a different alphabet than Latvian. Therefore, in my changes, the letters have been changed according to the Latvian alphabet.

 

If you use my variant, then the question about the Latvian language is closed. Thx.

[blzr]

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.

[IanSav]

Hi Blzr,

 

That is quite surprising.  Did you test the code or simply look at it?

 

I am concerned that Ims's reference document is getting so many complaints and objections.

 

Regards,

Ian.

[blzr]

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.

[Pr2]

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

[Taapat]

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

Edited by Taapat, 7 September 2018 - 11:19.

[Taapat]

I am concerned that Ims's reference document is getting so many complaints and objections.

 

This is with very many documents of the European Union  .

Not everything invented by bureaucrats in Brussels is used or possible in the individual country.

[blzr]

 

@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
 

[IanSav]

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.

[IanSav]

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.

[Pr2]

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

[IanSav]

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.

[Pr2]

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

[IanSav]

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.

[blzr]

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

[blzr]

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

[IanSav]

Hi Blzr,

 

For some users there were errors.  This was a case of damned if I did and damned if I didn't.  I wasn't to know that the reference document wasn't to be trusted.  It is, after all, the reference standard!

 

Regards,

Ian.

[Rob van der Does]

Dutch VK & NK are fine now.

[IanSav]

Hi Blzr,

 

Polish has been corrected as per your instructions.

 

I will push the changes out as a pull request tomorrow.  I hope others will test the code before then and report back so that I can combine all the corrections into a single update.

 

Regards,

Ian.