998 replies to this topic

[Huevos]

Thanks for the update. Sorry for moaning, but for me it is such a waste of resources tying up my build server building an image that is already being built elsewhere and is available behind closed doors.

 

Obviously in Ian's case it is a different issue because unfortunately he doesn't have OpenPLi supported hardware, so there is no option but to build it.

 

The other problem is he doesn't have sufficient hardware to dedicate a receiver to every image he contributes to.

Edited by Huevos, 22 June 2018 - 11:43.

[WanWizard]

I share your frustration. And Ian's case is being looked into at the moment.

[littlesat]

replace... '"SCOPE_ACTIVE_SKIN" with "SCOPE_CURRENT_SKIN".

 

When Who or what make a difference here... Active is somehow equal to Current in this context. At least it is not clear to me what the difference between them should be.

 

What is the exact difference between them... It could be one is newer but maybe an OE-A or even ViX invention... I do not prefer to adapt when it does not make any real additional sense... When there is a better functionality behind it we should simply arrange this functionality instead of change or add the 'new' name.... 

Edited by littlesat, 22 June 2018 - 13:48.

[IanSav]

Hi Littlesat,

 

"SCOPE_ACTIVE_SKIN" appears to be a copy of "SCOPE_CURRENT_SKIN" but with the added ability to search the "skin_default" directory if the image is not in the current skin directory.

 

I can't see a problem if my suggestion above is adopted.  "SCOPE_CURRENT_SKIN" becomes smarter and "SCOPE_ACTIVE_SKIN" becomes redundant.  Skins for OpenPLi can become smaller as they will be able share skin components from "skin_default" as well as skin specific elements.  For example, all the "vkey_*" buttons could come from "skin_default" but certain images could be replaced by being present in the skin's local directories.  An additional benefit is that more code should then be able to run transparently on more images.

 

Regards,

Ian.

[WanWizard]

If it reduces redundancy, I think it can only be a plus?

[IanSav]

Hi WanWizard,

 

If you haven't noticed, much of my efforts is targeted at improving the UI for users.  I try to also clean up any code I touch.  Part of the clean up is to try and make as much code as common as possible.  The more commonality we create the easier it will become to share code among the different images.  Having more common code will also make it much easier to maintain and merge the code with other images in the future.

 

I suffered extreme reluctance from OpenPLi to my Setup changes so I tried working on some of the associated code.  VirtualKeyBoard.py is the current example.  If this code is accepted I would love to have the same code on all images.  I worked very hard to ensure that all features from all images were incorporated into the freshly coded and optimised new version of VirtualKeyBoard.py.  If we need to update a few support libraries to make this happen then this should not be so difficult.  Once OpenPLi sees that I am only trying to make Enigma2 better for everyone I hope that this and the improved Setup.py, ConfigList.py and config.py code will also be more acceptable to OpenPLi.

 

Regards,

Ian.

[WanWizard]

Yes, I have.

 

I know it sometimes takes some time to convince Littlesat, know that it is not because he doesn't want to, but because he can't see in your head and has trouble visualizing your idea's. Perseverance is key...

[littlesat]

Skins for OpenPLi can become smaller

I would say... show me what you mean.... ... as I still don't fully get it... Through which subfolders are you 'searching' when it is not in the skin_default of the selected skin? As far I undersstood it always fall backs to the skin_default icons. So I still do not see why skins might get smaller, unless you scan 'randomly' through all skins subfolders.

[IanSav]

Hi Littlesat,

 

This is very hard to describe when you can't see the code and how it functions.  Can you run OpenViX?

 

Regards,

Ian.

[IanSav]

Hi Littlesat,

 

Did you read my explanation in the post to Ims: https://forums.openp...ndpost&p=900625

 

That is probably the best I can explain what happens without actually running some test code.

 

Regards,

Ian.

[Persian Prince]

@IanSav

 

Is there any news about this new keyboard?

 

Regards,

Persian Prince

[IanSav]

Hi Persian Prince,

 

Is there any news about this new keyboard?

 

Apart from any language corrections or additions the code is done.  The OpenPLi devs told me to hang on while they sort something out so I can test the code on OpenPLi.  (I have Beyonwiz hardware that is not directly supported by OpenPLi.)  I have not heard anything or been contacted by them in over three to four weeks! 

 

I also have the issue / desire that the OpenPLi Directories.py code get fixed / improved so that images not in the current skin can be loaded from the default skin.  I use this feature from OpenViX and Beyonwiz to save copying the standard images into EVERY skin.  :S

 

What do you suggest I do?

 

Regards,

Ian.

 

[IanSav]

Hi,

 

It looks like developer access to a build of OpenPLi for my hardware is not close, if one becomes available at all.  I am open to suggestions on how to proceed.

 

Regards,

Ian.

Edited by IanSav, 17 July 2018 - 17:34.

[Persian Prince]

@IanSav

 

I asked for help: https://forums.openp...ndpost&p=908599

 

Would you please tell me the exact model of your hardware?

 

Regards,

Persian Prince

[Huevos]

He is using Beyonwiz T3.

[IanSav]

Hi Persian Prince,

 

My main development platform is a T3.  It would also be helpful if the other boxes could be supported.  That is, add support the T2, T4 and U4 models.  I also own a T4 but I will never own a T2.  The U4 is new but I don't have one.

 

Regards,

Ian.

[Persian Prince]

@IanSav

 

Would you please test these images and confirm if they boot and work ok so we can provide you online feeds too?

 

beyonwizt3: http://www.mediafire...t3_usb.zip/file

 

beyonwizt4: http://www.mediafire...t4_usb.zip/file

 

Regards,

Persian Prince

[IanSav]

Hi Persion Prince,

 

Thank you for the files.  I will test them out over the weekend.

 

Regards,

Ian.

[IanSav]

Hi Persian Prince,
 
I have now had a chance to load the T3 image on my receiver.
 
The good news:

• The build appears to work fine.

The bad news:

• The service scan is wrong for Australia.  We have 7MHz bandwidth for each channel in both VHF and UHF.  One of the channels in the UHF band can't be found due to the 8MHz scan parameter.
• The broadcast channel list is out of date and incorrect.  Australia no longer uses UHF 52 - 69 for DVB-T.  Those frequencies have now been sold to other uses.  Scanning for Melbourne Australia scanned a lot of channels that are not used.
• The Australian picons are old and out of date.
• There are no online updates for the build.
• The are few plugins available.
• There is no option for the Beyonwiz remote control image / layouts.
• I have no SMB / Samba access to I can't access the image to install my test code.

There is probably lots more to report but there is not enough working for me to productively use this build.
 
I appreciate the efforts but this image is not really ready for use by a developer in Australia.
 
Regards,
Ian.

 

[IanSav]

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.

 

Attached Files

•  VirtualKeyBoard.zip   29.33KB   7 downloads