FileCommander.Inputmod & InputBoxmod

Moderators: Gully, peteru

Post Reply
prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

FileCommander.Inputmod & InputBoxmod

Post by prl » Sun Jun 10, 2018 16:10

FileCommander.Inputmod and FileCommander.InputBoxmod are pretty bad examples of inheritance-by-copy-paste.

FileCommander.InputBoxmod.InputBox adds some extra actions to the action map over Screens.InputBox.InputBox, but is otherwise functionally identical. Similarly for FileCommander.InputBoxmod.PinInput and Screens.InputBox.PinInput. FileCommander.InputBoxmod.PinInput is not used in the FileCommander code. FileCommander.Inputmod.Input and FileCommander.InputBoxmod.InputBoxmod are byte-for-byte identical, except that FileCommander.InputBoxmod.InputBoxmod defines its own FileCommander.InputBoxmod.InputBoxmod.skin.

FileCommander.Inputmod.Input and Components.Input.Input really only differ in any significant way in their instantiation parameters and in handleAscii().

Most of the changes I want to make to rationalise all of that are straight-forward, but I'm not sure about handleAscii().

FileCommander.Inputmod.Input.handleAscii() is:

Code: Select all

	def handleAscii(self, code):
		if self.type == self.TEXT:
			self.timeout()
		if self.allmarked:
			self.deleteAllChars()
			self.allmarked = False
		# self.insertChar(unichr(code), self.currPos, False, False)
		from Components.config import getCharValue
		newcode = getCharValue(code)
		if newcode is None:
			return
		self.insertChar(newcode, self.currPos, False, False)
		self.innerright()
		self.update()
while Components.Input.Input.handleAscii() is simply:

Code: Select all

	def handleAscii(self, code):
		if self.type == self.TEXT:
			self.timeout()
		if self.allmarked:
			self.deleteAllChars()
			self.allmarked = False
		self.insertChar(unichr(code), self.currPos, False, False)
		self.innerright()
		self.update()
Components.config.getCharValue() is:

Code: Select all

# ### EGAMI
...
rckeyboard_enable = False
# if file("/proc/stb/info/boxmodel").read().strip() in ["we will add someday keyboard rcusupport for boxtype"]:
# 	rckeyboard_enable = True

def getCharValue(code):
	global egmapidx
	global egkeymap
	global rckeyboard_enable
	print "got ascii code : %d [%d]" % (code, egmapidx)
	if rckeyboard_enable:
		if code == 0:
			egmapidx = 0
			return None
		elif code == 42:
			egmapidx += 1
			return None
		elif code == 56:
			egmapidx += 3
			return None
		elif code == 100:
			egmapidx += 2
			return None
		try:
			return egkeymap[code][egmapidx]
		except:
			return None
	else:
		return unichr(getPrevAsciiCode())
# ### EGAMI
The getCharValue() code is quite wrong, because the code value it is called with is the result of a call to getPrevAsciiCode(), which clears the value of the previous ASCII value (when a KEY_ASCII keycode has been received). It should simply return unichr(code) if rckeyboard_enable is False, as it always will be.

The issues with getCharValue() can be demonstrated by gong to MENU>Sources / Files, navigating in the panel to a file, then BLUE Rename, and trying then to enter ASCII text using a keyboard, instead of SMS-style entry using the remote.

So I think that the FileCommander.Inputmod.Input code can be simply thrown out, and any modification to the input argument naming to Input can be handled in FileCommander.InputBoxmod.InputBox and FileCommander.InputBoxmod.InputBoxmod. [/c]Input[/] is only referenced from within FileCommander.InputBoxmod.

