998 replies to this topic

[zeros]

Screenshots:
https://www.online.e...08-722c0becc012

[IanSav]

Hi Zeros,

 

The images you posted are not correct.  I don't think the skin you are using is correct.

 

Here are some samples from my machine.  This are using the DejaVuSansCondenced font.

 

 VirtualKeyBoardSample1.jpg   97.74KB   0 downloads

This is a sample of the en_AU (English - Australian) keyboard featuring some helpful text buttons.

 

 VirtualKeyBoardSample2.jpg   95.11KB   0 downloads

This is a sample of the fa_IR (Persian - Iran, Islamic Republic) featuring the characters that only exist in the DejaVu font set.

 

Regards,

Ian.

 

[zeros]

You are right, they are made before this font was added. I put them ithe screen shots I had made earlier and which I wanted to play earlier when I mistakenly went to the wrong file. It should be fine, Thanks for the nice work!

[zeros]

Could you add the Latvian keyboard screen capture on your recent changes view?

There were recently missing a few signs which I would gladly review. These are also special letters which may perhaps require a special font.

I add the screenshot of what was before. (The Latvian keyboard had already existed)

Attached Files

•  Latvian-keyboard.png   536.26KB   1 downloads

[IanSav]

Hi Zeros,

 

Sure here are the three shift levels for Latvian:

 

Regards,

Ian.

 

Attached Files

•  Latvian0.jpg   90.14KB   1 downloads
•  Latvian1.jpg   94.42KB   1 downloads
•  Latvian2.jpg   84.29KB   1 downloads

[zeros]

Thank you, I see that these characters are there nicely.

[Persian Prince]

@Ian

 

New virtual keyboard is in PLi's sources now

 

Regards,

Persian Prince

[IanSav]

Hi Persian Prince,

 

Does this mean it now gets wider testing or does it mean it is going out to users?

 

By the way, thank you to you, Zeros and everyone else who helped make this a reality.

 

Regards,

Ian.

[Persian Prince]

@IanSav

It's in develop branch of enigma2 so no it won't be available for users now but it's available for all developers and self-image builders

Regards,
Persian Prince

[ims]

My notes about it:

 

1 ) changes in fonts ... must be changed date in enigma.bb for it or changes are not accepted => gsod, because font dejavu is missing

 

2 ) change this, as it worked long years:

- use CH+/CH- for move cursor in text's label (as it was before) ...more ergonomic ...  it is not ideal to have 2 V.K. buttons on left bottom side only or use small FW/RW.

- use PREV/NEXT keys as delete before/under text cursor ... and do not use it as "Home/End" ... for it are 2V.K. buttons and "prev song"/"next song"

- each empty key should be SPACE as before

 

3 ) in help missing a lot of keys... user must be detective.

You are using one action for more keys, but defined in keyboard.xml. There is better defined same action for different keys in python - then you get help for all buttons on used RC

 

4) it is replace old VK in skin ? Standalone window in center ?

 

5) not all RCs have PLAYPAUSE. Some have PLAY, PAUSE, STOP, some has PLAYPAUSE, STOP

Edited by ims, 17 August 2018 - 09:40.

[littlesat]

1... I'm still think we should not change the skin -but- instead arrange to add (improve) the missing stuff in the current skin...

2... I agree... this should be (RE)added

3+4+5 Finetuning.... 

 

But in between we're already start improvements on the Virtual Keyboard....

Edited by littlesat, 17 August 2018 - 10:58.

[ims]

1... I'm still think we should not change the skin -but- instead arrange to add (improve) the missing stuff in the current skin...

2... I agree... this should be (RE)added

3+4+5 Finetuning.... 

 

But in between we're already start improvements on the Virtual Keyboard....

 

point 1 ) it is not about skin ... but about GSOD

 

Changes in skin are not problem (extra work only - it shout be done, btw) ... I changed it for PLi-FullHD (see picture).

Problem is in layout ... for me missing whole line with nat upper chars and I want not adding 4th layout...

 

 

Btw - for SD skins GSOD

  File "/usr/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 705, in buildVirtualKeyBoard
    self.markSelectedKey()
  File "/usr/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 736, in markSelectedKey
    self.list[self.selectedKey / self.keyboardWidth].append(MultiContentEntryPixmapAlphaBlend(pos=(x, 0), size=(self.key_sel.size().width(), self.height), png=self.key_sel))
AttributeError: 'NoneType' object has no attribute 'size'

Attached Files

•  VK.jpg   77.8KB   1 downloads

Edited by ims, 17 August 2018 - 11:18.

[littlesat]

Which sd skin? Sounds like it also need some adaption

Edited by littlesat, 17 August 2018 - 11:50.

[ims]

all PLi-HD*

old default skin too

Edited by ims, 17 August 2018 - 11:56.

[zeros]

ims, your GSOD text is as in my case, see my post # 146
How do you change the annexes? Are you sure you're properly attached?

[littlesat]

I see only one screen was changed and it seems it is now a full screen.... Why?

[ims]

I see only one screen was changed and it seems it is now a full screen.... Why?

