Config and VirtualKeyBoard enhancements

[prl]

I am concerned about various patch kits conflicting. I would like to put all the files here so that everyone can see what I have changed and can integrate these changes into existing patch kits.

What files are involved? None of the files you mentioned conflict with any of the alpha patches for stuff I'm currently working on, and anyway, those patches are intended to be for testing only.

[IanSav]

Hi Prl,

The files changed include:

• skin.py
• Components\ActionMap.py
• Components\config.py
• Components\ConfigList.py
• Screens\Setup.py
• Screens\VirtualKeyBoard.py
• Tools\NumericalTextInput.py
• keymap.xml
• setup.xml
• skin_default.xml
• skin.xml (easy-skin-aus-hd, Full-Metal-Wizard and OverlayHD)
• skin_setup.xml (easy-skin-aus-hd, Full-Metal-Wizard)
• vkey_shift0.png
• vkey_first.png
• vkey_green.png
• vkey_space.png
• vkey_shift3.png
• vkey_yellow.png
• vkey_last.png
• vkey_shift1.png
• vkey_space_alt.png
• vkey_enter.png
• vkey_shift2.png
• vkey_backspace.png
• vkey_red.png
• vkey_text.png
• vkey_blue.png

A few old vkey_xxx images will be removed.

I think that is all but as I prepare the files I may find other changes.

Regards,
Ian.

[prl]

In that list, the only conflicts with my current activities are in the built-in skin.xml files. You'd want to uninstall any of my FileCommander alphas before applying the patch that contains the Setup enhancements, because there are crossover interactions between my skin.xml changes and changes in Python files that aren't in the Setup enhancements.

[IanSav]

Hi Prl,

Is there a way we can combine our changes to skin.xml given that we are changing different parts of the file? If you are nearly done with skin changes then perhaps I should just add your changes to my proposed changes.

Regards,
Ian.

[prl]

Is there a way we can combine our changes to skin.xml given that we are changing different parts of the file? If you are nearly done with skin changes then perhaps I should just add your changes to my proposed changes.

My current changes should be submitted tomorrow. The next change I want to make ("link" arrows on all symbolic files in the list, not just on directories) won't involve any skin changes other than adding a single image file.

I simply think that any of my FileCommander changes should be uninstalled to test your Setup changes. That's certainly how I intend to test them.

[IanSav]

Hi Prl,

Given that your changes are being very quickly adopted into beta releases I think it would be acceptable / appropriate to wait one day for your changes to be submitted / merged and then simply add them into my change proposal. This would give testers the best of both efforts.

Regards,
Ian.

[prl]

Sounds fine to me, but I'm still a fair way from being finished. After the link display in the FileCommander file list, I think I've worked out a reasonably clean way to allow full permission & ownership control on a file.

[IanSav]

Hi,

For anyone following this thread who is using OverlayHD and wanting to try out my new code changes please note that you will need to upgrade to the new OverlayHD skin version 1.66. This is not yet released but I have posted a request for testers in the hope that this update can go our very quickly.

Regards,
Ian.

[IanSav]

Hi,

I am finally ready to provide the files changed to implement the new VirtualKeyBoard. The files required are in the attached ZIP file. I am hoping that Adoxa or perhaps Prl can integrate these changed files into a patch kit so that any users can try out the change. On the other hand, if you are familiar with the structure of Enigma2 and are happy backing up and copying files onto the Beyonwiz then anyone can use the files in this kit to try out the changes.

The ZIP file contains the code, keymap and skin files to implement the change. I would appreciate if the person creating the patch can give the code a try to make sure I have provided everything to make the code usable. Obviously if there is a problem let me know so I can get the source for the patch correct. Please note that these changes are not compatible with the skin_default. I could patch that skin as well but I think it would be better for these changes to come from an upstream merge as skin_default is not a Beyonwiz managed skin.

I welcome comments, suggestions and bug reports. If the testing goes well I will then submit this code as a pull request.

Regards,
Ian.

[prl]