The motivation for this is to allow fixes to Components.Input to allow proper scrolling in the text entry box while editing text (Bug #317: Unable to edit long file names) to be integrated into text input in FileCommander without more copy-paste. Also, because I hate inheritance-by-copy-paste.

Any objections? Suggestions?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Sun Jun 10, 2018 16:41

Hi Prl,

I haven't yet looked at the code you are reviewing but in the work I have done with config, VirtualKeyBoard and NumericalTextInput I found a lot of misplaced code attempting to handle character input timeouts that was just plain wrong / unnecessary. I found that lots of code could be removed with no detriment to functionality. To the contrary things worked faster. For example, if you are looking for SMS trype text input then all the timeout processing you need is already done by NumericalTextInput. Why some code turns off the inbuilt timeout processing and tries to replicate it externally is beyond me.

If you are interested in reviewing my new config, VirtualKeyBoard and NumericalTextInput code then please let me know.

Regards,
Ian.

Grumpy_Geoff
Uber Wizard
Posts: 6490
Joined: Thu Mar 05, 2009 22:54
Location: Perth

Re: FileCommander.Inputmod & InputBoxmod

Post by Grumpy_Geoff » Sun Jun 10, 2018 17:15

prl wrote:
Sun Jun 10, 2018 16:10
...The issues with getCharValue() can be demonstrated by gong to MENU>Sources / Files, navigating in the panel to a file, then BLUE Rename, and trying then to enter ASCII text using a keyboard, instead of SMS-style entry using the remote.
...

I did that just then. Yep, buggered for printable characters in the quick test I did. Deletion, et. al. work.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Sun Jun 10, 2018 17:47

IanSav wrote:
Sun Jun 10, 2018 16:41
I haven't yet looked at the code you are reviewing but in the work I have done with config, VirtualKeyBoard and NumericalTextInput I found a lot of misplaced code attempting to handle character input timeouts that was just plain wrong / unnecessary. I found that lots of code could be removed with no detriment to functionality. To the contrary things worked faster. For example, if you are looking for SMS trype text input then all the timeout processing you need is already done by NumericalTextInput. Why some code turns off the inbuilt timeout processing and tries to replicate it externally is beyond me.

After my changes, the timeout handling for character entry in FileCommander will revert to whatever Components.Input does (which is currently to do its own timeout handling in handleAscii()).

If you're looking at it, config.getCharValue() needs to change from:

Code: Select all

	if rckeyboard_enable:
		...
	else:
		return unichr(getPrevAsciiCode())
to

Code: Select all

	if rckeyboard_enable:
		...
	else:
		return unichr(code)
IanSav wrote:
Sun Jun 10, 2018 16:41
If you are interested in reviewing my new config, VirtualKeyBoard and NumericalTextInput code then please let me know.

Yes, thanks. I'd be interested in looking at that. I also want to allow long string editing in config.ConfigText, but it's clearly better to hold off on that until you've finished with your changes in config.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
MrQuade
Uber Wizard
Posts: 11842
Joined: Sun Jun 24, 2007 13:40
Location: Perth

Re: FileCommander.Inputmod & InputBoxmod

Post by MrQuade » Mon Jun 11, 2018 16:21

Why is this thread in "The Vault"?
Logitech Harmony Ultimate+Elite RCs
Beyonwiz T2/3/U4/V2, DP-S1 PVRs
Denon AVR-X3400h, LG OLED65C7T TV
QNAP TS-410 NAS, Centos File Server (Hosted under KVM)
Ubiquiti UniFi Managed LAN/WLAN, Draytek Vigor130/Asus RT-AC86U Internet
Pixel 4,5&6, iPad 3 Mobile Devices

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Mon Jun 11, 2018 16:31

MrQuade wrote:
Mon Jun 11, 2018 16:21
Why is this thread in "The Vault"?

It isn't... now. :)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 14, 2018 16:02

I've moved posts about IanSav's work on Config and VirtualKeyBoard to Config and VirtualKeyBoard enhancements
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Wed Jun 20, 2018 15:52

Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 21, 2018 17:21

Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Thu Jun 21, 2018 18:55

Hi Prl,

Did get ridding of help under MENU and creating a proper HELP based help screen make your list?

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 21, 2018 19:38

Doesn't #658 in my previous posted list cover that?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Thu Jun 21, 2018 21:12

Hi Prl,
prl wrote:
Thu Jun 21, 2018 19:38
Doesn't #658 in my previous posted list cover that?
Potentially. #658 indicates that there is no help and some should be added. I wasn't sure if you intended to remove the current help information from the MENU button and use a conventionally organised HELP screen. If that is your intention then yes that is what I was seeking. :)

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 21, 2018 22:52

I haven't looked in detail at exactly what I'll do. My preference is to use a plugin-local setup.xml file for the FileCommander setup screen, but I haven't checked to see how or even whether that still works. Second preference is to use a standard layout coded Setup screen using ConfigListScreen with the usual description display.

However, some of the button description in the current MENU screen for FileCommander are longish, and I haven't thought about whether an adequate description can be given in the more limited space available in a help screen.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Thu Jun 21, 2018 23:30

Hi Prl,

The use of a local setup.xml would be helpful. Rather than using a Screen, ConfigList and HelpableScreen subclass for the setup screen initialisation why don't you look as simply sub classing Setup itself. You will save yourself some code duplication while adding all the features of the normal Setup system. ;)

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Fri Jun 22, 2018 11:44

After having a bit of a look at the code and seeing how Setup fetches and uses setup.xml:
  • I can't see how Setup/setup.xml can be used directly for the FileCommander setup, since the FileCommander setup has a default directory setting and I can't see how it can be used to set or change directory names using a browser like LocationBox.
  • I can't see a simple way of inheriting from Setup and adding that directory setting functionality. The methods of Setup itself don't seem to provide a way in to capture key-presses directed at specific config items. All input handling in Setup is done by its ConfigListScreen mixin and acted on by ConfigListScreen's ConfigList instance. It might be possible to replace the ConfigList instance with a subclass of ConfigList, but it would be a bit messy.
It looks like the simplest path will be a code cleanup of FileCommanderConfigScreen.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Fri Jun 22, 2018 13:37

Hi Prl,

I would be happy to show you how I subclass Setup in my Timeshift.py and Recordings.py refactors. They are complete but not submitted because Setup and ConfigList changes have not been submitted. They are waiting on the tedious repairs I am developing for config.py.

Alternatively just complete your cleanup and I can jump in and make the appropriate changes to work with the Setup.

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Fri Jun 22, 2018 13:40

IanSav wrote:
Fri Jun 22, 2018 13:37
I would be happy to show you how I subclass Setup in my Timeshift.py and Recordings.py refactors. They are complete but not submitted because Setup and ConfigList changes have not been submitted. They are waiting on the tedious repairs I am developing for config.py.

Thanks. I'd be interested in seeing how you did it.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Fri Jun 22, 2018 13:59

Hi Prl,

See attached...

These new code files require the new Setup.py and ConfigList.py to work. I think I have provided them previously. (If you don't have them I can get you the current drafts.)

The setup.xml has the new Recordings and Timeshift options present but commented out so that I can use this file in production and development system. The settings show how I use the new "data=" attribute to offer more data sensitive interaction between the xml files and the Setup code.

Regards,
Ian.
Attachments
setup.xml.txt
(67.03 KiB) Downloaded 178 times
Timeshift.py.txt
(4.06 KiB) Downloaded 172 times
Recordings.py.txt
(4.75 KiB) Downloaded 176 times

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Fri Jun 22, 2018 15:24

So, from __future__ import Setup? ;) The new features look good, but I was looking at what I could do with FileCommander now.

I'd be interested in using the new features of Setup in FileCommander when it becomes part of the release.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Fri Jun 22, 2018 16:22

Hi Prl,

If PeterU would merge my pull requests directly into the Beyonwiz image I would have submitted these changes months ago. At the moment I have to get the code into OpenPLi then OpenViX and then finally ask PeterU to merge the changes into the Beyonwiz image. So far this has not happened with the new ActionMap.py code so I don't know what is going on.

As you may know, the Setup changes have been held up because OpenViX want me to fix the bugs in config.py before I submit the rest of the changes. I can do it the other way around but some further updates to ConfigList and perhaps Setup.py may still be required. It would not be a problem for me but in the scenario that PeterU wanted I need to get everything done to suit OpenPLi and OpenViX before I can get code to Beyonwiz. This is problematic because the OpenPLi code is quite different and a lot of time and effort goes into getting all the changes correctly into place everywhere.

If the changes would be accepted directly then I would be happy to create Beyonwiz specific pull requests for all the pending code I have ready. The Beyonwiz updates are much easier as most of my development has the Beyonwiz image specifically in mind. The code is also all developed on Beyonwiz hardware. I just don't want to waste my time curating Beyonwiz pull requests just to have them ignored or closed until an upstream merge.

Do you have any suggestions about what I can do to solve this problem?

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Fri Jun 22, 2018 18:31

Ask peteru?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Fri Jun 22, 2018 23:08

Hi Prl,
prl wrote:
Fri Jun 22, 2018 18:31
Ask peteru?
I did. I was ignored. :(

Regards,
Ian.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by peteru » Sat Jun 23, 2018 03:13

I don't have much spare time, so for the foreseeable future, I don't have any plans to perform upstream merges or track other repositories closely. I also don't have any plans for starting a new firmware branch.

I am planning on maintaining an active beta and merging Beyonwiz specific pull requests as time permits. Small, easy to understand, non-controversial pull requests are preferred. I think that the current production release is good enough to last a while, so now is a good time to shift the beta cycle into a mode where more changes will be accepted. Users should understand that being on the beta feed is actually being a beta tester and living on the edge.

@IanSav: If you are confident that the Beyonwiz specific changes will not cause merge headaches in the future (because the code diverges from upstream), then go ahead and create pull requests against the Beyonwiz repo. If it becomes difficult to merge in the future, I'll come to you for help.

"Beauty lies in the hands of the beer holder."
Blog.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Sat Jun 23, 2018 22:24

Hi PeterU,
peteru wrote:
Sat Jun 23, 2018 03:13
@IanSav: If you are confident that the Beyonwiz specific changes will not cause merge headaches in the future (because the code diverges from upstream), then go ahead and create pull requests against the Beyonwiz repo. If it becomes difficult to merge in the future, I'll come to you for help.
Why are my pull requests being tagged with special conditions? Prl, Adoxa and your changes do not have these conditions applied.

Regards,
Ian.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by peteru » Mon Jun 25, 2018 00:34

IanSav wrote:
Sat Jun 23, 2018 22:24
Hi PeterU,
peteru wrote:
Sat Jun 23, 2018 03:13
@IanSav: If you are confident that the Beyonwiz specific changes will not cause merge headaches in the future (because the code diverges from upstream), then go ahead and create pull requests against the Beyonwiz repo. If it becomes difficult to merge in the future, I'll come to you for help.
Why are my pull requests being tagged with special conditions? Prl, Adoxa and your changes do not have these conditions applied.
You are making changes in at least three different forks. Those changes will need to be merged at some point in the future. If the code does not diverge much, it won't be hard. If it does diverge, then you are the expert on that code and therefore the logical person to ask for advice in cases of merge difficulty.

BTW: There are no tags with special conditions on your pull requests.

"Beauty lies in the hands of the beer holder."
Blog.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Mon Jun 25, 2018 02:04

Hi PeterU,
peteru wrote:
Mon Jun 25, 2018 00:34
You are making changes in at least three different forks. Those changes will need to be merged at some point in the future. If the code does not diverge much, it won't be hard. If it does diverge, then you are the expert on that code and therefore the logical person to ask for advice in cases of merge difficulty.
I am simply following your instructions. You asked me to make all my changes upstream so that you could more easily merge in my changes. I am doing as you asked. As a result of my contributions I am now being asked to make many more changes upstream to both OpenPLi and OpenViX. Some of these changes are and will be significant.

Due to inter image politics I need to tailor all the changes specifically for OpenPLi and OpenViX separately plus supporting all the differences in the Beyonwiz image. As hard as I am trying to minimise merge issues they will, by current circumstances, continue to exist. I hope that my efforts are at least reducing the number of merge problems.

My life would be SIGNIFICANTLY easier if I could just submit the changes to the Beyonwiz image. You indicated that I wouldn't need to commit to the Beyonwiz repository as you would simply merge in my changes from upstream. This is not happening and I now have to curate Beyonwiz specific pull requests as well. :(
peteru wrote:
Mon Jun 25, 2018 00:34
BTW: There are no tags with special conditions on your pull requests.
My point was that I note no similar requests from the other contributors. (I acknowledge that Prl is contributing some changes upstream to OpenViX.) Some of the Beyonwiz changes are creating significant merge problems.

Regards,
Ian.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by peteru » Mon Jun 25, 2018 02:32

Yep, it's hard enough when you are only looking at a few files that you are working on. Now just imagine how challenging the work gets for a maintainer who has to deal not only with all of the enigma2 code, but also with every other piece of software that goes into making the firmware.

There are no easy answers. Every single changed character that differs between forks requires a review. A lot of the time that means understanding three (or more) lots of code that you have never seen before and making sure that it still works when it's all merged. As a maintainer, I get uncomfortable with any changes that do not provide "high value" benefits. For example, changes that only affect code comments are not "hard" to merge, but they still require extra work. Changes that only change formatting of debug output are not important enough to cause potential merge conflicts later down the track. (However, removing noisy debug output that can slow the system down by flooding the serial port output can provide enough benefit to accept.)

"Beauty lies in the hands of the beer holder."
Blog.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Mon Jun 25, 2018 02:45

Hi PeterU,

But merging those "trivial" changes from upstream will reduce the merge errors and would save you time and effort!

Regards,
Ian.

User avatar
peteru
Uber Wizard
Posts: 9730
Joined: Tue Jun 12, 2007 23:06
Location: Sydney, Australia
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by peteru » Tue Jun 26, 2018 01:41

That's not quite how it works out with git merges. The safest bet is to not modify more than one fork so that merges are simpler. Once the same areas are modified in more than one branch, the likelihood of merge conflicts skyrockets.

The "trivial" changes are best saved for a single merge at a later date. On the other hand, important bug fixes would be worth the effort, but those are best kept to a minimal change set.

Anyway, I think we are getting too far off-topic. You may be able to get some appreciation for the kind of effort involved if you actually try to use git to work with multiple branches and repositories and perform merges between them.

"Beauty lies in the hands of the beer holder."
Blog.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Tue Jun 26, 2018 11:02

Hi PeterU,
peteru wrote:
Tue Jun 26, 2018 01:41
That's not quite how it works out with git merges. The safest bet is to not modify more than one fork so that merges are simpler. Once the same areas are modified in more than one branch, the likelihood of merge conflicts skyrockets.
Ah to live in your idealistic world. The reality is that politics and personalities play a more significant role than merge efficiency in the different Enigma2 images. What is acceptable or mandatory for one image is highly objectionable for another. To make any progress I am forced to customise each submission for each image.

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Tue Jun 26, 2018 15:21

I'm sure peteru is well aware of the consequences of those dynamics in the enigma2 world.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Tue Jun 26, 2018 15:29

Getting back on topic...

I've started doing help screens for the File Commander, and it certainly looks as though it will be possible to remove the remote button help text from the File Commander setup screen and use the help screens instead.

There's still a bit of a problem with the help text for the OK button. The text for it in the setup screen is:
Play movie and music, show pictures, view/edit files, install/extract files, run scripts

My current, perhaps over-terse replacement in the help screen is:
Play/view/edit/install/extract/run

The current setup screen text is too long (it is cut off just after the "n" in "install"). My current help screen text is perhaps too dense, but could be made almost twice as long and still fit. Adding "file" at the end probably wouldn't be a bad idea. Any suggestions?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Tue Jun 26, 2018 16:46

Hi Prl,

Perhaps something like: "Play, use or run the currently selected file".

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Wed Jun 27, 2018 10:31

I've found another strangeness in the File Commander, this time with symbolic links.

The current help text in the setup screen says:
2: New symlink with file name.
3: New symlink with folder name.
But the descriptions aren't much like what the buttons actually do.

"2" can create a symbolic link to either a file or directory, and the user is asked to enter a name for the new link. The popup box to enter the name has no pre-fill.
"3" can only create a symbolic link to a directory, but it has the same name (in the other directory) as the original directory.

I think that either
  • "2" should be left as it is, and "3" should be changed so that it can create symbolic links to either files or directories, or
  • "3" should be removed, and the popup box to name the link be pre-filled with the name of the file being linked to.
I tend to favour the second approach.

The help text, should, of course, be changed to reflect what the buttons actually do.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Wed Jun 27, 2018 11:41

These are the current help texts in my development code for the File Commander screens. I'm still looking for better help text for the two File Commander file lists screens. The current OK help text for the main screen is about as long as it can get and still fit. The help texts for 2 & 3 in the main screen reflect the current actual operations for those two buttons.

Suggestions? Comments?

File Commander main screen
OK: Play/view/edit/install/extract/run file or enter directory
EXIT: Leave File Commander
MENU: Open configuration screen
NEXT: Activate right-hand file list as source
PREV: Activate left-hand file list as source
CH+: Activate right-hand file list as source
CH-: Activate left-hand file list as source
1: Create directory/folder
2: Create user-named symbolic link
3: Create symbolic link to directory using the same name
4: Toggle execute permissions on/off (755/644)
5: Go to your default folder
TEXT: View or edit file (if size < 1MB)
INFO: Show task list
BACK: Go to parent directory
UP: Move up list
DOWN: Move down list
LEFT: Page up list
RIGHT: Page down list
RED: Delete file or directory (and all its contents)
GREEN: Move file/directory to target directory
YELLOW": Copy file/directory to target directory
BLUE: Rename file/directory
0: Refresh screen
MEDIA: Enter multi-file selection mode

File Commander multi-select screen
OK: Select (source list) or enter directory (target list)
EXIT: Leave multi-select mode
NEXT: Activate right-hand file list as multi-select source
PREV: Activate left-hand file list as multi-select source
CH+: Activate right-hand file list as multi-select source
CH-: Activate left-hand file list as multi-select source
INFO: Show task list
BACK: Go to parent directory
UP: Move up list
DOWN: Move down list
LEFT: Page up list
RIGHT: Page down list
RED: Delete the selected files or directories
GREEN: Move files/directories to target directory
YELLOW: Copy files/directories to target directory
BLUE: Leave multi-select mode
0: Refresh screen
MEDIA: Select

File Commander text viewer/editor
OK: Edit current line
EXIT: Exit editor and write changes (if any)
RED: Exit editor and write changes (if any)
GREEN: Edit current line
YELLOW: Delete current line
BLUE: Insert line before current line
CH+: Go to start of file
CH-: Go to end of file

File Commander picture viewer (no HELP button hint)
EXIT: Exit picture viewer
LEFT: Show next picture
RIGHT: Show previous picture
BLUE: Start/stop slide show
YELLOW: Show image information
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

Paul_oz53
Wizard
Posts: 2787
Joined: Sat Jun 13, 2009 02:34
Location: Melbourne

Re: FileCommander.Inputmod & InputBoxmod

Post by Paul_oz53 » Wed Jun 27, 2018 14:55

prl wrote:
Wed Jun 27, 2018 11:41
These are the current help texts in my development code for the File Commander screens. I'm still looking for better help text for the two File Commander file lists screens. The current OK help text for the main screen is about as long as it can get and still fit. The help texts for 2 & 3 in the main screen reflect the current actual operations for those two buttons.

Suggestions? Comments?

File Commander main screen
OK: Play/view/edit/install/extract/run file or enter directory
...

File Commander multi-select screen
OK: Select directory/file or enter directory
...
These look quite good.

Can't really see an easy way to improve the OK help text in the main screen. It captures the functions that occur in different contexts. Possibly "play/view" is nearly a tautology. "View" would probably capture both actions well enough for regular punters.

For the multi-select screen, "or enter directory" seems a little misleading. It applies if you swap to the other list to move or copy files. String length may be a problem though. I'd like to see something like:

"Select directory/file or (move/copy) enter directory"; or, if size is an issue, "Select dir/file or (move/copy) enter dir".

P.
__________________________________
Paul
Beyonwiz T4, 2 x U4: FW - 19.3 20211010
Samsung QA85Q80BAWXXY 4K TV
Samsung QA65Q80TAWXXY 4K TV
Samsung HW Q800BXY soundbar
OverlayHD 1.70, IceTV, Foxtel IQ4
2 x Win7 PCs, 2 x Win10 PCs
Denon AVR -X2400H

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Wed Jun 27, 2018 17:56

Paul_oz53 wrote:
Wed Jun 27, 2018 14:55
prl wrote:
Wed Jun 27, 2018 11:41
These are the current help texts in my development code for the File Commander screens. I'm still looking for better help text for the two File Commander file lists screens. The current OK help text for the main screen is about as long as it can get and still fit. The help texts for 2 & 3 in the main screen reflect the current actual operations for those two buttons.

Suggestions? Comments?

File Commander main screen
OK: Play/view/edit/install/extract/run file or enter directory
...

File Commander multi-select screen
OK: Select directory/file or enter directory
...
These look quite good.
Thanks.
Paul_oz53 wrote:
Wed Jun 27, 2018 14:55
Can't really see an easy way to improve the OK help text in the main screen. It captures the functions that occur in different contexts. Possibly "play/view" is nearly a tautology. "View" would probably capture both actions well enough for regular punters.
The "view" is for what it does on image files and text files. Images can be displayed as a slideshow, but that only happens after you've entered the image viewer. "view/edit" is what it can do for text files.
Paul_oz53 wrote:
Wed Jun 27, 2018 14:55
For the multi-select screen, "or enter directory" seems a little misleading. It applies if you swap to the other list to move or copy files. String length may be a problem though. I'd like to see something like:

"Select directory/file or (move/copy) enter directory"; or, if size is an issue, "Select dir/file or (move/copy) enter dir".

Yes, that one's the text I'm least happy with. I'm not all that keen on that suggestion, either, though, because in the right-hand list, OK only does "enter directory"; it can't move or copy. I can make the help text context sensitive so that it shows "Enter directory" when focus is in the right-hand pane and "Select directory/file" when the focus in in the left-hand pane, but I'd prefer a single help text if possible. It's "just" finding a wording that's clear and fits in the space available. The current "Select directory/file or enter directory" text uses about 2/3 of the line width, so it could be made about 50% longer, but there's not a lot of space to play with. "Brevity is the soul of wit" (Hamlet *) :)

Fortunately, neither is a non-reversible action, so "read, then experiment", while less than perfect, would be viable.

* However, it was said by Polonius, and he was neither brief, nor the sharpest tool in the shed ;)
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
adoxa
Wizard
Posts: 1490
Joined: Thu Feb 23, 2017 22:58
Location: CQ
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by adoxa » Wed Jun 27, 2018 20:52

