About Estonian language, I find a small bug: we're missing one character 'š' and 'Š'.
I would suggest to put it on the third page.
Attached Files
Edited by zeros, 25 August 2018 - 10:45.
Posted 25 August 2018 - 10:43
About Estonian language, I find a small bug: we're missing one character 'š' and 'Š'.
I would suggest to put it on the third page.
Edited by zeros, 25 August 2018 - 10:45.
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
Posted 25 August 2018 - 11:05
T9 keyboard (SMS Type keyboard), it's more complicated than I thought.
I can't find the standard about Estonia. I'd have to try on some old type cell phone what I do not have at the moment because I would like to add this thing as it is elsewhere as well.
https://www.online.e...a1-bab232635ab4
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
Posted 25 August 2018 - 12:24
Hi Zeros,
About Estonian language, I find a small bug: we're missing one character 'š' and 'Š'.
I would suggest to put it on the third page.
I can move the "\" to the bottom row then I can add the 'š' and 'Š' just under the BACKSPACE button on shift level 0 and 1 respectively. Is that okay.
Regards,
Ian.
Posted 25 August 2018 - 12:25
Hi Zeros,
T9 keyboard (SMS Type keyboard), it's more complicated than I thought.
I can't find the standard about Estonia. I'd have to try on some old type cell phone what I do not have at the moment because I would like to add this thing as it is elsewhere as well.
I am sorry but I don't understand what all the images are meant to mean or what you want me to do.
Regards,
Ian.
Posted 25 August 2018 - 13:22
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
Posted 25 August 2018 - 16:16
And second- Estonia is just missing at the moment and I can see there English default setup. I'm investigating where the missing characters of Estonia are located on T9 keyboard (SMS Type keyboard)
This one from attached screen would be correct Estonian text input layout?
(I was not completely sure about Š and Ž if they should be included, and of the order of special O's...)
Edited by blzr, 25 August 2018 - 16:17.
Posted 25 August 2018 - 16:35
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
Posted 25 August 2018 - 17:08
Edited by Taapat, 25 August 2018 - 17:08.
Posted 25 August 2018 - 17:08
Hi Everyone,
After Zeros' request I have reviewed my plans for NumericalTextInput. I have now rewritten it to be significantly more flexible. All the various input modes, text entry, search entry and hex entry, can now be offered for ALL languages. I believe that the hex modes are international and will be the same in all languages. If I am wrong please tell me.
What this means, for example, is that the NumericalTextInput search option can now be in a local language and not forced to only be in English.
I will try to adapt the existing languages into the new system but I really need your help the check my work and offer improvements and corrections. Remember I only know English so I will likely make mistakes for which I will welcome corrections.
Regards,
Ian.
Posted 25 August 2018 - 17:23
We have an old-type mobile with keyboard Sony Ericsson W715. I will try to rip in tomorrow how Estonian language has been presented there. The main characters are the letters õ,ä,ö,ü,š,ž, what are missing, If we are talking about Estonian SMS type keyboard.
As you can see on the screenshot in my previous post, I've added ä,õ, ö, š, ü, ž letters in my version;
if you'd like to test on your stb, NumericalTextInput.py with Estonian layout added attached...
Posted 25 August 2018 - 17:26
Hi Taapat,
@IanSav are you offering these changes In VirtualKeyBoard thought also about compatibility?
1. Why do you change the location of buttons png from skin_default to buttons?
This makes mandatory create these buttons in skins and not allow use it from skin_default.It create GSOD on all skins that miss this change and does not have own buttons for VirtualKeyBoard!
I think it's right to place these buttons png in skin_default as before, because in that case they are in enigma and they can be used by all skins without change.
If you want your buttons you can change them in skin_default in your skin.
If you have been following this topic OpenPLi has a very strange way of locating images. It makes no allowance for finding images in standard locations and has no option to find images based on the current resolution of the skin. I have proposed ways to fix this and I think some of the developers are seeing the issue and are also considering a change to make locating images easier and smarter.
Did you read my instruction manual ( /doc/VIRTUALKEYBOARD ) for implementing the new VirtualKeyBoard? I have also provided XML samples and all the standard images that most developers can use to kick start their skin updates.
2. Why did you change the "header" to the "prompt"?
I understand that the "prompt" is a more precise mark, but it also breaks the compatibility with skins without change.
I think it's better to leave a "header" as before.
The old variable is misleading and needed to be changed. Given the other changes in the new VirtualKeyBoard required changes to skins anyway I felt this was an appropriate time to make this correction. Unless someone starts implementing fixes then these sorts of issues will never get fixed.
I am disappointed that not all developers and skin maintainers are reading the instruction I wrote to help with the update. If my instructions are followed then there should not be any crashes or issues. I have also been actively helping and supporting anyone who has asked for assistance with the change.
Regards,
Ian.
Posted 25 August 2018 - 17:30
Hi Bizr and Zeros,
We have an old-type mobile with keyboard Sony Ericsson W715. I will try to rip in tomorrow how Estonian language has been presented there. The main characters are the letters õ,ä,ö,ü,š,ž, what are missing, If we are talking about Estonian SMS type keyboard.
As you can see on the screenshot in my previous post, I've added ä,õ, ö, š, ü, ž letters in my version;
if you'd like to test on your stb, NumericalTextInput.py with Estonian layout added attached...
If this Estonian layout is okay with Zeros as well then I would like to use it in my new NumericalTextInput. The code is quire different now and I am still checking to make sure it will be a drop in replacement for the existing code.
Regards,
Ian.
Posted 25 August 2018 - 17:38
Posted 25 August 2018 - 17:43
Hi Taapat,
I fully agree that the distribution of images is not optimal. Unfortunately there is currently no mechanism within OpenPLi to properly address this problem. If/When we can get consensus on how SCOPE_CURRENT_SKIN can be changed to resolve these issues then we can move to cleaning up the VirtualKeyBoard images and probably a lot more.
I would like to be able to improve and fix everything at once but unfortunately that is not possible.
Please spread the word to all skin maintainers to have a read of the documentation and adjust their skins accordingly. If anyone needs help then get them to come here and ask. I will be happy to help.
Regards,
Ian.
Edited by IanSav, 25 August 2018 - 17:44.
Posted 25 August 2018 - 18:08
Posted 25 August 2018 - 18:19
Hi Taapat,
But why you want to use exactly resolveFilename(SCOPE_CURRENT_SKIN, "buttons/... ?
I do this because I don't want to create a complete and utter mess in the skin directory. I believe that the images within a skin should be organised into some sort of meaningful structure.
If you feel that the buttons are not correctly placed directly in skin_default, ok place them in skin_default/buttons and use resolveFilename(SCOPE_CURRENT_SKIN, "skin_default/buttons/..
But I think it's wrong specially create a GSOD for incompatible skins.
Why hard code odd paths into the resolver. The resolver should be able to use its own logic to find the required image files. The OpenViX and Beyonwiz images have some logic in their resolver to do this for you. I think this idea could and should be used and improved upon within OpenPLi's resolver. See my and Littlesat's earlier comments for some of the ideas being considered.
Regards,
Ian.
Edited by IanSav, 25 August 2018 - 18:21.
Posted 25 August 2018 - 18:54
Posted 25 August 2018 - 19:00
Hi Taapat,
Can you please provide a sample list of folders where you believe skin components should go. Then describe how an image is to be found within that list of directories. I would also like to see how you handle images that belong to skins of different resolutions.
Please excuse me if I don't make any more posts tonight. It is a 04:00 in the morning here and I really need to get some sleep. I will look at your post and respond when I awake.
Regards,
Ian.
Posted 25 August 2018 - 19:37
Edited by Taapat, 25 August 2018 - 19:38.
0 members, 10 guests, 0 anonymous users