998 replies to this topic

[zeros]

Norway / Norwegian here:
https://gate2home.co...wegian-Keyboard

Edited by zeros, 18 June 2018 - 18:47.

[IanSav]

Hi Ims,

 

I will add/correct cs_CZ when it wll be merged... I have not idea yet, how replace chars for 3 dead keys...

 

Here is a Czech keyboard layout for your review.  Please let me know if this is correct or needs adjustment.

 

Regards,

Ian.

 

Attached Files

•  cs_CZ0.jpg   194.75KB   2 downloads
•  cs_CZ1.jpg   226.77KB   2 downloads
•  cs_CZ2.jpg   216.51KB   2 downloads

[IanSav]

Hi Zeros,

 

Norway / Norwegian here:
https://gate2home.co...wegian-Keyboard

 

It is very early morning here so I want to get some sleep.  I will work on the Norway layout when I awake.

 

Regards,

Ian.

[zeros]

Yes, I know, my old aunt living near Sydney in Australia. ;-)

[Persian Prince]

Hi Persian Prince,
 

Here is another small fix:
 

], [
    [u"\u00F7", u"\u06F1", u"\u06F2", u"\u06F3", u"\u06F4", u"\u06F5", u"\u06F6", u"\u06F7", u"\u06F8", u"\u06F9", u"\u06F0", u"-", u"=", u"BACKSPACE"],
    [u"FIRST", u"\u0636", u"\u0635", u"\u062B", u"\u0642", u"\u0641", u"\u063A", u"\u0639", u"\u0647", u"\u062E", u"\u062D", u"\u062C", u"\u0686", u"\u067E"],
    [u"LAST", u"\u0634", u"\u0633", u"\u0649", u"\u0628", u"\u0644", u"\u0622", u"\u0627", u"\u062A", u"\u0646", u"\u0645", u"\u06A9", u"\u06AF", u"ENTER"],
    [u"SHIFT", u"\u0638", u"\u0637", u"\u0698", u"\u0632", u"\u0631", u"\u0630", u"\u062F", u"\u0626", u"u0621", u"\u0648", u"\u060C", u"\u061F", u"SHIFT"],
    [u"EXIT", u"LOC", u"LEFT", u"RIGHT", u"ALL", u"CLR", u"SPACE"]
]

So all you want me to change is to delete the glyph u"\u061B" from the left of the ENTER button? Should it appear somewhere else?
Regards,
Ian.

Yeah because I had a missing "," between 'u"\u0622" u"\u0627"' so it appeared as one and we both thought there is one character short and I did add an extra one, now it's fixed and no need for any extra character

Regards,
Persian Prince

[IanSav]

Hi,

 

Okay it is time for the chick to leave the nest...

 

I have attached a ZIP file that has the files and the instructions for trying out the new VirtualKeyBoard for yourselves.  This is a chance to try the changes out and offer feedback and suggestions *before* the code hits the repositories.  The file README.txt has the instructions.  The file VIRTUALKEYBOARD explains the changes.  There are sets of the additional images for both 720 and 1080 skins.  The sample skin changes will be what goes into the default_skin but are an indicative template of what changes the various skin maintainers will need to change in their skins if/when the code is adopted.

 

Please note that the instructions are complete but not comprehensive for a newbie.  You should be familiar with Enigma2 internals, moving files in the file system and editing files before you should consider trying out this sneak-peak.  I want to put the code out there so I can get feedback on the changes and also get input into any changes or corrections that may be required.

 

If you try this out please post your feedback.  Positive and constructive negative comments are all welcomed.

 

Regards,

Ian.

 

Attached Files

•  VirtualKeyBoard.zip   29.97KB   7 downloads

[ims]

If you want test it under PLi, you must create it under PLi ... PLi using : SCOPE_CURRENT_SKIN instead ACTIVE...

then in VK must be png as (SCOPE_CURRENT_SKIN, "skin_default/buttons/vkey_bg.png") or (SCOPE_CURRENT_SKIN, "skin_default/vkey_bg.png")