A means of terminating the script would be nice, too.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 28, 2018 11:14

adoxa wrote:
Wed Jun 27, 2018 20:52
A means of terminating the script would be nice, too.

That would mostly need to be implemented in Screens.Console (and perhaps enabled by calling screens that want to have the facility). The underlying eConsoleAppContainer only supports sending the command SIGKILL or SIGINTR.

It wouldn't be hard to do.

There is also the question more generally of what should be done if the termination is done part-way through the Console's command list. Should it only kill the currently-running command, and continue, or should it abandon the rest of the commands?.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 28, 2018 11:18

On the help screen text, I've changed
File Commander multi-select screen
OK: Select directory/file or enter directory
MEDIA: Select directory/file

to

OK: Select (left list) or enter directory (right list)
MEDIA: Select

Does that clarify things without losing too much?

I've updated my original post to reflect the new strings
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
adoxa
Wizard
Posts: 1490
Joined: Thu Feb 23, 2017 22:58
Location: CQ
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by adoxa » Thu Jun 28, 2018 11:48

prl wrote:
Thu Jun 28, 2018 11:18
OK: Select (left list) or enter directory (right list)
Since either side could be the multi-select, "source list" and "target list" would be better.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Thu Jun 28, 2018 12:24

adoxa wrote:
Thu Jun 28, 2018 11:48
prl wrote:
Thu Jun 28, 2018 11:18
OK: Select (left list) or enter directory (right list)
Since either side could be the multi-select, "source list" and "target list" would be better.

