IanSav

Hi,

Okay, here is a prototype of a Python API that could be used to manage the boxinfo data.  I suggest that this become "Tools/BoxInfo.py".  Currently there are 4 proposed methods "loadBoxInfo()", "getItem(key, default)", "setItem(key, value)" and "deleteItem(key)".

1. loadBoxInfo() reloads the "/etc/enigma2/boxinfo" file.  This is automatically done when the code first loads but the method can force a reload at any time.
2. getItem(key, default) returns the current value of the item key if it exists or default if it doesn't.
3. setItem(key, value) sets the key to value.  Returns True if it worked or False if that key is immutable.
4. deleteItem(key) deletes the key.  Returns True if it worked or False if the key did not exist or is immutable.

The keys should be the text strings that we previously discussed in "boxinfo.txt" file.

This code could either replace the SystemInfo module or else compliment it.

What do people think?

Regards,

Ian.

Hi,

There seems to be some comment about developer support for Enigma2 images.

One of the recent frustrations in new code development is the fact that hardware developers seem to want to keep the codes that their remote control drivers emit into Enigma2 a secret.  This is ridiculous!  All manufacturers should be expected, demanded, to document exactly what every button on their remote control emit, as a KEY_xxx code, into Enigma2.  It should not be up to Enigma2 developers and support people to scramble to find access to *EVERY* box and to painstakingly work out and document the button codes so that the hardware can be supported by their image.  Similarly any special modes like SHIFT buttons or any buttons that change they codes need to be properly documented.

Further, if the drivers are to be provided as a closed source binary then it should be demanded that the manufacturers *must* allow a button translation may be enabled for all their remote control (and front panel) drivers.  That is, Enigma2 developers should be able to adjust the KEY_xxx codes for every button on the remote control and front panel so that the Enigma2 firmware can be simplified and optimised.  The current need to bloat the key maps and action maps to make all the different remote controls work should be seen as inappropriate and wrong.  This will also formally allow firmware developers to reassign buttons to better support Enigma2.  For example, I would dearly love my GigaBlue UE 4K to remap the physical F1 button to emit the KEY_HELP code.  This remote control doesn't have a HELP button at all which very much damages the Enigma2 usage experience.  I think there are many examples where productive use could be made of uniformly enabling button remaps.

For example, to enable button remapping all the drivers should be made to have two mandatory function calls.  One should deliver a list of integers that are the KEY_xxx codes for that remote control presented in a documented order, probably top left to bottom right.  The other function call should be take an appropriate list of KEY_xxx codes and load that into the driver.  From that point any button press on the remote control should only emit the KEY_xxx code as requested by the firmware.

It may be difficult for the remote control driver to keep the updated list across firmware restarts but then it would be very easy (I have already prepared code) to load the driver remap data on Enigma2 startup.

So, if hardware manufacturers really do want to support the images and the developers let them start with this relatively simple request.

If this question is too far off topic I am happy for this post to be deleted.

Regards,

Ian.

Hi,

I am not going to make specific quotes but I am concerned when people talk about using some of this information to make decision on how Enigma2 may operate.  In particular I strongly object to code that says something like if this is box model x, or model y then do something special.  This is maintenance insanity.  All these decisions based on hardware differences should *NEVER* be exposed to any part of Enigma2.

I believe this should be done by providing a list of features and then making Enigma2 decisions based on the feature (and NOT the box that may or may not offer it).  For example, I think it better to know if a box has a front panel power led, does it have a HDMI input, does it have a LCD/OLED front panel display, does it have a 7 segment LED display etc.  How this information is determined should be totally irrelevant to the bulk of Enigma2.

In Enigma2 I would like to only see code like if this box has a 7 segment LED then do something.  If this box has a HDMI input port than include this menu etc.  There should be no mention of the box brand, make model or anything else specific about the hardware *anywhere* in the bulk of Enigma2.  All we should be interested in is features.  This is something that boxbranding has tried to do.  Unfortunately coders still manage to abuse boxbranding to do the wrong things.

It is fine to talk about an API and other implementation details but I think we should be making an effort to define what we need to know and how we want to gather and parametrise the data so that an appropriate API can be designed.

In my earlier examples I indicated that I want to know the display ready image name (Beyonwiz, OpenATV, OpenPLi, OpenVision, OpenViX, etc).  I also want to know the hardware manufacturer name (Beyonwiz, GigaBlue, VU+, Zgemma, etc) and the model name (T3, T4, U4, V2, DUO 2, UE4K, etc).  I want this information to add to display information for users.  As I suggested above, and has been somewhat done by boxbranding, we need to create a list of all the hardware features that may have an impact on what Enigma2 needs to know or can affect its operation.

