998 replies to this topic

[zeros]

It doesn't matter from my side. I liked both the colors. The new graphics is good (imho). The Best keyboard in the neighborhood. For me these colors OK.

[ims]

it is a question, if littlesat saw to HD or to FullHD -PLi skins ... FullHD skins have PLi's background, HD skins have Ian's background in VK.

[IanSav]

Hi,

 

I am now confused.  Do people want to keep the new muted highlight colours or should I revert to the brighter original colours?

 

Regards,

Ian.

[ims]

no matter on it ... i am using FullHD skins and there I have own background

[Rob van der Does]

Hi Rob,
 
If you have a strong objection to the iconography I can look at providing alternatives.  (For example, I could add a Setup screen to allow some of the options to be changed by users.)
 
Regards,
Ian.

Well, I really would like that. But if I'm the only one, I wouldn't bother.

[Taapat]

@IanSav that's what I wrote before.

Why I am against the introduction of additional icons.

 

If you create your own skin, you want everything to look different, in your skin design.

Of course, if you are satisfied with the design by default, you can use it.

But if you satisfied with the design by default, why make own skin?

 

Therefore, if you change all the buttons, add additional images, you put extra work on skin developers.

And is not important as the images look by default. If they don't fit your skin concept you will need make your own.

[IanSav]

Hi Taapat,

 

The reason I moved to icons was because translations for the English text buttons was causing problems fitting into the space available.  Icons transcend languages.  Pick up any Android or Apple phone many / most of the controls are now represented by icons.

 

Any skin designer is totally free to change any and all images for the VirtualKeyBoard.  They also have controls in the skin parameters to change other aspects of the display.  I believe I have provided more than enough controls and tweaks to allow any skinner to make the VirtualKeyBoard look the way they want.

 

I will consider adding the Setup screen but that won't be considered until after I complete the Setup refactor.  (I would use facilities in the new Setup to make the VirtualKeyBoard Setup screens efficient.)

 

Regards,

Ian.

[ims]

@Taapat - all FullHD skins can use own graphics for VK in SKIN/buttons directory ... default skin's graphics using HD/SD skins.

I do not see here problem.

Edited by ims, 5 April 2019 - 13:10.

[WanWizard]

If you create your own skin, you want everything to look different, in your skin design.

Of course, if you are satisfied with the design by default, you can use it.

But if you satisfied with the design by default, why make own skin?

 

Therefore, if you change all the buttons, add additional images, you put extra work on skin developers.

And is not important as the images look by default. If they don't fit your skin concept you will need make your own.

 

I don't really agree with this.

 

Are you suggesting we can't and shouldn't improve the default because it makes it more complex for people who want something other that default? That seems to me like the world upside down?

[IanSav]

Hi,

 

I have attached a revised and complete set of VirtualKeyBoard images for 720 and 1080 skins with both black and white versions.  I would like people to have a look at these images and test them on various systems to see if they are acceptable to be committed into the repository.  The only deliberate change to the images is to use a slightly darker version of the original highlight colours.

 

Please note that these images have been compressed with a new tool that I have never used before.  This new tool appears to compress the images even more than the online tool I was using previously.  (That site is down at the moment so I needed to find an alternative in a bit of a hurry.)  I would like to be sure there are no odd side effects of the newer image compression.  If the images are acceptable we can update the repository later.

 

Regards,

Ian.

Attached Files

•  VirtualKeyBoardImages.zip   43.06KB   1 downloads

Edited by IanSav, 5 April 2019 - 14:24.

[Taapat]

I am writing about backward compatibility.

You can create a new design with respecting backward compatibility or completely ignore as it is in this case.

About this also pointed MCelliotG in comments at this commit: https://github.com/O...7d1e61b450ecc04

 

Why do you need to change names for all buttons instead of adding some missing ones?

Why do you need change the keyGreen to style and call the GSOD in plugin EPGSearch?

 

Improvements can be added bat needs respect others. And make a radical change only in case if is not possible backward compatibility.

 

But I know it will be ignored here and therefore I not see reason to spend not my time not IanSav time and discuss about it.

[WanWizard]

But I know it will be ignored here and therefore I not see reason to spend not my time not IanSav time and discuss about it.

 

