HelpMenu.py question...

[IanSav]

Hi Prl,

Is there a specific reason why the HelpMenu code in the showHelp() method specifically looks for the SecondInfoBarScreen and closes it if it is open? (This is also in OpenViX but not in OpenPLi.)

Regards,
Ian.

[prl]

Is there a specific reason why the HelpMenu code in the showHelp() method specifically looks for the SecondInfoBarScreen and closes it if it is open? (This is also in OpenViX but not in OpenPLi.)

I'm not sure. It was put there a long time ago and logged to Paul In & In in 2012 (I think that In & In did the original port of enigma2 to Beyonwiz). The code was originally:

Code: Select all

		if self.secondInfoBarScreen and self.secondInfoBarScreen.shown:
			self.secondInfoBarScreen.hide()
			self.secondInfoBarWasShown = False

The only comment on the checkin was the fairly obvious "HelpScreen: close 2nd infobar if open." One of my pet peeves is checkin comments that just say in words what the diff shows.

This was changed 12 days later by Paul In & In to:

Code: Select all

                try:
                        if self.secondInfoBarScreen and self.secondInfoBarScreen.shown:
                                self.secondInfoBarScreen.hide()
                except:
                        pass

With the commit log message: "HelpMenu: fix possible BSOD." The reason for catching the exception is simple - the code would crash if the HelpableScreen was used in any class other than InfoBar. It's not explained why the self.secondInfoBarWasShown = False statement was removed.

I think that's longhand for "I don't know," but commenting the code out doesn't seem to do anything obviously bad.

[IanSav]

Hi Prl,

That was my finding as well. I thought it better to ask.

I am preparing a port of your help improvements for use in OpenPLi and OpenViX. With all the extra help screens I am adding to their code they are starting to notice how poor was their original help system.

Regards,
Ian.

[prl]

With all the extra help screens I am adding to their code they are starting to notice how poor was their original help system.

Yes, it was in pretty poor shape when I started work on it. It was probably little used because it wasn't all that good.

BTW, I think the code I wrote to do the button indicator movement animation in MovingPixmap is overcomplicated and should just use floating point arithmetic to calculate the intermediate points, and toss all the integer-only code that uses a modified Bresenham's line algorithm.

[IanSav]

Hi Prl,

I would like this to go in with minimal change to minimise future merge issues. (VirtualKeyBoard.py and NumericalTextInput.py have been coded to be identical for all images.) If you want to tidy up the Beyonwiz version then I will simply track your improvements across the other images.

Regards,
Ian.

[prl]

OK, I'll have a look at it over the weekend.

[IanSav]

Hi Prl,

If you want to really simplify the code you could leave out the animation. If I remember that was how it was previously. Either way, I will follow your lead.

Regards,
Ian.

[prl]

If you want to really simplify the code you could leave out the animation. If I remember that was how it was previously. Either way, I will follow your lead.

It's what's implementing the animation that's changing, not the use of animation in the Help screen. It's putting Components.PixMap.MovingPixmap back to closer to what it used to be.

[prl]

BTW, I think the code I wrote to do the button indicator movement animation in MovingPixmap is overcomplicated and should just use floating point arithmetic to calculate the intermediate points, and toss all the integer-only code that uses a modified Bresenham's line algorithm.

Submitted.

[prl]

BTW, I think the code I wrote to do the button indicator movement animation in MovingPixmap is overcomplicated and should just use floating point arithmetic to calculate the intermediate points, and toss all the integer-only code that uses a modified Bresenham's line algorithm.

Submitted.

Merged and in firmware 20180825.