Yes, of course. Updated in the original post.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

Paul_oz53
Wizard
Posts: 2787
Joined: Sat Jun 13, 2009 02:34
Location: Melbourne

Re: FileCommander.Inputmod & InputBoxmod

Post by Paul_oz53 » Thu Jun 28, 2018 13:49

prl wrote:
Thu Jun 28, 2018 12:24
adoxa wrote:
Thu Jun 28, 2018 11:48
prl wrote:
Thu Jun 28, 2018 11:18
OK: Select (left list) or enter directory (right list)
Since either side could be the multi-select, "source list" and "target list" would be better.

Yes, of course. Updated in the original post.

That works for me.
__________________________________
Paul
Beyonwiz T4, 2 x U4: FW - 19.3 20211010
Samsung QA85Q80BAWXXY 4K TV
Samsung QA65Q80TAWXXY 4K TV
Samsung HW Q800BXY soundbar
OverlayHD 1.70, IceTV, Foxtel IQ4
2 x Win7 PCs, 2 x Win10 PCs
Denon AVR -X2400H

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Sat Jun 30, 2018 16:38

prl wrote:
Wed Jun 27, 2018 10:31
I've found another strangeness in the File Commander, this time with symbolic links.

The current help text in the setup screen says:
2: New symlink with file name.
3: New symlink with folder name.
But the descriptions aren't much like what the buttons actually do.

