37 replies to this topic

[mfaraj57]

@littlesat

VirtualKeyboard.py is not holly module and written by god so what is the problem if we can use flexiblity of python to play with it and changing some structures , of course if we know what to do.

[mfaraj57]

@Taapat

sorry ,i misunderstood you,i understand just to change the system skin_default.xml which i cannot do.

[littlesat]

it is better to get in there what you want. This starts by discuss here what you need. Much much more better then implement a quick class stealing hack. It is better to get a good fix instead of having it just working

Edited by littlesat, 4 September 2018 - 07:23.

[mfaraj57]

 

 

It is better to get a good fix instead of having it just working 

yes this is what i amy trying to do by putting the question here  but i got what you do not like.

I do not know the intentions of who put the skin.py module by giving the priority for the screens defined in skin_default.xml and ignores any peripehral module local requests to modify the screens.But seem to me the opposite is more reasonable by giving the priority for local requests to modifiy the screens,so in this unreasonable situtation may use tricky way to do things.

Edited by mfaraj57, 4 September 2018 - 07:40.

[IanSav]

Hi,

 

Please note that VirtualKeyBoard.py is shared by a number of images.  Hacks like this should not be accepted where it creates differences for no good purpose.  I don't understand why a skin can't be changed yet the core code is seen to be an easy fix.  Can you please explain why VirtualKeyBoard can't be re-classed and a custom screen added?

 

It is hacks to the code that lead to the mess that prompted me to rewrite VirtualKeyBoard in the first place.  Now that the code is clean putting in new hacks is the start of a downward spiral to more code dilution and rot.  If you really want to modify VirtualKeyBoard and re-classing it doesn't work then please create your own version and leave the shared copy alone.

 

Please don't hack VirtualKeyBoard.

 

Regards,

Ian.

[IanSav]

Hi Mfaraj57,

 

If your issue is with how skins are selected and processed then please ask this question and not break VirtualKeyBoard.

 

There are a number of bugs with skin processing in OpenPLi.  Correcting these problems is where the attention should be directed.

 

Regards,

Ian.

[samsamsam]

@littlesat, @IanSav

 

It looks that you are not understand. 

The skin is not the only thing @mfaraj57 will need to modify in the VirtualKeboard component.

 

As you can see he also want to apply the suggested word by pressing red button. 

So regardless of the skin, he must modify python code.

 

At least that's how I understood it from the beginning.

Edited by samsamsam, 4 September 2018 - 07:54.

[samsamsam]

Yes it looks he wants this... at least SSS is suggesting it...
And exactly these kind of structure to steal functions and classes might break things at once...

 

It proves that you did not read first post. In the first post @mfaraj57 show modified VirtualKeyboard source file with added custom skin and ask how to force E2 to use the this embeded skin.

This was the question. Am I right?

 

The question if he should or not modify system component. This is another matter. But this in not what he asked about.

Edited by samsamsam, 4 September 2018 - 08:04.

[IanSav]

Hi Samsamsam,

 

It is not appropriate to change shared core code to create a custom function.  Normally this is done by sub-classing the core code and changing the new instance.

 

I still don't understand why this is not possible.

 

Regards,

Ian.

[samsamsam]

@IanSav

 

I agree but @mfaraj57 did not ask about this.

[samsamsam]

@mfaraj57 already wrote about this.

 

Thanks Ian and Taapat
I think you suggested same idea about importing VirtualKeyBoard class to my customized class.
This way is good if i want to use virtual keyboard in my plugin but i do need this,i want to edit virtual keyboard screen in the system file Screens.VirtualKeyBoard.py and keep the file name as it is also the name of class VirtualKeyBoard.
But your suggestion make me to think to do in opposite way by importing my screen class to virtualkeyboard class.

 

So, in my opinion all such posts like yours and @littlesat are offtop.

Edited by samsamsam, 4 September 2018 - 08:31.