I would appreciate if the person creating the patch can give the code a try to make sure I have provided everything to make the code usable. Obviously if there is a problem let me know so I can get the source for the patch correct. Please note that these changes are not compatible with the skin_default. I could patch that skin as well but I think it would be better for these changes to come from an upstream merge as skin_default is not a Beyonwiz managed skin.

Although VirtualKeyBoardPatch.zip contains 15 VirtualKeyBoard .png files (skin_name/buttons/vkey*.png) only 3 of them appear to actually be modified, the same 3 in each skin:
buttons/vkey_backspace.png
buttons/vkey_space.png
buttons/vkey_text.png

These files are in the ZIP, but aren't different from what is in their respective repositories:
buttons/vkey_blue.png
buttons/vkey_enter.png
buttons/vkey_first.png
buttons/vkey_green.png
buttons/vkey_last.png
buttons/vkey_red.png
buttons/vkey_shift0.png
buttons/vkey_shift1.png
buttons/vkey_shift2.png
buttons/vkey_shift3.png
buttons/vkey_space_alt.png
buttons/vkey_yellow.png


Is that as it should be?

[IanSav]

Hi Prl,

Yes, the three files that use the same names are intended to replace images from the original skins. This was done as the SPACE button is no longer just the background image but a task specific button. The BACKSPACE button is now an iconic rather that text button. The text frame is changed to be longer to account for the new wider button grid. All the other images are to implement all the new features of the code. All the existing images that are not in my kit can be removed when the code becomes production.

One of the main changes is that I don't use graphical buttons to display text buttons. I build those buttons on the fly, after passing the button text through the translation system.

I have also provided some button options for the SPACE button. One is just the SPACE symbol on its own and another with the confirmation text encoded in the button. The one without the text is intended for non English usage. Testing so far on OpenPLi (where there are a number of non English users) so far seem to be happy with the version of the button that says "SPACE".

Regards,
Ian.

[prl]

My confusion. I was looking at the files with git status -uno. The other button icons are additional to what's currently in the repositories.

[prl]

The file set appears to be complete. I'm ready to make a patch available.

I'm a bit puzzled by some of the choices for the locale keyboards.

The default locale is en_GB, rather than en_AU or en_US.

The en_GB locale uses the bottom row of characters for vowels with acute accents (but doesn't include vowels with diaereses, for those of us old enough to know what they're for).

The en_AU locale puts perhaps useful URL abbreviations on those keys.

The en_US locale doesn't put anything in those button positions.

The new button mappings may take a little while for people to get used to, but it's probably worth it in the long run to get more consistency.

[prl]

Here's a an alpha patch that applies the changes in IanSav's VirtualKeyBoardPatch.zip.

I tested this patch on firmware 20180729beta.

It is compatible with OverlayHD and if OverlayHD is installed, it makes the appropriate changes to OverlayHD for the new functions to operate correctly. It may also co-exist with Patches By Adoxa, but I haven't tested that.

To install:

To apply the patches, download the linked .ZIP file, and extract it. It will create a new directory/folder called vkbd-installer, which contains two files, installer.sh and uninstaller.sh.

Copy the two files somewhere convenient on a T/U series box (like /home/root), then log into the box using telnet or ssh, change directory to the place you put the installer.sh/uninstaller.sh files. If you put the files in /home/root you'll be in the right place as soon as you log in.

To install the patches run:

sh installer.sh

and restart the GUI (or reboot).

To uninstall the patches, log in and go to the directory as you did to install, and run

sh uninstaller.sh

And restart the GUI.

Make sure you uninstall before doing an upgrade. Don't run the installer if you've already installed & don't run the uninstaller if you've already uninstalled.

You can check whether the patches are installed by logging in and running this on the box:

find /usr/bin /usr/share/enigma2 /usr/lib/enigma2 -name \*.bak

It should print nothing if the patch isn't installed, and it should print

Code: Select all

