998 replies to this topic

[Huevos]

Can you point me to that part...

 

Actually you navigate with left/right/up/down and you have equal keys in each row... so I do not see how the navigation can be done quickly for larger buttons...

That is what happens when people confuse something that looks good in a jpeg image with something that is a practical, user friendly interface.

 

If you have a wide button with 2 narrow buttons above it how does the UI ever decide which narrow button to select when moving from the wide button to the narrow button. For this reason, IMO, all buttons should form a grid where it is 100% clear which cell becomes active to when pressing LEFT/RIGHT/UP/DOWN.

 

Aesthetics should come second to a user friendly interface. And whether Ian's keyboard has any aesthetic problem is a matter of opinion anyway.

Edited by Huevos, 21 September 2018 - 15:36.

[Pr2]

You can keep the grid approach even with wider buttons, a wider button is just a button that include several adjacent cells, you just need to remember the former button position.

So when you reach the wider button you can always easily return to this last position depending on the direction decided by the end-user.

[littlesat]

Indeed... only when you do left/right you need to ‘skip’

[Rob van der Does]

Actually you navigate with left/right/up/down and you have equal keys in each row... so I do not see how the navigation can be done quickly for larger buttons...

Exactly!

[Taapat]

I can make mistakes, but at this moment I understand this:

The code already assumes that the size of the buttons in the skin may vary.

Therefore, you can use larger buttons in HD skins.

The same thing works if the button size is only wider and not bigger.

Therefore, in markSelectedKey is the check for select button location and size: https://github.com/O...eyBoard.py#L404

 

If we are talking about button sizes then I agree that the left/right/up/down navigation buttons of different sizes may be a problem.

It seems to me that a button with 2-button size, if it is just on the edges of the keyboard, is a very small problem. There is no big problem going one position to the right or left if we leave it.

A bigger problem might be space if it has a large size. In the current code this button looks like one button with a wider size, so it does not remember the previous position.

 

But if we consider that the left/right/up/down navigation as a priority, then the existing layout 4x14+1x7 is not good enough.

Then you should use for example 5x13.

 

If anyone says that the view is less important than navigation that was used until now, then you should have told this Steve Jobs 10 years ago, when he released the iphone without buttons  .

Edited by Taapat, 21 September 2018 - 17:59.

[Huevos]

 

If anyone says that the view is less important than navigation that was used until now, then you should have told this Steve Jobs 10 years ago, when he released the iphone without buttons  .

 

I don't know what you mean. The iPhone uses a tactile screen there the user touches the required button, i.e. an image map, not left/right/up/down buttons on a remote control.

[Taapat]

I think that before first iphone many thought that navigation was possible only with buttons. And if something changes this, then it will not be usable.

 

But I also like simple and understandable things.

Therefore, I do not like the current keybord, which is not symmetrical and contains non-usable buttons.

I do not know what would be the right way. Seeing the sss keyboard I think it might be a wide buttons.

But maybe I'm wrong.

It seems to me that I will create it, and try how it works.

Edited by Taapat, 21 September 2018 - 18:37.

[Abu Baniaz]

Some questions:
Why only two languages have the wide spacebar?
Why are Tappat's changes to achieve the wide space bar/uttons, i.e make it look like a real keyboard being alleged to have detrimental effect in speed? Is there any truth in this?
Why are Tappat's changes to achieve the wide space bar/uttons, i.e make it look like a real keyboard being alleged to have messed up the clean code? Is there any truth in this?

I found objections to thr wide buttons here? Are these objections unfounded?

Is it possible to have the space bar bigger on VK like on real keyboard?

This is not easy to do. The simplicity of the code lies in the easy calculations required to calculate the cursor position. Making any keys an irregular size would complicate the code for little return. This is not a change I would like to tackle at this late stage.



The other issue is that some of the keyboard designs take advantage of every grid location available per screen. Removing available cells would require a rework of all the keyboards.