Edited by ims, 21 June 2018 - 13:19.

[IanSav]

Hi Ims,

 

Unfortunately OpenPLi don't support my hardware so I am unable to maintain an active OpenPLi development image.  Huevos built an image for me but as there are no updates available the image is now out of date and effectively useless.

 

It is a shame that there are so many artificial differences between the images.  I will explore what changes I can make to eliminate the issue.

 

Regards,

Ian.

[IanSav]

Hi Ims,

 

I tried swapping from ACTIVE to CURRENT.  While the code works the self defence mechanism in the ACTIVE code is not present in the CURRENT code.  That is, if the image is not correctly specified in the current skin there is no automatic fallback to see if the image is available in the default_skin.

 

This change will require significantly more vigilance from ALL skin developers.  Would it be acceptable to add the fall back enabled ACTIVE option to OpenPLi?  Alternatively would it be permitted to modify the CURRENT code to also check skin_default as a fall back for not finding the image in the current skin?

 

Regards,

Ian.

Edited by IanSav, 21 June 2018 - 15:08.

[ims]

but SCOPE_CURRENT_SKIN, "skin_default/buttons/vkey_bg.png" read vkey_bg.png from .../SKIN_NAME/skin_default/buttons => and it is fully skineable, because all PLi skins have skin_default directory and using it.

 

Your path /usr/share/enigma2/skin_default/buttons/ using skin_default, what is very very old SD dmm skin.

 

Btw - you can test it under old PLi image, because there in VK were not changes long time...

Edited by ims, 21 June 2018 - 15:56.

[Persian Prince]

You can compile a new image using https://github.com/P...etas/pli-extras

And if you want I can compile it for you

[IanSav]

Hi Ims,

 

Assume that "/usr/share/enigma2/skin_default/buttons/" exists and contains all the "vkey_*" images.

Assume that "/usr/share/enigma2/myskin/buttons/" also exists and contains all the "vkey_*" images.

 

With the code "resolveFilename(SCOPE_ACTIVE_SKIN, "buttons/vkey_bg.png")" the image will be found in the "myskin" location.  No problems.

With the code "resolveFilename(SCOPE_ACTIVE_SKIN, "buttons/vkey_backspace.png")" the image will be found in the "myskin" location.  No problems.

 

With the code "resolveFilename(SCOPE_CURRENT_SKIN, "buttons/vkey_bg.png")" the image will be found in the "myskin" location.  No problems.

With the code "resolveFilename(SCOPE_CURRENT_SKIN, "buttons/vkey_backspace.png")" the image will be found in the "myskin" location.  No problems.

 

Now remove the "vkey_backspace" image from "/usr/share/enigma2/myskin/buttons/".

 

With the code "resolveFilename(SCOPE_ACTIVE_SKIN, "buttons/vkey_bg.png")" the image will be found in the "myskin" location.  No problems.

With the code "resolveFilename(SCOPE_ACTIVE_SKIN, "buttons/vkey_backspace.png")" the image will be found in the "skin_default" location.  No problems.

 

With the code "resolveFilename(SCOPE_CURRENT_SKIN, "buttons/vkey_bg.png")" the image will be found in the "myskin" location.  No problems.

With the code "resolveFilename(SCOPE_CURRENT_SKIN, "buttons/vkey_backspace.png")" the image will NOT be found.  Big problems!

 

A number of skins rely on missing images being found in the "skin_default" location.  These will not work as intended on OpenPLi.  I would prefer to write the code so that there is a maximum chance that users will never see an issue.

 

What do you suggest we do to maintain maximum compatibility and reliability of the functionality?

 

Regards,

Ian.

 

[IanSav]

Hi Persian Prince,

 

You can compile a new image using https://github.com/P...etas/pli-extras

And if you want I can compile it for you

 

