FileCommander.Inputmod & InputBoxmod

[prl]

For anyone who'd like to have a play with the suggested symlink changes in FileCommander, here are the diffs that work on firmware 20180627.

Code: Select all

diff --git a/lib/python/Plugins/Extensions/FileCommander/plugin.py b/lib/python/Plugins/Extensions/FileCommander/plugin.py
index 7d27a11..4beeccc 100644
--- a/lib/python/Plugins/Extensions/FileCommander/plugin.py
+++ b/lib/python/Plugins/Extensions/FileCommander/plugin.py
@@ -116,8 +116,7 @@ class FileCommanderConfigScreen(Screen, ConfigListScreen):
 		self["help"] = Label(_("Keys:\n"
 							   "0: Refresh screen.\n"
 							   "1: New folder.\n"
-							   "2: New symlink with file name.\n"
-							   "3: New symlink with folder name.\n"
+							   "2: New symlink.\n"
 							   "4: Change permissions: chmod 644/755.\n"
 							   "5: Change to default folder.\n"
 							   "BACK: Change to parent folder.\n"
@@ -235,7 +234,6 @@ class FileCommanderScreen(Screen, key_actions):
 			"prevBouquet": self.listLeft,
 			"1": self.gomakeDir,
 			"2": self.gomakeSym,
-			"3": self.gomakeSymlink,
 			"4": self.call_change_mode,
 			"5": self.goDefaultfolder,
 			# "8": self.test,
@@ -505,7 +503,7 @@ class FileCommanderScreen(Screen, key_actions):
 		sourceDir = self.SOURCELIST.getCurrentDirectory()
 		if (filename is None) or (sourceDir is None):
 			return
-		self.session.openWithCallback(self.doMakesym, InputBox, text="", title=_("Please enter name of the new symlink"), windowTitle=_("New symlink"))
+		self.session.openWithCallback(self.doMakesym, InputBox, text=os.path.basename(os.path.normpath(filename)), title=_("Please enter name of the new symlink"), windowTitle=_("New symlink"))
 
 	def doMakesym(self, newname):
 		if newname:

As I said, the changes are pretty minimal.

The source changes change the function of "2" so that its popup box is pre-filled with the name of the file/folder in the source list and marked. To create a link with the same name as the original file, just press OK in the popup. To give the link a completely different name, just start entering text SMS-style. To modify the pre-fill text, press LEFT or RIGHT to clear the "all marked" setting, and then edit as normal.

Button "3"'s action is removed. Buttons "4" and "5" retain their current actions.

And don't worry too much about the old-style help. The code for proper help screens is already written and tested.

[Grumpy_Geoff]

For anyone who'd like to have a play with the suggested symlink changes in FileCommander, here are the diffs that work on firmware 20180627.

I would give it a go, but how do I go about getting the source so I can apply the changes? As far as I understand it, I've only the (optimised?) plugin.pyo file.

Code: Select all

root@beyonwizu4:/# ls -al /usr/lib/enigma2/python/Plugins/Extensions/FileCommander
drwxr-xr-x    5 root     root          4096 Jun 27 12:57 .
drwxr-xr-x   23 root     root          4096 Jun 27 10:50 ..
-rw-r--r--    1 root     root         17481 Jun 27 10:50 FileListmod.pyo
-rw-r--r--    1 root     root          2057 Jun 27 10:50 InputBox.pyo
-rw-r--r--    1 root     root           155 Jun 27 10:50 __init__.pyo
drwxr-xr-x    2 root     root          4096 Jun 27 12:57 addons
drwxr-xr-x    2 root     root          4096 Jun 27 12:57 images
drwxr-xr-x    2 root     root          4096 Jun 27 12:57 pic
-rw-r--r--    1 root     root         41882 Jun 27 10:50 plugin.pyo
root@beyonwizu4:/#

[prl]

For anyone who'd like to have a play with the suggested symlink changes in FileCommander, here are the diffs that work on firmware 20180627.

I would give it a go, but how do I go about getting the source so I can apply the changes? As far as I understand it, I've only the (optimised?) plugin.pyo file.

The diffs are really only intended for people with checked-out copies of the source. Which probably means peteru, IanSav & adoxa.

If people other than just those are interested in giving it a go, I'll post one of my normal patch installers here tomorrow. I've been busy with RL stuff most of yesterday and today.

[Grumpy_Geoff]

The diffs are really only intended for people with checked-out copies of the source. Which probably means peteru, IanSav & adoxa.
...

Okay, no problem. If you do get time to create a patch installer, then I'll happily try it out. If you don't get the time, then no worries as I can wait for it to appear in a beta sometime.

[prl]

Here's a an alpha patch for Bug #666: Operation of link creation in FileCommander doesn't match help text.

The patch changes change the function of "2" in the FileCommander (MENU>Sources / Files from live TV) so that its popup box is pre-filled with the name of the file/folder in the source list and marked. To create a link with the same name as the original file, just press OK in the popup. To give the link a completely different name, just start entering text SMS-style. To modify the pre-fill text, press LEFT or RIGHT to clear the "all marked" setting, and then edit as normal.

Button "3"'s action is removed. Buttons "4" and "5" retain their current actions.

Uninstall this patch before doing any online firmware update! A firmware update from USB will safely remove this patch, and recover from any errors you might make in doing the install or uninstall.

This patch was tested on firmware 20180701beta. It will not work on any firmware earlier than 20180701.

It should be compatible with OverlayHD and with all of adoxa's current patches.

If you're uncomfortable with doing any part of the instructions, don't do any of them!

To install:

To apply the patches, download the linked .ZIP file, and extract it. It will create a new directory/folder called fc-symlink3-installer, which contains two files, installer.sh and uninstaller.sh.

Copy the two files somewhere convenient on a T/U series box (like /home/root), then log into the box using telnet or ssh, change directory to the place you put the installer.sh/uninstaller.sh files. If you put the files in /home/root you'll be in the right place as soon as you log in.

To install the patches run:

sh installer.sh

and restart the GUI (or reboot).

To uninstall the patches, log in and go to the directory as you did to install, and run

sh uninstaller.sh

And restart the GUI.

Make sure you uninstall before doing an upgrade. Don't run the installer if you've already installed & don't run the uninstaller if you've already uninstalled.

You can check whether the patches are installed by logging in and running this on the box:

find /usr/bin /usr/share/enigma2 /usr/lib/enigma2 -name \*.bak

It should print nothing if the patch isn't installed, and it should print

Code: Select all

/usr/lib/enigma2/python/Plugins/Extensions/FileCommander/plugin.pyo.bak

If the patch is installed.


Comments welcome!

[adoxa]

Enhancement #657: Refactor FileList in FileCommander

The getParentDirectory part of this had problems: a typo (Nome instead of None); but it should have stayed as != False, as None is valid, representing the list of storage devices. A fix has been submitted.

[prl]

Thanks.

[Grumpy_Geoff]

The alpha doesn't work the way the 'old' option 3 did - create a symbolic link to the selected folder. The (now remaining) option 2 creates a link (default) named as per selection, but to the containing parent directory.
I had selected /media/autofs/Public/Test_Wiz_share/ as the target, but got a link as below -
lrwxrwxrwx 1 root root 21 Jul 2 15:23 Test_Wiz_share -> /media/autofs/Public/

Is this related to adoxa's fix?

[prl]

The alpha doesn't work the way the 'old' option 3 did - create a symbolic link to the selected folder. The (now remaining) option 2 creates a link (default) named as per selection, but to the containing parent directory.
I had selected /media/autofs/Public/Test_Wiz_share/ as the target, but got a link as below -
lrwxrwxrwx 1 root root 21 Jul 2 15:23 Test_Wiz_share -> /media/autofs/Public/

Thanks - I have carefully preserved a bug in the old code.

Is this related to adoxa's fix?

No.

[prl]

I've put a new installer ZIP, fc-symlink2-installer.zip, which fixes the bug Grumpy_Geoff pointed out, in the original post.

Uninstall the old version before installing the new one.

[Grumpy_Geoff]

I've put a new installer ZIP, fc-symlink2-installer.zip, which fixes the bug Grumpy_Geoff pointed out, in the original

That was quick.

Uninstall the old version before installing the new one.

Do we need a UI restart in between uninstalling the old and installing the new?

[prl]

Do we need a UI restart in between uninstalling the old and installing the new?

No.

[Grumpy_Geoff]

I've put a new installer ZIP, fc-symlink2-installer.zip, which fixes the bug Grumpy_Geoff pointed out, in the original post.

If you accept the name, then press OK, then the symlink is correctly created.

If you change the name, then it creates a link to a non-existent directory of the changed name (i.e. below, it should be to */Test_Wiz_share, not to */Test_Wiz_share-1 -

Code: Select all

root@beyonwizu4:/media/hdd/movie# ls -al Test_W*
lrwxrwxrwx    1 root     root            37 Jul  2 17:19 Test_Wiz_share-1 -> /media/autofs/Public/Test_Wiz_share-1
root@beyonwizu4:/media/hdd/movie#
root@beyonwizu4:/media/hdd/movie# ls -ald /media/autofs/Public/Test*
drwxr-xr-x    2 root     root             0 Jun 18 16:28 /media/autofs/Public/Test_Wiz_share
drwxr-xr-x    2 root     root             0 Jun 17 14:48 /media/autofs/Public/Test_junk
drwxr-xr-x    2 root     root             0 Apr  6 10:36 /media/autofs/Public/Test_logs
root@beyonwizu4:/media/hdd/movie#

[prl]

So few changes, so many bugs

Try fc-symlink3-installer.zip.

[Grumpy_Geoff]

So few changes, so many bugs

Much more betterer
I created symbolic links to -

• a folder and accepted the default name
• a folder and changed the default name
• a file and changed the default name

All tests passed:

Code: Select all

root@beyonwizu4:/media/hdd/movie# ls -al Test_W*
lrwxrwxrwx    1 root     root            35 Jul  3 14:12 Test_Wiz_share -> /media/autofs/Public/Test_Wiz_share
lrwxrwxrwx    1 root     root            35 Jul  3 14:14 Test_Wiz_share-2 -> /media/autofs/Public/Test_Wiz_share
lrwxrwxrwx    1 root     root            35 Jul  3 14:13 Test_Wiz_share1 -> /media/autofs/Public/Test_Wiz_share
root@beyonwizu4:/media/hdd/movie#
root@beyonwizu4:/media/hdd/movie# ls -al Link*
lrwxrwxrwx    1 root     root            74 Jul  3 14:15 Link 2 My Kitchen Rules [QSF].ts -> /media/autofs/Public/20180417 1154 - 7HD Perth - My Kitchen Rules [QSF].ts
-rw-r--r--    1 root     root            12 Jul  3 14:17 Link 2 My Kitchen Rules [QSF].ts.cuts
root@beyonwizu4:/media/hdd/movie#

The cuts file comes from me playing the linked file.

[prl]

Thanks for digging out those bugs.

[Grumpy_Geoff]

No probs.
I wasn't going to bother testing, as I thought you made it sound like it was such a simple change, but I thought don't be rude, if an alpha is offered then test it - and looked at what happened

[prl]

By the way, I don't think you expressed an opinion on whether, with the action on "3" removed, "4" and "5" should be left as-is, or have their actions moved to "3" and "4". Which goes back to why the alpha was requested in the first place.

[Grumpy_Geoff]

By the way, I don't think you expressed an opinion on whether, with the action on "3" removed, "4" and "5" should be left as-is, or have their actions moved to "3" and "4". Which goes back to why the alpha was requested in the first place.

You got me there. I was going with the flow of "4" and "5" should be left as-is.

[adoxa]

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 can't think of any function to fill it, but how about "Properties"? This would be useful to see the size in bytes, or when a long name takes over the header.

[prl]

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 can't think of any function to fill it, but how about "Properties"? This would be useful to see the size in bytes, or when a long name takes over the header.

Not a bad idea. Should it display a popup with the file base name and info like this:

FileName
112 MB Thu Jan 1 1970 10:00:00 Mode 644

Any other data about the file?

[adoxa]

I can't think of any function to fill it, but how about "Properties"? This would be useful to see the size in bytes, or when a long name takes over the header.

Not a bad idea. Should it display a popup with the file base name and info like this:

FileName
112 MB Thu Jan 1 1970 10:00:00 Mode 644

Any other data about the file?

I'd prefer separate lines. File size should be bytes - "123,456,789 bytes" (perhaps with " (118 MiB)" if you really want it). Perhaps time should use the movie list format? If it's a symlink, its target.

[prl]

I can't think of any function to fill it, but how about "Properties"? This would be useful to see the size in bytes, or when a long name takes over the header.

Not a bad idea. Should it display a popup with the file base name and info like this:

FileName
112 MB Thu Jan 1 1970 10:00:00 Mode 644

Any other data about the file?

I'd prefer separate lines. File size should be bytes - "123,456,789 bytes" (perhaps with " (118 MiB)" if you really want it). Perhaps time should use the movie list format? If it's a symlink, its target.

At this level, I think the same argument applies to time as you've made for size: full HH:MM:SS time in 24-hour clock.

[IanSav]

Hi,

I think that making a file properties screen for option 3 could be a good idea. I would go all out and display everything available about the object including owner, group, number of links etc. This could be helpful diagnosing issues on local or remote file systems.

I was also wondering if there should be an option to allow setting of any permission bits rather than just the 644/755 option. This could be a replacement for option 3 or it could be an enhancement for option 4 with the object properties taking the number 3 slot.

Regards,
Ian.

[prl]

I think that giving all the information that's in a full ls -li listing is a good idea. Showing the permissions symbolically as well as an octal number is probably also useful.

I was also wondering if there should be an option to allow setting of any permission bits rather than just the 644/755 option.

I suspect that anyone who cares enough about the permissions being limited to 644/755 will probably be able to do what they want in the commandline interface.

Pretty much everything (including the command-line interface) runs as root: a file can be read or written to, no matter what its read or write permissions are and can be executed if any execute bit is set, no matter what its ownership is, so fine access control doesn't seem to have much point.

Also, if you care about user and group permissions, you'd probably want to be able to set the owner and group of the file, too.

Calling 644 "archive mode" is a bit silly, though, and it's a term I've never otherwise heard for that permission setting.

[IanSav]

Hi Prl,

I was thinking that the extra information and controls may come into play when network mounts are taken into consideration.

Regards,
Ian.

[IanB]

...
Calling 644 "archive mode" is a bit silly, though, and it's a term I've never otherwise heard for that permission setting.

It dates back to samba from the Windows 3.11 wfw and win95 era when the various Unix execute bits were stolen to map various fat file system attributes like the Archive, System and Hidden bits into the Unix file system samba was using.

[adoxa]

For those that have them, the output of ffprobe or file could be handy, too.

Code: Select all

Name: name
Size: 123,456,789 bytes (118 MiB)
Date: 2018-07-04
Time: 12:14:18
Mode: rwxr-xr-x (755)
Link: target (only present if name is a symlink)

Output of ffprobe or file, when available.

[adoxa]

Enhancement #657: Refactor FileList in FileCommander

A side-effect of this change was the font decreasing from 20 to 18. Is this something that should be restored in File Commander's FileList; the default changed in Component's FileList; an alias added to the skins; or something I should change locally myself?

[prl]

Enhancement #657: Refactor FileList in FileCommander

A side-effect of this change was the font decreasing from 20 to 18. Is this something that should be restored in File Commander's FileList; the default changed in Component's FileList; an alias added to the skins; or something I should change locally myself?

I allowed it to default to the values set in Component.FileList because that has the ability to use the FileList font alias for the font size and item height, while the old code for FileCommander.FileListmod just had fixed values, and I didn't want to add a new font alias. Of course, increasing the font size in the alias will increase it in all uses of FileList (e.g. in the various LocationBox classes), but I don't think that would be a bad thing.

I think that adding the font alias to the skin may be the cleaner way to handle it (no changes to the Python code that way).

[adoxa]

I think that adding the font alias to the skin may be the cleaner way to handle it (no changes to the Python code that way).

I think that changing the default in the Python code may be the cleaner way to handle it (no changes to the skins that way).

My preference (what I've done personally) is to change the default to 20. I think something should be changed in any event, as size 18 with a height of 25 looks too spaced out (not that I really noticed in the location box, but it was really noticeable after it changed in File Commander).

[IanSav]

Hi,

I haven't had time to look at the code involved but in many cases fonts are now specified in skin parameters. It is important not to hard code fonts. They should always be made available for change via a skin.

Regards,
Ian.

[prl]

For those that have them, the output of ffprobe or file could be handy, too.

Code: Select all

Name: name
Size: 123,456,789 bytes (118 MiB)
Date: 2018-07-04
Time: 12:14:18
Mode: rwxr-xr-x (755)
Link: target (only present if name is a symlink)

Output of ffprobe or file, when available.

file is available as a package. I couldn't find an ffprobe package. There are Python file-magic modules that will perform the same actions as file without running a process, but I couldn't find one installed or obviously available as a package.

The "Link" field could perhaps be broadened to "File type" to reflect the file type mode bits: regular file, symbolic link, block device, directory, character device, FIFO (aka named pipe).

Device minor/major instead of size for device files?
User & group?
Link count?
All times: status changed, read, write?
The "other" mode bits: setuid, setgid, sticky (who knows what that's for any more )?
Number of blocks?
Preferred write size?

Arcarna such as file's device minor/major, inode number?

[prl]

I haven't had time to look at the code involved but in many cases fonts are now specified in skin parameters. It is important not to hard code fonts. They should always be made available for change via a skin.

Skin-settable via a font alias:

Code: Select all

class FileList(MenuList):
	def __init__(self, directory, showDirectories=True, ...):
		...
		font = skin.fonts.get("FileList", ("Regular", 18, 25))
		self.l.setFont(0, gFont(font[0], font[1]))
		self.l.setItemHeight(font[2])

[IanSav]

Hi Prl,

file is available as a package. I couldn't find an ffprobe package. There are Python file-magic modules that will perform the same actions as file without running a process, but I couldn't find one installed or obviously available as a package.

I think this is an optional component of BusyBox. I don't believe that the option has been selected for any of the Enigma2 images.

The "Link" field could perhaps be broadened to "File type" to reflect the file type mode bits: regular file, symbolic link, block device, directory, character device, FIFO (aka named pipe).

Device minor/major instead of size for device files?
User & group?
Link count?
All times: status changed, read, write?
The "other" mode bits: setuid, setgid, sticky (who knows what that's for any more )?
Number of blocks?
Preferred write size?

Arcarna such as file's device minor/major, inode number?

I use information like major / minor device numbers to work out if files can be hard linked etc. I am all for as much information as can be efficiently accrued.

Regards,
Ian.

[adoxa]

I couldn't find an ffprobe package.

It's part of FFmpeg (similar to MediaInfo). GStreamer has gst-discoverer-1.0, but apparently that's not included.

The "Link" field could perhaps be broadened to "File type" to reflect the file type mode bits: regular file, symbolic link, block device, directory, character device, FIFO (aka named pipe).

Sure (as "Type" to keep labels to four characters ). Directly after "Name" might be better, then, too.

Device minor/major instead of size for device files?
User & group?
Link count?
All times: status changed, read, write?
The "other" mode bits: setuid, setgid, sticky (who knows what that's for any more )?
Number of blocks?
Preferred write size?

Arcarna such as file's device minor/major, inode number?

The first one maybe, I don't see much of a need for the rest (although apparently IanSav does).

[peteru]

md5, sha1 and sha256 hashes / checksums can be handy, but expensive.

[adoxa]

I've now thought of a new operation - copy to a new name. I missed the end of Madam Secretary, so downloaded the last few minutes. I'd like to copy the eit from the recording, but atm that means copying to another directory, renaming there, then moving back.

[prl]

I've now thought of a new operation - copy to a new name. I missed the end of Madam Secretary, so downloaded the last few minutes. I'd like to copy the eit from the recording, but atm that means copying to another directory, renaming there, then moving back.

Move, too? Perhaps they should both be handled the way symlink does it.

[adoxa]

I've now thought of a new operation - copy to a new name. I missed the end of Madam Secretary, so downloaded the last few minutes. I'd like to copy the eit from the recording, but atm that means copying to another directory, renaming there, then moving back.

Move, too? Perhaps they should both be handled the way symlink does it.

Move is rename.

[prl]

On the topic of the various sorts of additional information that might be gleaned from files: checksums (MD5, etc), file "magic number" checking programs and media format information (ffprobe, mediainfo).

While extracting information from the stat() system call leaves all the file metadata unchanged, extracting information from the file contents can change that access time on the file.

Also, the information from some of those programs (especially ffprobe & mediainfo), is quite lengthy and may be better off in a separate functions. They also each have large numbers of commandline options.

[IanSav]

Hi,

Adding an action function to position 3 would be a better UI choice. The information option can still be added as a new item at the end of the list.

Regards,
Ian.

[adoxa]

While extracting information from the stat() system call leaves all the file metadata unchanged, extracting information from the file contents can change that access time on the file.

Yes, so?

Also, the information from some of those programs (especially ffprobe & mediainfo), is quite lengthy and may be better off in a separate functions. They also each have large numbers of commandline options.

I was originally think a message box would suffice, but with this output a console window could be used. Hm, maybe just running ls -l FILE or ls -l FILE; ffprobe FILE (and/or file if that's available) would be good enough (or maybe even prompt for a command to run, defaulting to ls -l FILE). Is mediainfo available on the box? The default options are fine.

I think I'd rather see "copy as new name" as 3, now. I could live without the properties - it was just a thought when I wanted to see the full file size (don't even remember why, now) and when a long name blocked out the date (looking at my offline updated packages).

[prl]

While extracting information from the stat() system call leaves all the file metadata unchanged, extracting information from the file contents can change that access time on the file.

Yes, so?

I just think that looking at a file's basic properties shouldn't change them.

[IanSav]

Hi Prl,

I just think that looking at a file's basic properties shouldn't change them.

It is holistic and considered thinking like this that makes Prl's code and suggestions so valued and stable from their conception.

Enigma2 changes need to be planned and fully considered to avoid issues.

Regards,
Ian.

[prl]

So few changes, so many bugs

I just noticed. It's the issue number of the beast - #666: Operation of link creation in FileCommander doesn't match help text. No wonder I was having problems.

[prl]

Bug #666: Operation of link creation in FileCommander doesn't match help text

Fix submitted. "2" now prefills the link name and allows you to edit it and the action on "3" is gone, perhaps to be replaced with "file info" in some form.

Next up:
Issue #658: Add help screens to FileCommander

[adoxa]

I've had another thought. Since the header allows for two lines, make it an actual two-line header: one line for the path/name and the other for the stats.

[IanSav]

Hi Adoxa,

I've had another thought. Since the header allows for two lines, make it an actual two-line header: one line for the path/name and the other for the stats.

What "header"?

Regards,
Ian.