In my opinion, we should be getting the list of what we need to know organised.  We then need to think about how that information should be presented.  Should it be a string, an integer a Boolean?  Then is it immutable or can the state or feature be changed.  Once we have a reasonably complete list of features that we need to track then we can decide how and where the API can be created.  We should also keep in mind that the list of features may change.  Some feature may fall out of use and others may be added.  The design must allow this sort of flexibility.

We need to understand the data and the needs for that data *before* an API can be defined and the data identification (access) indexes or labels can be created.  Once designed this *must* be standardised across *all* images.

Okay, I have had my little rant.    What do people think?  Should we start collecting a list of features that we need to manage?  If that is agreeable can we agree to start with the features exposed and listed by boxbranding and then fill out the list with any information that is not currently offered by boxbranding?

Regards,

Ian.

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.

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.

Hi Zeros,

OK, it would be good if these letters would go exactly on these positions, as posted by Mr.blzr (on post #427)
I do not know whether it is standardized and I have no clue as to how other languages could be.

That is exactly what I used for the template.

Regards,

Ian.

Hi Zeros,

The VirtualKeyBoard changes are done.  I will wait a little while to see if any other changes are requested before I commit this change.

Regards,

Ian.

Hi Adga,

Thank you.  I will raise a pull request with this new update. 

Regards,

Ian.

Hi Zeros,

Thank you for your supportive feedback.

Regards,

Ian.

Hi Zeros,

Attached are the corrected files.  You will need to install the keyboard images files into the correct location.  Follow the updated instructions and the crash should go away.

Please note that I am unable and unwilling to change all the skins out there to match the new VirtualKeyBoard code.  This should be  done by the appropriate skin maintainers.  The shin changes in the test kit are simply a guide on what could / should be done.

Regards,

Ian.

Hi Huevos,

The thing is you are complaining about the services and picons. But that is not relevant. Only the transponder parameters are of any interest to us. Anyway no point complain that the data is wrong but not correcting it.

What a rude and unhelpful comment.

I was not complaining about the data as I don't and can't use it.  I simply pointed out that the reference source for all the satellite data may not always authoritative or correct.

I also pointed out that it was inappropriate for me to correct the data as I can't receive or test the signal so I can't verify what is actually going on.  As a believer of providing accurate and reliable information it would be contradictory of my standards to provide information that I cant verify or substantiate.

If you are offering to supply and fit all the satellite equipment required to receive these signals then I would be happy to provide verified corrections.

Regards,

Ian.

Hi All,

While I can't run a proper OpenPLi development image yet I have tried to tweak VirtualKeyBoard to run on OpenPLi without changes.  I have attached an updated patch kit for OpenPLi developers / testers to try out.  This version is changed and further improved from the previous version I posted on 21-Jun-2018.  I would like to apologise in advance if I have misrepresented your language.  I mean you no offence and am simply showing that I only know English (and I often much that up too  ).

Can all users who try out this test code please give me feedback.  Are you happy with the changes?  Should anything be fixed?  Should anything be changed?  Can anything be improved?

In particular I want all the various languages, other than English, to be fully checked out and tested.  Are all the characters needed present?  Are there any incorrect characters?  Should any of the characters be moved to more appropriate locations?  Also, are any languages missing that should be added?  Should any of the provided languages be removed?

I would very much appreciate if I can get some testing done on this code.  I would like confirmation that what I have done is acceptable for all the languages provided.  If all goes well I will submit the code for inclusion into the firmware.

NOTE: To make this code work in OpenPLi I have forgone the auto image location facility offered by SCOPE_ACTIVE_SKIN.  I am very much hoping that the OpenPLI image managers will consider changing Directories.py to add this most helpful feature.  (I would prefer that SCOPE_CURRENT_SKIN is enhanced to offer the facility of SCOPT_ACTIVE_SKIN rather than simply adding the duplicated method.)

Regards,

Ian.

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.

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.

Hi Zeros,

Here are the draft Swedish and Finnish layouts for checking / correction.  For each language please tell me if any characters are missing or if there are too many characters.  Also mention is any characters are in incorrect places.  (I have taken the liberty of moving a few characters to reduce the number of keymaps.)

Regards,

Ian.