Why? I think backward compatibility, if possible, is important, so you may have a point there.

 

I can't judge if these improvements can be made while maintaining backward compatibility, sometimes it's not possible and a choice has to be made between compatibility and progress...

[littlesat]

Or the same names should be used. Or the broken plugin (when sources available) should be adapted...

 

IanSav tries to define better and clearer descriptions... but then always in E2 something might get broken...

 

What is needed to repair the epgsearch plugin? What is the exact 'crash'...

Edited by littlesat, 5 April 2019 - 15:24.

[IanSav]

Hi,

 

Sorry but I am getting very confused and frustrated.  The latest version of the VirtualKeyBoard code has required NO skin XML changes.  The new images are quite happy to reside beside the previous images.  Where has all this issue about backward compatibility come from?  All my changes have been documented in the revised VirtualKeyBoard documentation.

 

This VirtualKeyBoard update was a fluid and natural progression from my previous version.  All the internal label changes have NOTHING to do with compatibility of the VirtualKeyBoard code.

 

This wishy washy swaying in the breeze is ridiculous.  Does OpenPLi want contributions of code enhancement or not?

 

Regards,

Ian.

[littlesat]

This is not about we want it or not... This is about a plugin (EPGSearch) that now crashes on the latest changes, it seems this plugin is a good used plugin... and we need to consider to adapt the plugin and/or the virtual keyboard feature...

[IanSav]

Hi Littlesat,

 

From what I can see Taapat changed an OpenPLi private version of EPGSearch to use an undocumented change he made to VirtualKeyBoard.  The new calling parameter is a translated fixed text string.  What a poorly thought out command parameter to pass between modules.

 

I checked the VirtualKeyBoard documentation in the OpenPLi repository and there have been NO changes since I wrote the original versions.  I looked at the OpenPLi VirtualKeyBoard code before I offered my changes.  All I can say is that I found the code an unreadable mess.  The code certainly did not function correctly.  I saw no point in trying to unravel the mess to implement my completely functional upgrade.  All my changes have been clearly documented.

 

When my new receiver arrives I will be able to run a production OpenPLi image.  I will then be able to test my code in an OpenPLi environment and then potentially pick up these code aberrations.

 

Rather than making these pot shot criticisms why wasn't my documentation used to fix the calling parameter and just move on.  SIGNIFICANTLY more effort has been expended whinging and responding to the complaints then would have been required to fix the actual issue.

 

Regards,

Ian.

[WanWizard]

Ian,

 

Without looking into it in detail, you may have a point here.

 

We really need to think about a way to get the community together, put all ego's aside, and redesign / rebuild Enigma.  As an (ex) professional programmer and designer, I cringe every time I have to look at the code.

 

Apart from the fact it's 15+ years old and not really fit for purpose anymore, it's design and architecture is complete and utter crap. With globals, global functions and global classes everywhere, and everything poking into the internals of everything else. With proper abstraction and encapsulation, these issues would not be possible.

 

But I fear it's wishful thinking...

[IanSav]

Hi,
 
I just tried to commit the small fix required to EPGSerach.  Unfortunately the source code contains ISO-8859-1 characters that must be changed to UTF-8!  This is creating a change to the code that I do not wish to make.
 
To fix the code change line 16 from "from Screens.VirtualKeyBoard import VirtualKeyBoard" to "from Screens.VirtualKeyBoard import VirtualKeyBoard, VKB_SEARCH_ICON"[/background] and line 779 from "keyGreen = _("Search")" to "style=VKB_SEARCH_ICON".

 

Regards,

Ian.

[IanSav]

Hi Littlesat,

 

If the source code was quickly editable (without binary characters) the whole fix would have taken about 20 seconds!  I tried to make the change using the GIT web interface and it objects to the file's contents!  The characters on line 751 are being changed by the GIT editor.    Now you can see why I took all the binary characters out of the VirtualKeyBoard code.  The VirtualKeyBoard is fully editable in ANY editor!

 

Regards,

Ian.

Edited by IanSav, 5 April 2019 - 16:12.

[Abu Baniaz]

Try using Sourcetree. You can edit files with whatever editor you prefer to use.