I'm having a quick squiz at the code now. I'll post my comments as I go...
First a general comment about code style and conventions. As you probably noticed, the enigma2 source code is a mess. Which is a shame, because the Python programming community has quite a good set of guidelines for these things. These guidelines are known as
PEP8. There are even tools to check your code and suggest improvements. Both prl and myself tend to run our code through the PEP8 checking tools to help us. If you haven't already done so, I suggest that you do the same. Of course, you should also have a read of PEP8.
In terms of conventions, there are different naming schemes for classes, variables and functions. These conventions usually cover things such as verb/noun usage and capitalisation. It may be the case that the Python conventions are different to those you may be used to in other programming languages.
As an example, PEP8 suggests that "Modules should have short, all-lowercase names." Since the OverlayHD plugin is a Python module, it should have been all lower case. Similarly, "Class names should normally use the CapWords convention." and "Function names should be lowercase, with words separated by underscores as necessary to improve readability." Now, with enigma2 source code, this could become a bit of a problem, because the base classes will most likely use "mixedCase". I think that's mainly because a lot of the Python code is built on top of the C++ libraries, which use those conventions. It's up to you whether you are happy with either mixing two conventions (which would help you detect whether you are dealing with an enigma2 function vs your own) or whether you will stick with the enigma2 convention all the way (which gives you consistency in your code).
It's probably too late to change OverlayHD now, but it's something to keep in mind for the future.
Debug output "print" statements are fine for development and beta code (or code that often gets unexpected results), but as the plugin matures you should comment out the remaining debug "print" statements so that the logs are not too noisy. Even better, you may wish to replace simple "print" statements with conditional versions so that you can turn debug logging on/off with a variable.
You do not need to use setValue() and getValue() on config. entries. You can just say config.blah.value = 5
In buildColour(), are you sure about this?
Code: Select all
return gRGB(colorNames[colour.getValue()].argb() | trans)
I suspect you may want to mask out the old alpha value and replace it with the new one, rather than just set additional bits.
With the help of a friend and lots of wasted effort and time I finally got to where it is now. (The problem was that the clone and sync were not connecting with the source cache on my NAS.)
(Edit: It looks like GeneralMenu is a bit better behaved after Prl's cleanup but it is still chatty. 