Page 1 of 7
FileCommander.Inputmod & InputBoxmod
Posted: Sun Jun 10, 2018 16:10
by prl
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?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sun Jun 10, 2018 16:41
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sun Jun 10, 2018 17:15
by Grumpy_Geoff
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sun Jun 10, 2018 17:47
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 11, 2018 16:21
by MrQuade
Why is this thread in "The Vault"?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 11, 2018 16:31
by prl
MrQuade wrote: ↑Mon Jun 11, 2018 16:21
Why is this thread in "The Vault"?
It isn't... now.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 14, 2018 16:02
by prl
I've moved posts about IanSav's work on Config and VirtualKeyBoard to
Config and VirtualKeyBoard enhancements
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 20, 2018 15:52
by prl
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 17:21
by prl
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 18:55
by IanSav
Hi Prl,
Did get ridding of help under MENU and creating a proper HELP based help screen make your list?
Regards,
Ian.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 19:38
by prl
Doesn't #658 in my previous
posted list cover that?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 21:12
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 22:52
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 21, 2018 23:30
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 11:44
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 13:37
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 13:40
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 13:59
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 15:24
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 16:22
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 18:31
by prl
Ask peteru?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Fri Jun 22, 2018 23:08
by IanSav
Hi Prl,
prl wrote: ↑Fri Jun 22, 2018 18:31
Ask peteru?
I did. I was ignored.
Regards,
Ian.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 23, 2018 03:13
by peteru
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 23, 2018 22:24
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 25, 2018 00:34
by peteru
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 25, 2018 02:04
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 25, 2018 02:32
by peteru
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.)
Re: FileCommander.Inputmod & InputBoxmod
Posted: Mon Jun 25, 2018 02:45
by IanSav
Hi PeterU,
But merging those "trivial" changes from upstream will reduce the merge errors and would save you time and effort!
Regards,
Ian.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Tue Jun 26, 2018 01:41
by peteru
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Tue Jun 26, 2018 11:02
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Tue Jun 26, 2018 15:21
by prl
I'm sure peteru is well aware of the consequences of those dynamics in the enigma2 world.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Tue Jun 26, 2018 15:29
by prl
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?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Tue Jun 26, 2018 16:46
by IanSav
Hi Prl,
Perhaps something like: "Play, use or run the currently selected file".
Regards,
Ian.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 27, 2018 10:31
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 27, 2018 11:41
by prl
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
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 27, 2018 14:55
by Paul_oz53
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 27, 2018 17:56
by prl
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
Re: FileCommander.Inputmod & InputBoxmod
Posted: Wed Jun 27, 2018 20:52
by adoxa
A means of terminating the script would be nice, too.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 28, 2018 11:14
by prl
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?.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 28, 2018 11:18
by prl
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
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 28, 2018 11:48
by adoxa
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 28, 2018 12:24
by prl
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Thu Jun 28, 2018 13:49
by Paul_oz53
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 30, 2018 16:38
by prl
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?
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 30, 2018 16:48
by adoxa
prl wrote: ↑Sat Jun 30, 2018 16:38
i.e. drop "3" and leave the other numbering unchanged
That would be my preference.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 30, 2018 17:35
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 30, 2018 19:02
by prl
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
).
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sat Jun 30, 2018 20:42
by IanSav
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.
Re: FileCommander.Inputmod & InputBoxmod
Posted: Sun Jul 01, 2018 09:10
by prl
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.