Thank you very much for the offer but unless developers can have live updates from the core development branch there is no point in wasting time continuously rebuilding the image.  I want to spend my time developing improvements for Enigma2 not waste my time by constantly rebuilding the platform to get all the changes.

 

On Beyonwiz and OpenViX I can access all betas and development code by simply running the online updates.  On OpenPLi this is not supported.

 

OpenPLi really need to make developing for OpenPLi easier if they want more people to contribute.  I am trying to keep OpenPLi on my development list but the many restrictions and limitations really do make it very difficult.

 

Regards,

Ian.

[WanWizard]

On Beyonwiz and OpenViX I can access all betas and development code by simply running the online updates.  On OpenPLi this is not supported.

 

It is, if you have an OpenPLi supported box. Only not publicly.  And we still don't build images for Beyonwiz, so you'd need a supported box to use that.

[IanSav]

Hi Ims,

 

I should add that a very important benefit of the "SCOPE_ACTIVE_SKIN" option is that skinners need only supply images that differ from the "skin_default".  This can save substantial space in the firmware image and make it available for other uses.

 

Regards,

Ian.

[IanSav]

Hi WanWizard,

 

 

On Beyonwiz and OpenViX I can access all betas and development code by simply running the online updates.  On OpenPLi this is not supported.

 

It is, if you have an OpenPLi supported box. Only not publicly.  And we still don't build images for Beyonwiz, so you'd need a supported box to use that.

 

 

Is anyone offering to give me a supported box that will work in Australia?  A VU+ Ultimo 4K or maybe the new VU+ Duo2 4K with a DVB-T/T2 FBC card would be nice.  The DVB-T/T2 card still does not exist and I am guessing that no-one is offering the rest of the hardware either.  I am not aware of any other Enigma2 boxes sold and supported in Australia.  Thus I have to continue to use what hardware I have available to me.

 

By the way, OpenViX also don't support Beyonwiz hardware but when I became an active contributor they ensured that my hardware was supported in their build system. 

 

Regards,

Ian.

[Huevos]

 

On Beyonwiz and OpenViX I can access all betas and development code by simply running the online updates.  On OpenPLi this is not supported.

 

It is, if you have an OpenPLi supported box. Only not publicly.  And we still don't build images for Beyonwiz, so you'd need a supported box to use that.

 

And anyone who wants to contribute to OpenPLi still has to build their own images even if using supported receivers. Why does PLi make it so difficult for us to push code back to PLi? I've been asking for this to be sorted out for months now. It used to be easy to contribute to PLi. Now there are three choices, be part of the PLi elite, or build PLi yourself, or just don't bother contributing anymore. Why does the developer build have to be non-public?

Edited by Huevos, 22 June 2018 - 00:47.

[IanSav]

Hi,

 

If anyone wants to use my evaluation code posted above please note that on OpenPLi you will need to replace all occurrences of "SCOPE_ACTIVE_SKIN" with "SCOPE_CURRENT_SKIN".  Please ensure that you have all the images in the correct place or else the code will not work properly.  ("SCOPE_ACTIVE_SKIN" has some enhanced code to try and find the images if they do not exist where expected.)

 

Regards,

Ian.

[zeros]

Thanks for you work and specsally for the

"et_EE": [_("Estonian"), _("Estonia"), self.estonian(self.scandinavian)]

I will let you know after tests. Instructions are OK, seems to me to be clear 

I will test in next week.

[WanWizard]

And anyone who wants to contribute to OpenPLi still has to build their own images even if using supported receivers. Why does PLi make it so difficult for us to push code back to PLi? I've been asking for this to be sorted out for months now. 

 

This has already been explained. A few times.

 

I only have one pair of hands, and due to health issues only limited time available to make those hands work. It is being worked on, but every time more urgent issues pop up that need to be addressed first. I understands that that frustrates you (it frustrates us as well), but here are only two options: more hands, or more time. Neither of which are available.

 

The develop image access mechanism has been made, it is currently tested by Pr2. A few issues have already been found that made access less smooth, and are being ironed out.