/usr/share/enigma2/OverlayHD/buttons/vkey_space.png.bak
/usr/share/enigma2/OverlayHD/buttons/vkey_text.png.bak
/usr/share/enigma2/OverlayHD/buttons/vkey_backspace.png.bak
/usr/share/enigma2/OverlayHD/skin.xml.bak
/usr/share/enigma2/Full-Metal-Wizard/buttons/vkey_space.png.bak
/usr/share/enigma2/Full-Metal-Wizard/buttons/vkey_text.png.bak
/usr/share/enigma2/Full-Metal-Wizard/buttons/vkey_backspace.png.bak
/usr/share/enigma2/Full-Metal-Wizard/skin.xml.bak
/usr/share/enigma2/keymap.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/buttons/vkey_space.png.bak
/usr/share/enigma2/easy-skin-aus-hd/buttons/vkey_text.png.bak
/usr/share/enigma2/easy-skin-aus-hd/buttons/vkey_backspace.png.bak
/usr/share/enigma2/easy-skin-aus-hd/skin.xml.bak
/usr/lib/enigma2/python/Screens/VirtualKeyBoard.pyo.bak

If the patch is installed. If you don't have OverlayHD installed, the lines containing "OverlayHD" won't be shown.


Comments welcome!

[IanSav]

Hi Prl,

The file set appears to be complete. I'm ready to make a patch available.

I'm a bit puzzled by some of the choices for the locale keyboards.

The default locale is en_GB, rather than en_AU or en_US.

That is because my request to make the Beyonwiz default en_AU was rejected. On my machine I do use a default of en_AU.

The en_GB locale uses the bottom row of characters for vowels with acute accents (but doesn't include vowels with diaereses, for those of us old enough to know what they're for).

From memory this was done for the UK keyboard because someone on OpenPLi requested it or it was what I found on the Google descriptions for a UK keyboard. The data can easily be changed. That is why the code is going out for testing.

The en_AU locale puts perhaps useful URL abbreviations on those keys.

The en_US locale doesn't put anything in those button positions.

This was done to preserve PeterU's changes to the keyboard. I can't make it global as this code will now be used globally.

The new button mappings may take a little while for people to get used to, but it's probably worth it in the long run to get more consistency.

Yes, I will progressing these consistent mappings across the whole UI.

Regards,
ian.

[prl]

The en_GB locale uses the bottom row of characters for vowels with acute accents (but doesn't include vowels with diaereses, for those of us old enough to know what they're for).

From memory this was done for the UK keyboard because someone on OpenPLi requested it or it was what I found on the Google descriptions for a UK keyboard. The data can easily be changed. That is why the code is going out for testing.

The Wikipedia for the UK QWERTY layout has the accented vowels on AltGr-letter. Seems an odd choice, but that's what it is.

[IanSav]

Hi Prl,

The Wikipedia for the UK QWERTY layout has the accented vowels on AltGr-letter. Seems an odd choice, but that's what it is.

Yes, I also thought it was very odd. I decided to keep the accented characters rather than offend users in that region. So far no one has objected to the extra buttons.

I am hoping that the Beyonwiz build will finally switch the en_AU as it should always have been. We could even have an en_NZ to keep our near neighbours in on the game.

Regards,
Ian.

[adoxa]

I welcome comments, suggestions and bug reports.

Please use Keyboard where possible (certainly when displayed), not KeyBoard (the word is "keyboard" (a single word), not "key board" (with a space) or "key-board" (with a hyphen)).

Perhaps not directly a VirtualKeyBoard issue, but it would be nice if the text cursor could be visible after the last character. It's disconcerting to move it to the end and have it disappear, as well as not being initially visible. (Looks awkward to implement.)

It might take me a while to stop using PREV as backspace, but it's nice being able to move the text cursor without having to select the movement keys.

[IanSav]

Hi Adoxa,

Please use Keyboard where possible (certainly when displayed), not KeyBoard (the word is "keyboard" (a single word), not "key board" (with a space) or "key-board" (with a hyphen)).

This is the name of a function not a general description so I felt the case matching the function was appropriate. At the moment this is also most convenient as the existing code uses VirtualKeyboard for the parameters and fonts. Using the different capitalisation lets me keep existing code in place. If you feel strongly for a change we can look at this again when the old code and settings are completely removed.

Perhaps not directly a VirtualKeyBoard issue, but it would be nice if the text cursor could be visible after the last character. It's disconcerting to move it to the end and have it disappear, as well as not being initially visible. (Looks awkward to implement.)