Where ? I tried change PLi-FullHD to fullscreen with Pig. I hate standallone VK in center ...

[littlesat]

E.g. here...

https://github.com/l...1772fb27fb17563

[IanSav]

Hi,

 

Rather than repeat answers for each of the recent posts let me address them all.

1. If a build or image does not have the DejaVuSans font installed then obviously asking the system to load that font will cause a crash.
   
   If DejaVuSans is going to be added then add it EVERYWHERE so that it is universally available.  If it is not going to be globally available then keep using "Regular".
   
   The crash is not caused by the VirtualKeyBoard.  It is a problem that the skin load does not cope with fonts not being found at load time.  This is an Enigma2 issue that should be fixed.  Blaming this crash on VirtualKeyBoard is inappropriate.
    
2. The new button assignments are different because they are part of a much bigger plan to make all navigation buttons more logical and consistent.  Some users may think the new buttons are odd but as more screens get adjusted the new system will be MUCH better.  All the button matching is done in the VirtualKeyBoardActions section of the keymap.xml if you want to change it do so but I think you will like the mappings when you realise how much easier to use the system will become.
   
   In general:
   PREV -> Jump to the beginning or first item of a selection list
   LEFT -> Move one item to the left
   RIGHT -> Move one item to the right
   NEXT -> Jump to the end or the last item of a selection list
   REW -> Jump to the top or first item of a list
   CH+ -> Jump up one screen
   UP -> Move up one item
   DOWN -> Move down one item
   CH- -> Jump down one screen
   FF -> Jump to bottom or last item of a list
   BACK / STOP -> Delete a character or item to the left of the cursor
   PLAY/PAUSE / PLAY -> Delete a character or item under the cursor
   INFO -> Toggle between insert or overwrite mode for text entry
   MENU -> Convert a selection list into a selection menu
   
   Some buttons may get reassigned to comparable functions where required.  For example, in VirtualKeyBoard, we need a way to navigate the grid and the text buffer so the arrows navigate the grid and REW and FF are "borrowed" to become LEFT and RIGHT for the text buffer.
   
   This borrowing of buttons for related issue is in the plan.  For example in a screen with left and right columns of lists LEFT and RIGHT will no longer be jump up or down a screen but move to the left or right columns respectively.
   
   You will see much more of this button consistency if/when you look at my completely rewritten Setup.py, ConfigList.py and config.py.  It is mostly written but needs a few more items to be completed and then tested.  The refactor is to clean up a lot of very bad code and to fix a significant number of bugs and/or issues in the existing code.
    
3. Most of the code I am changing will be getting help information added.  This is one of the reasons why I gave OpenPLi and OpenViX the new ActionMap.py code.  If OpenPLi and OpenViX would take the new Beyonwiz help engine then you could also have a cleaner and far more functional help system.
   
   If you believe that I have made any mistakes with the VirtualKeyBoard help then please tell me exactly what is wrong.
   
   (Using the new Beyonwiz help engine the help menus are quite different and much better.  I can show screen captures on some of the changes if people are interested.)
    
4. The location and presentation of the VirtualKeyBoard is up to the skin writer.  For simplicity I gave the sample as pop up screens but in OverlayHD I designed it to be a full screen.  The VirtualKeyBoard code supports use in both pop up and menu screens.  Any displays that you currently are looking at can be changed in the skin.  Please ask the skin authors to change their presentation as per the documentation I provided.
    
5. All the sample remote controls I have seen only have PLAY/PAUSE, I can/will add PLAY as an alias.

Do these comments address the concerns expressed so far?

Do I need to fix anything, other than the keymap.xml PLAY button?

Are there any other questions?

 

Regards,

Ian.

[IanSav]

Hi Ims,

 

 

point 1 ) it is not about skin ... but about GSOD

 

 

Changes in skin are not problem (extra work only - it shout be done, btw) ... I changed it for PLi-FullHD (see picture).

Problem is in layout ... for me missing whole line with nat upper chars and I want not adding 4th layout...

 

 

Btw - for SD skins GSOD

  File "/usr/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 705, in buildVirtualKeyBoard
    self.markSelectedKey()
  File "/usr/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 736, in markSelectedKey
    self.list[self.selectedKey / self.keyboardWidth].append(MultiContentEntryPixmapAlphaBlend(pos=(x, 0), size=(self.key_sel.size().width(), self.height), png=self.key_sel))
AttributeError: 'NoneType' object has no attribute 'size'

 

In this case the crash is caused because the VirtualKeyBoard icons are not in exactly to correct place.  They must all be in the buttons subdirectory of the current skin.

 

On OpenViX and Beyonwiz the SCOPE_ACTIVE_SKIN function are a copy of SCOPE_CURRENT_SKIN with the added ability to find images in the current skin or else in the skin_default skin.  This allows image sharing between skins.  On OpenPLi all the skin images must be carefully placed in the correct locations.  Please read the VirtualKeyBoard installation notes from the test kit.  I have attached them here for easy reference.

 

I will update the VIRTUALKEYBOARD documentation to make the image location information explicitly more clear.

 

Regards,

Ian.

 

Attached Files

•  README.txt   2.19KB   1 downloads