Console (screen) improvements

[Jason Hood]

Since some of my changes to Screens.Console have already been declined, I’ll discuss them in this issue, before trying to submit them again.

‌

Tidy up: an earlier version of this was declined because of potential upstream merge issues. Is that still a concern? Is there still an upstream? OpenPLi/OpenViX have different code and whilst I’ve based these changes on OpenATV, I’ve taken a different approach. If there’s going to be merge conflicts anyway, may as well fix minor things, too.

‌

Additional keys: I think this was declined because of IanSav's concerns, but he seems to have given up on Beyonwiz. There's still the precedent set by File Commander's viewer for using CH+/- as first/last page (plus they're already in DirectionActions so there’s no need for a new map). LEFT/RIGHT are often used for page up/down when UP/DOWN move by line.

‌

Stop and hide: these were added by OpenATV (although it uses “Cancel” rather than “Stop”). I suggested stop (to terminate a script from File Commander), but prl seemed to think it was harder than it was. Not too sure of the value of hide, but there may be some situations where it could be useful. OpenATV only unhides on keys it recognises; I unhide on any key, except volume. (This requires a corresponding skin change.)

‌

Write output: this earlier proved contentious and was removed without being submitted. OpenATV has added a “Save” option (/tmp/HHMMSS_console.txt), but I've stuck with saving automatically (/home/root/logs/console.txt; not .log, to make it immune to the log manager). Once saved OpenATV has a “Load” option; since I always save, I’ve changed that to “Details”. OpenATV includes the entire text of a script; I haven’t done that, but have added the start time of each command and the final finish time. Currently there’s no provision to preserve the output, as I felt that was just duplicating File Commander functionality.

[IanSav]

Additional keys: I think this was declined because of IanSav's concerns, but he seems to have given up on Beyonwiz.

I did not give up on Beyonwiz. There were a number of issues including being asked to do something unethical which I refused to do. My hardware was repossessed and I was banned from the development areas of the forum and from participating on the V2.

With all the time I am saving not doing work for Beyonwiz I am now even more active in the Enigma2 world. I am now a developer for the OpenPLi, OpenViX and OpenATV images. All the work that PeterU refused to accept is now becoming part of all those images and their derivatives.

[Jason Hood]

@Peter Urbanec : Does the lack of comment mean I should submit again, or you just haven’t got around to having a look?

[Peter Urbanec]

Have not looked yet.

Will do soon…

[Peter Urbanec]

Looked now. It seems OK, about the only reservation I have is that a noisy script could generate enough output to fill flash.

[Jason Hood]

Is that likely? Wouldn’t it have to be really noisy? After seeing a few screens of output I’d be inclined to cancel a script, never mind even a few meg that would fill an already-full flash.

[Peter Urbanec]

The thing is, you and I are likely to recognise issues better than a typical end-user that just bought a PVR and found some script on forums that is supposed to solve all their problems - all they have to do is put it on the USB stick and run it…

I can see a scenario where something goes wrong and a script will start dumping loads of errors to the console (say repeated dumps of a web page that failed to parse) and the user just sits there, patiently waiting for things to get better! Next thing you know, flash is full, GUI locks up and they power off. From then on, they have a flaky box, but given their level of experience, no idea why or what to do about it.

Having said that, I’m not sure if it is worth the coding effort to limit the maximum size of the written log. Let’s just leave it as is and see if it ever becomes an issue that’s worth addressing.

[Jason Hood]

Merged.