I agree with you but this is a skin choice for the two built in skins. If you try OverlayHD you will find that the text is left justified and the cursor is displayed properly. It is not for me to redesign the built in skins, there is a lot I don't like about them which is why OverlayHD came to be in existence.

It might take me a while to stop using PREV as backspace, but it's nice being able to move the text cursor without having to select the movement keys.

You can easily be reminded by using all the new HELP screens I have been adding.

The buttons and keys used in VirtualKeyBoard are indicative and compatible with all the UI code changes I am making. The same navigation buttons should perform identical, or at least comparable, actions throughout the UI. All the new Setup and config code I have been developing already use the same navigation controls. User having to remember and switch between LEFT, RIGHT, CH-, CH+ etc to page up and down etc will be hopefully all be gone when I am finished. For example, my current navigation plan is to use:

• REW -> Jump to top of vertical list
• CH+ -> Jump up a screen
• UP -> Move up a line
• DOWN -> Move down a line
• CH- -> Jump down a screen
• FF -> Jump to bottom of vertical list
• PREV - > Jump to first item in a selection list or first character of text
• LEFT -> Move to previous item in a selection list of previous character of text
• RIGHT -> Move to next item in a selection list of next character of text
• NEXT - > Jump to last item in a selection list or last character of text
• INFO - Toggle insert/overwrite mode during text editing
• BACK or STOP -> Delete the character to the left of the cursor
• PLAY/PAUSE -> Delete the character under the cursor

Where appropriate some of the navigation options may have different but related functions. For example in a screen that has two columns the PREV / LEFT buttons will jump to the left column while RIGHT / NEXT will jump to the right column. Similarly in a screen with two areas one on top of the other then REW / UP will jump to the top section of the screen while DOWN / FF will jump to the bottom section of the screen. This will change if the items in the top and/or bottom of the screen actually allow UP / DOWN navigation in which case only REW / FF will jump up or down the screen sections respectively.

Most, if not all of these navigation functions / actions will also be available for keyboard users.

Regards,
Ian.

[IanSav]

Hi Adoxa and Prl,

For cases where the Input control's text is right aligned then perhaps the text buffer should always keep the cursor and the character under the cursor as the right most element of the data view port. Keeping the cursor hidden, just to the right of the view port can be disconcerting.

I just tested the new scrolling code in the OverlayHD version of the VirtualKeyBoard. The new scrolling code does not work for left aligned text. As you type beyond the view port the new text is not displayed. Prl, can this please be fixed?

Regards,
Ian.

[prl]

I just tested the new scrolling code in the OverlayHD version of the VirtualKeyBoard. The new scrolling code does not work for left aligned text. As you type beyond the view port the new text is not displayed.

By "new scrolling code", do you mean "the alpha test version of Components.Input"?

Prl, can this please be fixed?

I'd presume so. I have so far only tested right-aligned text. I'll certainly be testing other alignments before it is released.

[adoxa]

Hi Adoxa,

Please use Keyboard where possible (certainly when displayed), not KeyBoard (the word is "keyboard" (a single word), not "key board" (with a space) or "key-board" (with a hyphen)).

This is the name of a function not a general description so I felt the case matching the function was appropriate.

Yeah, existing code is hard to change, but user-visible text should not be mixed case (e.g. the title and help description). After all, you want en_AU, not en_PY.

At the moment this is also most convenient as the existing code uses VirtualKeyboard for the parameters and fonts. Using the different capitalisation lets me keep existing code in place.

Ah, I see, existing skins have b for the old code and updated skins have B for the new. Well, that's fair enough, I guess.

[IanSav]

Hi Adoxa,

For now I think changing the skin title= attribute for the VirtualKeyBoard screen should address the problem for you.

Regards,
Ian.

[adoxa]

For cases where the Input control's text is right aligned then perhaps the text buffer should always keep the cursor and the character under the cursor as the right most element of the data view port. Keeping the cursor hidden, just to the right of the view port can be disconcerting.

The problem is that right-aligned text removes trailing spaces, so the space appended to the text for the cursor gets left out. That leads to a simple solution - append a non-breaking space instead of a space.

