998 replies to this topic

[IanSav]

Hi Persian Prince,

 

Have you been testing this new version of the VirtualKeyBoard?  There was a bug in the Persian locale that I am hoping I correctly fixed.

 

Regards,

Ian.

[littlesat]

It was decide not to make the keyboard wider... instead we decide to make a third shift screen for other wierd buttons... this as compromis skins stay compatible and wider keyboards also look chaotic...

Edited by littlesat, 14 August 2018 - 06:44.

[IanSav]

Hi Littlesat,

 

- Who made this decision?

- Why was I not involved in the discussions?

- Don't users and usability of the screens matter?

 

Fixing skins is not hard!  Are you saying that no code can be fixed or improved if it requires a change to skins?

 

Regards,

Ian.

Edited by IanSav, 14 August 2018 - 07:08.

[Persian Prince]

Hi Persian Prince,

 

Have you been testing this new version of the VirtualKeyBoard?  There was a bug in the Persian locale that I am hoping I correctly fixed.

 

Regards,

Ian.

 

Hi Ian,

 

Would you please give me the latest version (I want to add it as a patch for https://github.com/P...etas/pli-extras so I could compile an image with the new keyboard? Also I can build a new beyonwiz image with your keyboard if you want

 

Regards,

Persian Prince

[IanSav]

Hi Persian Prince,
 
The latest code is on the previous page in post #157.  I don't know if you should be bothered making any changes.  It appears that Littlesat and unnamed others have decided that this code will not be accepted.

 

Regards,

Ian.

[littlesat]

- Who made this decision?

- Why was I not involved in the discussions?

- Don't users and usability of the screens matter?

 

Fixing skins is not hard!  Are you saying that no code can be fixed or improved if it requires a change to skins?

Most likely this was decide 'in the background'... it was a third screen and/or make it wider. Making it wider is not the way to go so we choose to go for the third screen only. Making it wider also made the navigation 'longer' and indeed has complications with skins so this was not the optimal way to go when the issue, goal and scope was that there were not enough spots for 'weird' characters. In addition the SMS way is still faster. Making a third shift screen only needs relatively small changes in python and nothing needs to be changed in skins so everything is 100% compatible. E.g. IMS was involved here (https://github.com/O...6489c47ce06feb6)

Making it wider does also not 'feed' the user usability. I think it makes it even worse as the selections of the keyboard get wider... so more keypresses are required to reach a specific character. In addition when you add two columns you effectively have less additional buttons (16 characters max or so) than with adding a third shift screen...

 

A solution is not always what you thirst think!

 

There was also a third option is scope.. the blind key option when you e.g. press " then e that gives an e with double points on top etc... but this is extreme complicated in coding and does also not always reach each character in every possible country,

The issue is always here that a lot of coders (including myself)... first solve an issue with coding, before they investigate the problem to create a real balanced solution...

 

And beside this using the SMS style is even faster than using arrow navigation on a virtual keyboard....

 

 

Won't it be better for testing to create your keyboard with an alternate name and screen name that won't try to reuse the existing one, and find a way to be able to select the keyboard that we want to use. I guess this will ease life of people willing to test your new keyboard layout.

 

This was exactly one on the reasons why we did go for a third shift screen...

 

Do do it really properly you could consider to reverse engineer the keyboard from e.g. an iPhone/iPad...

Edited by littlesat, 14 August 2018 - 08:36.

[Pr2]

@Littlesat,

 

Am I right to think that the decision taken for the current Enigma2 keyboard layout was made when the full-HD skin doesn't exist yet. So we had less pixels available and the current keyboard layout was a nice decision?

Or is it a decision take in full consideration of the full HD skin (and even more in the future I guess)?

Just to clarify this point.

 

Pr2

[IanSav]

Hi Littlesat,

 

In all your coding and usability considerations were the end users EVER considered?

 

A significant part of my design and logic was to make the "VirtualKeyBoard" match and be comparable to / compatible with a real world physical keyboard.  You should note that the button allocations are very deliberately chosen to match real / physical keyboard positions as closely as practical.  This was done to allow users to find the buttons they want quickly because the layout should be closer to a real keyboard with which they would be more familiar.  Doing this with the narrower layout is impossible!

 

The previous Enigma2 VirtualKeyBoard requires users to scan all the buttons on all the different shift screens to find the button they may require.  There was no plan or logic to the previous button assignments.  This is inefficient and not user friendly!

 

The new VirtualKeyBoard still fully supports SMS style data entry.  It also now allows for data input with a physically (wired, or wireless) keyboard.

 

I didn't throw the new VirtualKeyBoard together on a whim.  This is not my first version of the code review either.  This was a considered and, in my opinion, a well thought out redesign.  Initial reviews of my earlier screen captures indicated that the new design could be popular among Enigma2 users, including OpenPLi users.

 

I find it ridiculous that significant improvements to the Enigma2 core must be put at risk and/or be totally rejected because the skins may require some minor adjustments.  Why aren't the skin designers part of the code improvement process.  In my test kit I provided all the information and samples that any skin designer should require to make the trivial adjustments to their skins.  I could make the appropriate changes to the skin_default skin if required.

 

If you wish to argue that not all skins are fully supported then I would ask why those abandoned skins are still being distributed?  Enigma2 is a living product and if elements are abandoned then either new maintainers should be found or those elements deprecated with a view to ultimately being removed.

 

Since I started cutting OpenPLi versions of my code I have made little to no progress in getting a valid development platform or getting my changes accepted without MAJOR efforts.  Am I simply wasting my time trying to include OpenPLi in my efforts?

 

Regards,

Ian.

 

[IanSav]

Hi,

 

I should also point out that the new VirtualKeyBoard is fully translatable to any language.  There are no buttons with English text that must be used in another language.  All the action buttons are built on the fly and use translated text.

 

Before you mention the SPACE button having the word "SPACE" on it, there are two versions in the image kit, one with and one without the hint text.

 

Regards,

Ian.

[Pr2]

IanSav,

 

Sorry but there is not really a standard and unique keyboard layout, so end-user are used to search for the key they want when it is visual/on-screen keyboard.

A keyboard on a PC, on a Mac, on an Android, on an Apple iPhone/iPad are different. And since dead-keys are not supported end-user will anyway have to search to the symbol on the screen.

 

Moreover the usage is also totally different, you never wrote a novel on an enigma2 receivers, you just use the keyboard to enter configuration value, to make a search or rename some entries.  So its usage is very limited and doesn't require neither to have a full keyboard.

 

You mention that you keyboard support physical one, but Enigma2 already support external physical keyboard, so I don't see what you bringing here?

 

So once again, I think that if you want your keyboard to become popular make it as a true 3rd party plugin so people can decide or not to install it. But I am not sure if every plugin creators (which include skin) and pure skin makers will adapt there source code to support it.

 

How can you think that people will switch to your keyboard layout, if some of there installed plugins crash due to skin issues?

End-user needs a way to choose the keyboard so they can switch back to the current one (and use there beloved plugin) letting time to report the issue and have somebody having a look into the plugin to fix it to support the new layout.

 

And if end-user has no possibility to switch back to the current keyboard layout they are totally blocked, plugin no more working at all!

 

You should think in a sweet transition to it, and not a Big Bang like you try to do now.

 

Have you installed all the existing plugins and try them out one-by-one with your keyboard?

 

Pr2

[IanSav]

Hi Pr2,

 

The skin crash issue is simply because OpenPLi does skins in a different, and less smart, way than the other images.  The crash Zeros experienced was because I wasn't specific enough in my patch instructions.  There was nothing wrong with my code and the code was not changed to correct the issue.  All that needed to happen was I had to specify the exact location where the images were to be placed.  If the code were to be merged then this would not be an issue.

 

There should be no need to test all existing plugins as the entry and exit parameters of this code function should be identical.  I don't have a workable test environment for OpenPLi but all my testing so far on OpenViX and Beyonwiz have not indicated ANY issues.

 

How do you expect me to make the VirtualKeyBoard a plugin?  Creating the infrastructure to abstract this screen would be difficult to justify.  Not only would this be messy it would add bloat to the code.  I don't see what purpose or benefit it would offer.  What is so good about the old code, that I have not included or improved in the new code, that requires the old code to be kept?

 

Regards,

Ian.

[IanSav]

Hi Littlesat / Pr2,

 

Is there any information or responce to my comments and questions?

 

How are we going to proceed?

 

Regards,

Ian.

[IanSav]

Hi Persian Prince,

 

Have you tested the new code?

 

Regards,

Ian.

[IanSav]

Hi Zeros,

 

How is your testing proceeding?

 

Regards,

Ian.

[zeros]

Sorry, didn't test it last night, I'm going to do tonight. On Gsod I say it's not a problem, I'm not afraid to get them. The testing is to find and eliminate the bugs. I haven't seen the result yet, but I think it's going to be okay with your help. Can you tell me where besides the YouTube plugin we can use it more?

[littlesat]

We simply do not go fir making the keyboard wider... please keep it compact and small as it was... with a third shift screen there is suffiiciant room for special characters. Don’t go for the extra skin complications!
And a third shift screen is proven concept. Apple and Google is doing it. And e.g. For the English or dutch keyboard I even don’t know what to put there... empty keys are realle not done.
When you change code that required changes in the skin should also be done with care. Adding buttons is a have to add button for each keyboard... adding a third shift is it might be done when required and keeps stuff full backwards compatible. I think adding buttons is too much work with too much risk breaking thinks... as you see you’re also depended on skins...
And yes I think about the end users and this als means it is not your wish and also not my wish...
It is sometimes difficult to cobtribute to an open source community and here at ooenpli we are not willing to afd everyones changes. We want to keep some control regards the quality and also the changes. So we also weight changes. It seems three months ago you were not involved in a discussion here so you did go for a different fork for the not having enough characters in the virual keyboard issue and now of course you think your solution is THE solution and any argument from my side has for you no added value. That is how opensource seems to work...
But come with screenshots... so we see what we’re talking about...!

Note an iPhones keyboard width is 9 columns.... 14 where you even don’t have a touch screen is from my point of view still too much. Then better go for a complete new revision and copy and paste what Chrome or Apple is doing...

Edited by littlesat, 15 August 2018 - 07:06.

[Persian Prince]

Hi Persian Prince,

 

Have you tested the new code?

 

Regards,

Ian.

 

Hi Ian,

 

I did add your new Virtual Keyboard to our sources: https://github.com/P...f672df22d11cd55

 

Anyone wants to test your keyboard could simply add "iansav" to MACHINE_FEATURES and enjoy it

 

It patches enigma2 and https://github.com/l...r/share/enigma2 skins automatically

 

I have to admit your new keyboard is fantastic but as enigma2's fonts do not contain Persian characters I see the keyboard like this:

 

 

If I use DejaVuSans.ttf (https://forums.openp...ndpost&p=896893) it will be ok:

 

 

Regards,

Persian Prince

[littlesat]

As a .patch.... a kind of brrrr... Better try to get pomprimises here after a good weight discussen and then go for a popper merge request/patch.

 

i also counted now a normal keyboard. There the top two rows have 14 keys, then 13, then 12 and then 8 (with the big space bar). In between I also verified some screenshots.

 

Maybe we should go for 14 keys in a row.... Here for the good loocking it should also be nice to have a wide space bar so the bottom line is also filled up to the right... to 'balance' the whole thing.

 

Can we have a proper merge request including correct fixes for the standard skins?

Edited by littlesat, 15 August 2018 - 09:00.

[Persian Prince]

I did add it as a patch for develop and easy testing, if Ian finishes his work I'm willing to test and create merge requests for PLi's enigma2 and all wanted skins

[IanSav]

Hi Persian Prince,

 

In my OverlayHD skin I now automatically install the DejaVu fonts and forcibly select them for use on the VirtualKeyBoard.  I regret that, as you can see from some of the posts here, some developers don't care what users like and/or want.  Perhaps you can lobby for the default inclusion of the DejaVu fonts into the default build.

 

I am saddened by the constant negative reaction to any proposals for improvements or changes to Enigma2.  OpenPLi is a significantly more difficult team with whom to work.  Rejections range from the politically motivated or "we always did it that way" to a hint of "not invented here" syndrome.

 

I am repeatedly told that contribution to OpenPLi is welcomed.  For the VirtualKeyBoard submission I am told that my code is welcomed as long as it doesn't change anything.  Really!?!  What is the point?  The changes required to the skins are TRIVIAL yet it is apparently not permitted.

 

I am at a total loss as to what to say or what to do.

 

Regards,

Ian.