"2" can create a symbolic link to either a file or directory, and the user is asked to enter a name for the new link. The popup box to enter the name has no pre-fill.
"3" can only create a symbolic link to a directory, but it has the same name (in the other directory) as the original directory.

I think that either
  • "2" should be left as it is, and "3" should be changed so that it can create symbolic links to either files or directories, or
  • "3" should be removed, and the popup box to name the link be pre-filled with the name of the file being linked to.
I tend to favour the second approach.

The help text, should, of course, be changed to reflect what the buttons actually do.

I've gone with the second approach. That means that the function that was on "3" is now incorporated (and extended to include linking to files) using "2".

So, should the numbered buttons be:
1: Create directory/folder
2: Create symbolic link
4: Toggle execute permissions on/off (755/644)
5: Go to your default folder

i.e. drop "3" and leave the other numbering unchanged,

or:
1: Create directory/folder
2: Create symbolic link
3: Toggle execute permissions on/off (755/644)
4: Go to your default folder

i.e drop "3" and renumber the higher-numbered functions?
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

User avatar
adoxa
Wizard
Posts: 1490
Joined: Thu Feb 23, 2017 22:58
Location: CQ
Contact:

Re: FileCommander.Inputmod & InputBoxmod

Post by adoxa » Sat Jun 30, 2018 16:48