By "new scrolling code", do you mean "the alpha test version of Components.Input"?

Where's this code?

[prl]

By "new scrolling code", do you mean "the alpha test version of Components.Input"?

Where's this code?

As far as I recall, it's sitting on my laptop and nowhere else, other than backups. That's why I'm puzzled by IanSav's question. I have only tested my code Components.Input on right-aligned text, but I'd have thought it would work on other alignments.

[IanSav]

Hi Prl,

I thought you have made a submission of the code into a beta. If that is not the case then please accept my apologies for muddying the waters with my confusion.

Regards,
Ian.

[prl]

For cases where the Input control's text is right aligned then perhaps the text buffer should always keep the cursor and the character under the cursor as the right most element of the data view port. Keeping the cursor hidden, just to the right of the view port can be disconcerting.

The problem is that right-aligned text removes trailing spaces, so the space appended to the text for the cursor gets left out. That leads to a simple solution - append a non-breaking space instead of a space.

In the just-accepted pull request that implements this, why is a non-breaking space appended when self.visible_width is zero, but an ordinary space appended when it is not? Surely the problem of the original code hiding the cursor when it is in the rightmost position and the text is right aligned applies to both cases?

[adoxa]

Submitted an update.

[prl]

I only noticed it because when I merged it into my modifications to Components.Input, I saw that the new version uses common code to add the trailing space no matter what the value of self.visible_width is.

[adoxa]

I still think I've done it wrong (using Unicode without converting to UTF-8), just about to test...

Edit: it was broken, fixed now.

[prl]

I still think I've done it wrong (using Unicode without converting to UTF-8), just about to test...

Yes, at the point in the code the space being added should be UTF-encoded.

It should be either:

Code: Select all

				self.text = (self.Text + u"\xA0").encode("utf-8") 

or

Code: Select all

				self.text = self.Text.encode("utf-8") + u"\xA0".encode("utf-8")

I'd probably do it the first way.

[adoxa]

I actually did it with "\xC2\xA0".

[prl]

I actually did it with "\xC2\xA0".

That's how it's done in a lot of the code. I'd prefer to see the unicode codepoint in the code rather than using the UTF8. But clearly practice in the code is against me. unicodedata.lookup("NO-BREAK SPACE") might be even better for clarity. It's already imported in Components.Renderer.LcdPicon.

[IanSav]

Hi Prl,

Probably one person used the UTF-8 form and then all the code copiers jumped in and copied that code everywhere without ever understanding what they were doing.

Regards,
Ian.

[prl]

Probably one person used the UTF-8 form and then all the code copiers jumped in and copied that code everywhere without ever understanding what they were doing.

I can easily believe that. It's a pain to work out what they're trying to do with code in that form, though.

[IanSav]

Hi Prl,

Probably one person used the UTF-8 form and then all the code copiers jumped in and copied that code everywhere without ever understanding what they were doing.

I can easily believe that. It's a pain to work out what they're trying to do with code in that form, though.

Some of the code I have been developing and/or refactoring is a result of code patches being applied on to of patches being applied on to of patches, etc. The VirtualKeyBoard is a good example of this. If you look at the existing OpenPLi version you will see a messy nightmare of code. The only way to fix this was to start from scratch. Not only is the new code cleaner and easier to read it is now also easier to maintain, easier to enhance and a little faster to boot.

There is similar effort going into NumericalTextInput, Setup, ConfigList and config. There are more plans to keep going with other code as well.

Regards,
Ian.

[IanSav]

Hi,

I have been asked to proceed with implementing the new VirtualKeyBoard into both OpenPLi and OpenViX. I will prepare the pull requests shortly.

Is there any feedback from anyone on Beyonwiz?

Should I create a Beyonwiz pull request as well?

Regards,
Ian.

[prl]

I only thought of this last night. Not the VirtualKeyboard, but relating back to the config cleanup.

The choices for toggling set membership in ConfigSet are a bit obscure: the number keys, and for an ASCII keyboard KEY_DELETE and KEY_BACKSPACE. Could it be changed to something a bit more obvious (or have something more obvious included)? KEY_OK would seem to be a possibility.