[IanSav]

Hi Samsamsam,

 

This is why we need to explore what is really required and not simply hack in a solution to the current perceived issue.    We need to try and keep the code clean and modular.  Hacks will only come back to haunt us in the future.

 

Regards,

Ian.

[samsamsam]

This is an another offtopic post.

 

@mfaraj57

Do not want to modify repository source code, so this change is not to be pushed to the git repo.

 

Anyway it will be good to have for example some switch in the screen class definition which will tell skin.py if it allow or not to be skinable.

In others words if the screen class will have __class__.sikinable set to False (the default value should be True) then skin processor should not search for others skins but use skin from the object skin member.

 

This is something which OpenPli team can consider to add to the repository.

But this is still offtop.

Edited by samsamsam, 4 September 2018 - 08:52.

[mfaraj57]

Seem the only persons understood me fully in this thread are samsamsam and Taapat.

I do not have intetion to make repository source code,or to make my changes public or to include the changes in plugin.

Since begining i avoided to say my reasons because it is unimportant to you and may appear selly.

I want to add history of typed words to avoid retyping word another time but just press red and then ok to select from the history list ,lets say this is very helpful for my old parents especially with long words,sure i will not bother public forum for sake of my parents but it is good question so i put it here and the answers will be very helpful to beginners and developers.

However i do not see why adding  typing history list or google suggestion list to virtualkeyboard are serious or at least make options to use them or not.

we have to admit that virtualkeyboard is still deficient and  this make many plugins avoid using and use customized local virtalkeyboard(youtube,mediaportal,Tappat youtube and many others except samsamsam IPTVplayer which still using system vkeyboard).

 

 

Anyway it will be good to have for example some switch in the screen class definition which will tell skin.py if it allow or not to be skinable.

In others words if the screen class will have __class__.sikinable set to False (the default value should be True) then skin processor should not search for others skins but use skin from the object skin member.

Totally agree with you and i think this good solution to avoid illegal hacking or tricky solutions in such situation.

[IanSav]

Hi,

 

I'm sorry but I thought my attention to this thread was requested because changes were needed for the core VirtualKeyBoard.py code.  It now appears that this is not the case.

 

If there is any need for my assistance with the new VirtualKeyBoard then please come to the appropriate thread: https://forums.openp...ance-requested/ and ask.

 

Regards,

Ian.

Edited by IanSav, 4 September 2018 - 12:21.

[samsamsam]

 

 

As you can see he also want to apply the suggested word by pressing red button. 

So regardless of the skin, he must modify python code.

 

The recommendation you suggested are not done...

He can create an additional screen for his needs als follow:

 

class ModifiedVirtualKeyBoard (VirtualKeyBoard):

 

and add/change functions that he requires for the word-selection there...

 

And much much more better try to arrange that it is added in the current code.... Avoid the tricky trick stealing thing!

 

 

@littlesat

You have a big problem with reading and understanding.

 

Did you read this or not?

 

 

@mfaraj57 already wrote about this.

 

Thanks Ian and Taapat
I think you suggested same idea about importing VirtualKeyBoard class to my customized class.
This way is good if i want to use virtual keyboard in my plugin but i do need this,i want to edit virtual keyboard screen in the system file Screens.VirtualKeyBoard.py and keep the file name as it is also the name of class VirtualKeyBoard.
But your suggestion make me to think to do in opposite way by importing my screen class to virtualkeyboard class.

 

So, in my opinion all such posts like yours and @littlesat are offtop.

 

[samsamsam]

What a man. 

 

@littlesat  please don't embarrass yourself.

Read, read, read! At first read, then write your answer.

 

@mfaraj57 wrote

i want to edit virtual keyboard screen in the system file Screens.VirtualKeyBoard.py

 

Did you read this? Do you understand this?

Edited by samsamsam, 4 September 2018 - 14:13.

[littlesat]

Being short... I stop discussing with you!