prl wrote:
Sat Jun 30, 2018 16:38
i.e. drop "3" and leave the other numbering unchanged
That would be my preference.

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Sat Jun 30, 2018 17:35

Hi Prl,

Can some other function be assigned to (3) to eliminate the hole? I don't think the hole in the numbering is optimal.

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Sat Jun 30, 2018 19:02

IanSav wrote:
Sat Jun 30, 2018 17:35
Can some other function be assigned to (3) to eliminate the hole? I don't think the hole in the numbering is optimal.

Yes, another function could fill the hole. Any suggestions?

I'm tending to agree with adoxa that the numbering for existing functions shouldn't be changed (after implementing changed numbering :)).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

IanSav
Uber Wizard
Posts: 16846
Joined: Tue May 29, 2007 15:00
Location: Melbourne, Australia

Re: FileCommander.Inputmod & InputBoxmod

Post by IanSav » Sat Jun 30, 2018 20:42

Hi Prl,

Do you have a test package of the changes? I think a better suggestion may flow if I can see the current state of change.

Regards,
Ian.

prl
Wizard God
Posts: 32697
Joined: Tue Sep 04, 2007 13:49
Location: Canberra; Black Mountain Tower transmitters

Re: FileCommander.Inputmod & InputBoxmod

Post by prl » Sun Jul 01, 2018 09:10

IanSav wrote:
Sat Jun 30, 2018 20:42
Do you have a test package of the changes? I think a better suggestion may flow if I can see the current state of change.

Merging the two symlink options is the first change I've made to the FileCommander UI. My current version simply removes the action on "3", and when "2" is pressed, the only change is that instead of the "Please enter name of the new symlink" being opened with an empty text entry box, the box is filled with the name of the file or directory in focus in the source list, and all characters are selected..

So to create a link with the same name as the enter in the source list, press 2, then OK. To enter a different name completely, press 2, then just start entering characters. The first one will overwrite the old text. To edit the name, press 2 and use LEFT or RIGHT to clear the "all selected" state and then edit the name normally.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV

Post Reply

Return to “Developers Community”