search

OpenPLi / enigma2

Framebuffer based frontend for DVB functions on Linux settop boxes
GNU General Public License v2.0
151 stars 203 forks source link

[Multiboot] use enigma.info for image details #4038

Closed Huevos closed 1 month ago

littlesat commented 1 month ago

See the discussion on the forum…. Better parse just one thing where an image could put in a string how they want to show the skin in the list. Also no need to collect the complete enigma.info string in a slot as you only need to find this one and only ‘parameter’.

Huevos commented 1 month ago

Like I said there, it is not backwards compatible, and in the shared *.bb recipe would be impossible.

littlesat commented 1 month ago

A shared bb thing is not needed…. ‘Only’ something added that made a string how the image should present itself in the imagelist…

Huevos commented 1 month ago

A shared bb thing is not needed…. ‘Only’ something added that made a string how the image should present itself in the imagelist…

You don't seem to understand. I am not talking about inventing a new recipe.

The *.bb is already shared between all oe-alliance distros. That is why the the output is uniform across oe-alliance. https://github.com/oe-alliance/oe-alliance-core/blob/5.4/meta-oe/recipes-oe-alliance/image/enigma-info.bb

littlesat commented 1 month ago

Maybe that makes it extreme easy to add a new string for all… something that should be done from the beginning…

Huevos commented 1 month ago

Maybe that makes it extreme easy to add a new string for all… something that should be done from the beginning…

Like I already said, it is not backwards compatible. That newly invented string would be missing in all previous images.

littlesat commented 1 month ago

Yep and that proves it was bad by design… and that is why a good design is mandatory and that proves Iansav should never pushed it. At the end users just want to have the image name and date it is updated. Version numbers upto endless digits is not of interest. Leave that to the about screen. My ancient code we have does give image name with low level version number via the issue file and date. Exactly what users want. Versions in deep diggers is maybe only value added for us as developers

IanSav commented 1 month ago

A few points for consideration:

  1. I tried to propose the design and code on the OpenPLi forum and was open to design input. As is well known there was no consensus or progress, just abuse, so I moved on. Rather than complaining about the design now, contributions to the design should have been contributed when I was trying to elicit input.
  2. I only committed the code to OpenATV where it was wanted and welcomed. Others took the code, modified it and implemented it on other images.
  3. The code I wrote uses the "enigma.info", "enigma.conf" as well as the "/etc/issue" files! The code being used on images other than OpenATV are not authored by me. The modified code may not follow my designs and may not consult the issue file. (Note that I only consult the issue file if the other sources of the information are not available.) Prior to recent changes to OpenPLi, to add the "enigma.info" file, my code obtained the data for OpenPLi from the issue file.
  4. If there are issues with my code, feedback has NOT been provided to alert me to any problems. It is open-source courtesy to acknowledge original authors of code and feed back to those authors where the code can be improved, optimised or fixed. I am not promising to change my code but I am promising to consider all feedback.
  5. My designs and code only provide access to the data as coded in each image's build system. I am in no way responsible for the various image version numbers maintained by the various images. If a simplified version number is required then either correct the source data or else we can defines a new variable, "displayversion", that can hold a shorter and perhaps more meaningful version number.
littlesat commented 1 month ago

You tried indeed to propose and design.... and the thread became silent. And I understand you picked it up and hammer it in after switching for the x time to a different team. But as you can see this results in a non-optimal situation again....

Huevos commented 1 month ago

@littlesat I am just working with the tools available to me. If the output needs tweaks that can be done.

IanSav commented 1 month ago

You tried indeed to propose and design.... and the thread became silent. And I understand you picked it up and hammer it in after switching for the x time to a different team. But as you can see this results in a non-optimal situation again....

The thread became silent when the OpenPLi moderators refused to moderate the abuse being dished out in the thread.

My team associations are totally irrelevant and have little bearing on my code and vision for Enigma2 which has been virtually unchanged since I first got involved with Enigma2 very many years ago.

Can you please explain how my code is non-optimal on OpenATV, for where it has been designed and coded? If there are issues with my code, as written by me or the OpenATV team, then please raise issues on the OpenATV GitHub issues area or you can contact me directly. If the issues are with derivative versions of my code then please complain to the authors of the derivative code.

If there are no specific details of any real issues with my code then I would appreciate you not mentioning me or my code in disparaging terms.

Huevos commented 1 month ago

@IanSav No one is complaining about the BoxInfo code, and anyway Littlesat has rewritten that code in OpenPLi how he wants it... What he is talking about is the data in enigma.info where there are small differences between distros. With oe-alliance/enigma-info.bb all oe-alliance distros use the same recipe so the result is pretty close, but what others show is up to the distro.

WanWizard commented 1 month ago

We have exactly the same BB recipe (https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-openpli/enigma2/enigma-info.bb, tailored to our environment) and @neo-pli-bsps and I have made all the required changes to the the BSP. Moaning about this imho is a waste of breathable air...

The only point that can be made, and which I made, is the lack of documentation and specification. As long as it is not clear what key contains what kind of value (like the forum discussion about imagedevbuild, must it be a 3-digit number or not), you can wait for python exceptions to happen, because everyone is basically free to put whatever values in the file.

For me this is all water under the bridge, we've agreed to become compliant, we implemented it all, and it is in our interest to so do, if we want plugins to remain compatible.

IanSav commented 1 month ago

Unfortunately, documentation has ended up being a lower priority. There are a number of new features and bug fixes we are committed to making and finishing at the moment. Clearing the issue lists is also a high priority.

Another developer, an English speaker, offered to help update the language and documentation with us but they have, so far, not come forward to do the task. Unfortunately, even so, the documentation has priorities. We need to document the new graphical engine and skin XML templates first before any other documentation. I suspect that the documentation needed by the most people will be done first. There are more skinners than developers so they will be getting more attention.

If no-one steps in to help I will be adding more documentation as and when time permits. Sorry I can't get to this faster but developer resources are very limited.

If it helps, there is some initial documentation on BoxInfo here: https://github.com/openatv/enigma2/blob/master/doc/BOXINFO. We are open to enhancement requests and corrections to this documentation.