[Taapat]

I changed the layout only in my language and in en language after the litelsat request. Ims added this also in their language. I do not want to change anything in languages ​​that I do not use and therefore do not know what is the best layout for them.
If you want a wide buttons also in your language, write as you need and I will change it, or offer a change by yourself.

Edited by Taapat, 23 March 2019 - 16:34.

[IanSav]

Hi,

 

Do OpenPLi want the latest version of my VirtualKeyBoard?  It has been significantly updated and now should include all of the OpenPLi changes plus a lot more.  The code has been further optimised to improve performance and readability.

 

Yes, it has variable width button.  They are significantly better than the current OpenPLi version and have been implemented for all supported languages.

 

All the keyboard layouts should now comply with the layouts as described at http://kbdlayout.info/

 

Regards,

Ian.

Edited by IanSav, 31 March 2019 - 17:11.

[Abu Baniaz]

I am sure PLi do not do "blind dating". Can they see the changes before they say yes or no? I could not see the changes on your repository.

https://github.com/IanSav

I am sure PLI will take in benefcial changes that are to done to the normal high standards of your coding.

[IanSav]

Hi,

 

The code and required skin changes can be reviewed on OpenViX.

 

Regards,

Ian.

[littlesat]

That does not really help review on vix... please offer a merge request.... and/or show some screenshots... and also discuss your changes so we can help/adapt/give comments.
Is this the ‘only’ patch? https://github.com/O...e72964100d024b9
I’m not aware as far vix vkeyvoardcode is in line with hours....

Edited by littlesat, 1 April 2019 - 07:08.

[IanSav]

Hi Littlesat,

 

I rewrote the my previous VirtualKeyBoard to add the variable button sizes plus a whole lot more including some performance improvements.

 

I am happy to file a pull request but I don't want to be abused for my efforts.  Some of the OpenPLi members have been rude and critical and I don't enjoy working under such abusive conditions.

 

I will fille a pull request so you can see the code.  Here are some images of the new look:

 VKB1.jpg   167.06KB   0 downloads

 

 VKB2.jpg   150.43KB   0 downloads

 

Regards,

Ian.

 

[littlesat]

Thanks please... and the changes required in the skin?

Please stay open for (my) comments related to python code.... I understand it could sound rude... but that is never the intention. We try so strive some kind of quality, here ‘it (just) works’ is not sufficiant...
Nice to move Some buttons to the color buttons below... simple and proper idea...

Edited by littlesat, 1 April 2019 - 07:27.

[IanSav]

Hi Littlesat,
 
The code has been tested, checked and peer reviewed already but if there is a constructive proposal I would be glad to hear it.

 

Here is the complete pull request including all the required images for the default skin: VirtualKeyBoard enhancements #2079

 

(Some of the old images can be deleted as per the included documentation file.)

 

Regards,

Ian.

[Huevos]

Thanks please... and the changes required in the skin?

Please stay open for (my) comments related to python code.... I understand it could sound rude... but that is never the intention. We try so strive some kind of quality, here ‘it (just) works’ is not sufficiant...
Nice to move Some buttons to the color buttons below... simple and proper idea...

In ViX no skin changes to the xml file were needed. Only changes to some of the button images.

 

 vk.jpg   91.29KB   0 downloads

[littlesat]

@IanSav,

 

I'm not able to test the next day.. But as far I look at your coding it looks good... ...

When I do not need to adapt our basic skin(s) I can take the risk to merge it...

[WanWizard]

I don't like the word "risk" when we're about to branch off a release-candidate...

[IanSav]

Hi Littlesat,

 

I hope to soon have a receiver that can run production OpenPLi.  That will allow me to better test my code submissiond for OpenPLi.  At the moment the code has tested well on my OpenViX and Beyonwiz boxes.

 

If something goes wrong just let me know and I will quickly address the problem.

 

Regards,

Ian.

Edited by IanSav, 1 April 2019 - 11:31.