[IanSav]

Hi Prl,

Done and done!

The UI for ConfigSet has been completely revamped. The elements of the list are initially displayed as you see them now, only the elements active / included will be displayed. When you actually select the ConfigSet line and make it current then the entry is replaced with the list of ALL set members. Any set members that are currently inactive / excluded are shown in round brackets. Navigation along the list is via the PREV, LEFT, RIGHT and NEXT buttons (first entry, move left, move right and last entry respectively). Any set member can be toggled active or inactive with the OK, NUMBER, DELETE and BACKSPACE buttons. That set member will either gain or lose the brackets immediately to indicate the change in selection status. When you leave the field the non included elements will be removed from the display.

I have currently left all the old toggle keys in place but I intend to remove them all except for OK shortly.

What do you think? Would you accept OK becoming the only toggle key?

Regards,
Ian.

[prl]

Thanks, Ian. The new interaction interface sounds like a worthwhile improvement, too.

I'm not bothered either way whether the NUMBER, DELETE and BACKSPACE buttons are retained to toggle ConfigSet members when OK is added. I suspect that few people have ever tried to make changes to ConfigSet settings, otherwise we'd probably have seen more questions about how to use it and its rather strange current behaviour.

There are few instances of its use, the most likely ones that people might try to change are in MENU>Setup>TV>Recording settings>Fast forward/rewind speeds.

[Grumpy_Geoff]

...There are few instances of its use, the most likely ones that people might try to change are in MENU>Setup>TV>Recording settings>Fast forward/rewind speeds.

Yep, you can count me in for that one. I have struggled with that setting, particularly moving the 'set members' around after I used OWIF to set/unset some of the speeds and it buggered up the ordering. I got there in the end, and quite possibly I might not have even needed to re-order the speeds in any case.

[IanSav]

Hi Grumpy_Geoff,

How did you change the order of the elements in the set? That was not a feature of the original code and it is not in the new version.

Regards,
Ian.

[prl]

How did you change the order of the elements in the set? That was not a feature of the original code and it is not in the new version.

I was wondering that, too.

[IanSav]

Hi,

While I am grabbing some images for OpenPLi skinners, here is a screen grab showing the new ConfigSet display:

ConfigSet in the refactored Setup UI...

Regards,
Ian.

[prl]

[Grumpy_Geoff]

How did you change the order of the elements in the set? That was not a feature of the original code and it is not in the new version.

I was wondering that, too.

It was a while ago, but I just tested this again. Enabling 24 and 48 puts them at the end.

out_of_order.png (28.9 KiB) Viewed 3398 times

I then had to move along the members and it jumped from 16 to the 24 in the penultimate position, then unset the 24, then move again to 32 and then jumping to 48 and unset it. Then move back to their natural positions and set them again.

I also found that if I unset 24 and immediately set it again that the 48 then gets put in the correct position.

[prl]

Strange. I can't replicate that (U4, firmware 20180809, easy-skin-aus-hd skin):

[Grumpy_Geoff]

Strange. I can't replicate that (U4, firmware 20180809, easy-skin-aus-hd skin):

I'm using F-M-W, same f/w. Did you use OWIF to set some additional speeds? That's what gets them out of order.

Then came the struggle of remembering how to set/unset. If NUMBER wasn't mentioned here then likely I'd have struggled again. PREV/NEXT also work too.

[IanSav]

Hi Grumpy_Geoff,

I can't explain that at all from what I see in the config.py code. Perhaps this is an error in the OpenWebif handling of the web form data.

The fact that PREV / NEXT works will not be the case in the future. PREV / NEXT have been defined to have TWO functions! They are simultaneously coded as jump to first and jump to last AND backspace (delete backwards) and delete (delete under the cursor). The latter defined delete actions redefined and concealed to originally assigned movement actions. One of my corrections to the Setup and config system has been to split these definitions. PREV is now always jump to first / start, NEXT is now always jump to last / end, BACK and STOP are always backspace and PLAY/PAUSE is always delete.

Regards,
Ian.