Beyonwiz Australia

IanSav wrote: ↑

Mon Jul 16, 2018 02:20

Also, would you consider changing the MENU button menu structure to match that used by the MovieSelection layout? That is, make all the numeric functions an entry in a menu triggered by the MENU button and have the first item of that menu be "Settings..." to take the use to the configuration settings. (The direct access to the numeric functions should be retained.)

Like this?
Note hint to install ffmpeg package so that ffprobe can be run. In this test, the file package was already installed for the file command, but if it isn't it gets a similar entry.

Hi Prl,

YES! Exactly that.

Regards,
Ian.

... but with a capital "C" in Commander, please.

Grumpy_Geoff wrote: ↑

Wed Jul 18, 2018 19:33

... but with a capital "C" in Commander, please.

Good idea

Except for the LiveTV video showing through it looks great.

prl wrote: ↑

Wed Jul 18, 2018 18:53

Note hint to install ffmpeg package so that ffprobe can be run.

I wonder if that could be phrased a little differently, as it could be taken as going to install the ffmpeg package. I have no ideas atm, though.

adoxa wrote: ↑

Wed Jul 18, 2018 22:51

prl wrote: ↑

Wed Jul 18, 2018 18:53

Note hint to install ffmpeg package so that ffprobe can be run.

I wonder if that could be phrased a little differently, as it could be taken as going to install the ffmpeg package. I have no ideas atm, though.

I hadn't thought about that possible interpretation, and you're right, it is ambiguous. I thought of it as an imperative to the user, but it can also be read as an imperative to the UI.

Whatever it is, it has to be short. I changed it from "You need to install package '%s' to run '%s' command" which is cleared wording than "Install package '%s' to run '%s' command", but too long (both in the help screens and in the popup menu. It needs to have both the program name and the package name, because for ffprobe, they're different. "You must ..." might squeeze in.

An alternative would be to actually have the command do the installation, of course (with a "do you want to" popup).

How about about simply "Run ffprobe (ffmpeg must first be installed)"

Or even just "(requires ffmpeg)" if you need it really short. Anyone who needs the command will know what needs doing.

I also interpreted the screenshot wording as if the option would install ffmpeg on the users behalf.

MrQuade wrote: ↑

Wed Jul 18, 2018 23:20

How about about simply "Run ffprobe (ffmpeg must first be installed)"

Or even just "(requires ffmpeg)" if you need it really short. Anyone who needs the command will know what needs doing.

I also interpreted the screenshot wording as if the option would install ffmpeg on the users behalf.

Since brevity is not essential, my preference would be: "Run ffprobe (ffmpeg must be installed)".

And I don't know what ffprobe does but you can be sure I'll investigate it at some stage.

Hi Prl,

An alternative could be to have option 7 read "Install ffprobe option" if the package is not installed and change the message to "Run ffprobe command" when it is available. The actions are clearly defined and automatically adjust to fit the context. There should be no unexpected pop ups or ambiguity in the option messages with this arrangement.

Regards,
Ian.

IanSav wrote: ↑

Thu Jul 19, 2018 01:34

Hi Prl,

An alternative could be to have option 7 read "Install ffprobe option" if the package is not installed and change the message to "Run ffprobe command" when it is available. The actions are clearly defined and automatically adjust to fit the context. There should be no unexpected pop ups or ambiguity in the option messages with this arrangement.

Regards,
Ian.

Highly desirable option. It is reminiscent of the way the NFS server install menu operates, so there is a degree of consistency too.

Hi Paul,

Paul_oz53 wrote: ↑

Thu Jul 19, 2018 03:43

... there is a degree of consistency too.

Does that surprise you coming from me?

Regards,
Ian.

IanSav wrote: ↑

Thu Jul 19, 2018 01:34

An alternative could be to have option 7 read "Install ffprobe option" if the package is not installed and change the message to "Run ffprobe command" when it is available.

I'd already suggested that the buttons/menu entries should do the install rather that warning about the programs not being installed, and I'd pretty much decided that that was what I'd do anyway. The mechanism to change the menu entries/help text depending whether the required program is installed is already in place.

IanSav wrote: ↑

Thu Jul 19, 2018 01:34

The actions are clearly defined and automatically adjust to fit the context.

All I'd suggest is perhaps changing in the text is to make it "Install ffprobe option (package ffmpeg)" so that people know more accurately what the action will do. Alternatively the "Do you want to install ...?" popup could mention the package name. That would leave the menu item cleaner.

IanSav wrote: ↑

Thu Jul 19, 2018 01:34

There should be no unexpected pop ups or ambiguity in the option messages with this arrangement.

It all depends on what you think is "unexpected pop ups". There will be a "Do you want to install ...?" popup, because the action can be triggered just by pressing 6 or 7 in the File Commander file lists screen, and I wouldn't want it unilaterally starting installations that the user might not expect.

Hi Prl,

My reservation relates to how many of the network screens operate. If the networking module is not installed the user is taken directly to an installation screen. I prefer that the normal status screen be displayed showing that the option is not installed and an function provided to install that option. This is much better visually and for user experience and also faster to back out if required.

As for the text to be displayed on the menu if ffprobe is not installed that was not specifically significant in my request. Use what ever text makes best sense.

Regards,
Ian.

Enhancement #679: Add .log as a text file type in File Commander
Enhancement #680: Remove configuration clutter when ffprobe is run from File Commander
Enhancement #681: Show link targets in File Commander file status
Enhancement #682: Offer to install required packages in File Commander

Updated progress status.

Moving a file and then attempting to use it crashes (since it's still present in the list if you don't refresh, but not in the filesystem). Everything else seems okay, so I think this is sufficient:
If you're doing general cleanup it might also be nice to change _, filetype... to filetype...[1], otherwise the exception later on won't work. Not that it matters, since I don't think that exception will ever be caught, so it could be removed, too.

adoxa wrote: ↑

Fri Jul 20, 2018 18:26

If you're doing general cleanup it might also be nice to change _, filetype... to filetype...[1], otherwise the exception later on won't work. Not that it matters, since I don't think that exception will ever be caught, so it could be removed, too.

There are several other places where _, value = ... is used, and they should probably also be cleaned up.

adoxa wrote: ↑

Fri Jul 20, 2018 18:26

Moving a file and then attempting to use it crashes (since it's still present in the list if you don't refresh, but not in the filesystem).

Bug #684: Crash in File Commander when file used (OK) directly after move

Updated progress status

Here's a an alpha patch for
Enhancement #678: Settings and actions menu for FileCommander
Enhancement #680: Remove configuration clutter when ffprobe is run from File Commander
Enhancement #682: Offer to install required packages in File Commander

The patch changes change the function of "MENU" in the FileCommander (MENU>Sources / Files from live TV) so that it opens a context menu with accelerator buttons (the same button/action pairs as for the existing button actions for INFO, number buttons and coloured buttons). Within the context menu, MENU is a shortcut to open the settings menu. The context menu is a popup in the built-in skins and a full screen in OverlayHD.

Buttons 6 & 7 now offer (I hope unambiguously) to install the packages needed for them to work. When the packages are installed, menu items are added (without accelerator buttons) to allow them to be removed.

Running ffprobe from File Commander to get information about media files now suppresses the extremely verbose banner showing all the ffprobe config settings.

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 20180718beta. It will not work on firmware earlier than 20180718.

It is compatible with OverlayHD and if OverlayHD is installed, it makes the appropriate changes to OverlayHD for the new functions to operate correctly. It should also co-exist with Patches By Adoxa.

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-contextmenu-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
If the patch is installed. If you don't have OverlayHD installed, the line containing "OverlayHD" won't be shown.


Comments welcome!

prl wrote: ↑

Wed Jul 25, 2018 14:18

I'm not sure whether it will co-exist with Patches By Adoxa, so I'd advise uninstalling them before installing this alpha.

The current Patches does not modify skins or File Commander, so there should be no issues.

adoxa wrote: ↑

Wed Jul 25, 2018 14:45

prl wrote: ↑

Wed Jul 25, 2018 14:18

I'm not sure whether it will co-exist with Patches By Adoxa, so I'd advise uninstalling them before installing this alpha.

The current Patches does not modify skins or File Commander, so there should be no issues.

Thanks. I've changed the text accordingly.

prl wrote: ↑

Wed Jul 25, 2018 14:18

Running ffprobe from File Commander to get information about media files now suppresses the extremely verbose banner showing all the ffprobe config settings.

Indirectly related to this, it looks like you need .updateScrollbar() to go with .setPos(0).

adoxa wrote: ↑

Wed Jul 25, 2018 16:35

prl wrote: ↑

Wed Jul 25, 2018 14:18

Running ffprobe from File Commander to get information about media files now suppresses the extremely verbose banner showing all the ffprobe config settings.

Indirectly related to this, it looks like you need .updateScrollbar() to go with .setPos(0).

Thanks. I'd seen that the scroll-to-top worked, but the far side of the screen is hidden in my PVR-farm-on-the-desk setup unless I look specifically for something there.

Fixed now.

prl wrote: ↑

Wed Jul 25, 2018 14:18

...Comments welcome!

The alpha installed without issue. The extension menu works fine. It offered to install ffprobe, and subsequently the option changed to execute.
No issues

Thanks, Geoff.

adoxa wrote: ↑

Wed Jul 18, 2018 15:10

Here's some patches to consider.

Use the "txt" image for log files.

I've implemented this, but in a slightly different way. I've copied "txt"-typed extensions that were in FileCommander.FileList.LOCAL_EXTENSIONS but not in addons.key_actions.TEXT_EXTENSIONS into TEXT_EXTENSIONS (so they become editable) and removed all the explicit "txt"-typed extensions from LOCAL_EXTENSIONS.

The "txt"-typed extensions are now constructed from TEXT_EXTENSIONS but if the extension is already in LOCAL_EXTENSIONS, it isn't over-ridden by the update. so, for example, although ".py" is in TEXT_EXTENSIONS, that doesn't change the "py": "py" mapping in LOCAL_EXTENSIONS.

prl wrote: ↑

Thu Jul 26, 2018 17:01

adoxa wrote: ↑

Wed Jul 18, 2018 15:10

Here's some patches to consider.

Use the "txt" image for log files.

I've implemented this, but in a slightly different way. [...]

That's a good approach.

adoxa wrote: ↑

Fri Jul 20, 2018 18:26

If you're doing general cleanup it might also be nice to change _, filetype... to filetype...[1], otherwise the exception later on won't work. Not that it matters, since I don't think that exception will ever be caught, so it could be removed, too.

The handling of key_action.onFileAction()'s dirsource and dirtarget arguments is also bizarre.

Enhancement #678: Settings and actions menu for FileCommander
Enhancement #680: Remove configuration clutter when ffprobe is run from File Commander
Enhancement #682: Offer to install required packages in File Commander
All submitted (including a fix to the scroll bug that adoxa found).

Updated progress status

prl wrote: ↑

Sat Jul 14, 2018 16:26

It doesn't look like mediainfo is available for File Commander to use.

Here's mediainfo for the T series (tested on T2) and U4 (untested). For those without a command line the simplest way to test might be to move/link it to /usr/bin/file or ffprobe (whichever one you don't have) and use that in File Commander (the mediainfo command is commented out).

On a somewhat related note, some sort of "tee" functionality might come in handy. Maybe the console could also write to /tmp/console.txt, the user copying it if they want to keep it. I'll do that...

How does this look for a two-part list header for File Commander (from OverlayHD skin)?
The builtin skins are similar, but with yellow text.

With the mode string I think "Mode" could be dropped (and remove the leading zero, too).

The leading zero is significant and encodes the suid, sgid and sticky bits. Those bits are also reflected in the symbolic mode string.

Even so, I would rather only see four digits when necessary. That's not very often. E.g.: the U4's 20180417 USB fw has 14014 files and directories: one directory is sticky and 17 files are suid. That's 0.13% when it's not going to be zero.

adoxa wrote: ↑

Fri Jul 27, 2018 12:58

On a somewhat related note, some sort of "tee" functionality might come in handy. Maybe the console could also write to /tmp/console.txt, the user copying it if they want to keep it. I'll do that...

Submitted. I've also added LEFT/RIGHT as page up/down and CH+/- as first/last page (matching File Commander's viewer).

Hi Prl,

How does the display look for a directory? Is it easy to make these items appear in fixed columns so that the details don't jump around as you move up and down the file list?

If space is tight I would be happy to lose the "Mode" key word. I think the leading zero is significant and should stay.

I am also used to seeing the modes on the left of the line. Would you consider trying changing the order of the details?

Regards,
Ian.

Hi Adoxa,

adoxa wrote: ↑

Fri Jul 27, 2018 23:01

Submitted. I've also added LEFT/RIGHT as page up/down and CH+/- as first/last page (matching File Commander's viewer).

I would like to change the navigation buttons to match the refactored Setup navigation. We need a unified approach to screen navigation.

Regards,
Ian.

adoxa wrote: ↑

Fri Jul 27, 2018 22:46

Even so, I would rather only see four digits when necessary. That's not very often. E.g.: the U4's 20180417 USB fw has 14014 files and directories: one directory is sticky and 17 files are suid. That's 0.13% when it's not going to be zero.

There are 12 file permission bits, not 9. The form of the octal representation reflects that. It's the same representation used in the file info popup, and on-one mentioned that as an issue.

All 12 bits are permission also reflected in the symbolic form of the permissions.

IanSav wrote: ↑

Fri Jul 27, 2018 23:05

How does the display look for a directory?

The mode string copies the mode string in ls -l, so a 0777-mode directory will be drwxr-xr-x.

More fully, the first character of the mode string in the list headers is:
'-': Regular file
'd': Directory
'l': Symbolic link
'c': Character device
'b': Block device
's': Unix domain Socket
'p': FIFO (aka 'named pipe')

Each 'x' bit position can take 1 of 4 values for the user and group:
'-': not execute and not setu/gid
'x': execute and not setu/gid
'S': not execute and setu/gid (this is a rarely-used combination)
's': execute and setu/gid

And for the permissions for "other":
'-': not execute and not sticky
'x': execute and not sticky
'T': not execute and sticky (this is a rarely-used combination)
't': execute and sticky

In the file info popup, the file type character isn't displayed, because that information is already spelt out in the "Type" field.

Unless the font is fixed-width, the width of the symbolic mode string will vary slightly depending on its contents.

IanSav wrote: ↑

Fri Jul 27, 2018 23:05

Is it easy to make these items appear in fixed columns so that the details don't jump around as you move up and down the file list?

There are three options for that that i can think of:

• fixed-width font for the file info line (and if so, perhaps for the file path text, too), but since the size text is variable length, that would need to go last.
• 3 Label fields instead of 1 (mode, size, modification time)
• A single-line TemplatedMultiContent "list"

As mentioned above, unless the mode string is in a fixed-width font, so it will jiggle about a bit as the mode string changes anyway.

IanSav wrote: ↑

Fri Jul 27, 2018 23:05

If space is tight I would be happy to lose the "Mode" key word. I think the leading zero is significant and should stay.

I'm happy for the "Mode" to stay or go. I think that the ls -l style mode info makes it clearer that it is the mode, at least for people familiar with the U*ix ls command. As I said in the previous post, the 4-digit octal mode value simply reflects the full 12-bit permissions part of the file mode.

The complete file mode is:
TTTTsstrwxrwxrwx

Where T are the file type bits (file, directory, character special, block special, etc), s are the set uid/gid bits, in that order, t is the sticky bit and rwx are read/write execute permission bits for user (owner), group and others, in that order.

IanSav wrote: ↑

Fri Jul 27, 2018 23:05

I am also used to seeing the modes on the left of the line. Would you consider trying changing the order of the details?

I simply left the order unchanged (the code that creates the mode info string has been completely re-written). I have no strong feelings about the order.

The ls -l order is mode, size, modification time.

Unix trivia time: is anyone old enough to know what the original purpose of the sticky bit was without looking it up? It dates to Version 6 Unix.

Is it just me, pressing MENU in File Commander in 20180727 doesn't result in the context menu appearing, using Full-Metal-Wizard skin. Is the below log snippet relevant? Swapping to easy-skin-aus-hd is no different.

The invisible context menu is actionable though, as pressing OK brings up the settings screen.

Assuming no other File Commander changes were in the update, should I just reinstall the "contextmenu-installer" alpha patch until this is fixed?
Or do I need a hacked alpha mark 2 that just has the skin changes (i.e. removing the /usr/lib/enigma2/python stuff in the alpha mark 1).

Grumpy_Geoff wrote: ↑

Sat Jul 28, 2018 12:20

Assuming no other File Commander changes were in the update, should I just reinstall the "contextmenu-installer" alpha patch until this is fixed?

That should work, I think you'll just lose the scrollbar fix.

I forgot to issue pull requests for the matching skin changes for the context menu. I have done that now (including a pull request for Overlay).

Until a new update with the skin changes is available, it should be OK to use the contextmenu-installer patch. As before, it won't interfere with Patches by Adoxa, and it won't interfere with any of adoxa's other changes that were included in 20180727.

Hi Prl,

If you are agreeable, I would like to see the two lines of the heading become a TemplatedMultiContent. That was the order and position of all the elements can be at the skin designers discretion. The file name can be first or last, the attributes can be in any order with any alignment.

If you can do this before the skin updates get released then you could combine the code change with the missed skin changes.

Regards,
Ian.

Hi Prl,

For the skin writer TemplatedMultiContent can often be easier to manipulate.

I suggested adding the file name as one of the objects in the TemplatedMultiContent so that everything in the header is controlled by the one on screen object. You could also add other properties like owner, group (number and name), number of links etc as optional elements that could be nominated for display in a TemplatedMultiContent.

EDIT: I am following up on a post from Prl that no longer exists!

Regards,
Ian.

Sorry, I decided I needed to explain myself better than in the original.

The downside of using a single TemplatedMultiContent for both lines of the heading is that then both lines must have the same height.

I was proposing only using the TemplatedMultiContent for the file status information, with a two-line-high Label for the file path.

Using 4 Labels, one for the file path and one each for file size, file modification time and file mode gives the greatest layout flexibility.

Both the TemplatedMultiContent methods and the 4-Label method require changes in both the code and skin to add more fields, but I don't think it's a great idea to try to make the header fields replacements for the file status popup.

Bug #661: File commander extension filters incomplete
Enhancement #679: Add .log as a text file type in File Commander
Bug #683: Incorrect name prefill in FileCommander Rename
Bug #684: Crash in File Commander when file used (OK) directly after move

All submitted.

Updated progress status

Hi Prl,

prl wrote: ↑

Sat Jul 28, 2018 13:21

Sorry, I decided I needed to explain myself better than in the original.

Not a problem. Quick replies is a problem when you spend lots of time on the forum.

prl wrote: ↑

Sat Jul 28, 2018 13:21

The downside of using a single TemplatedMultiContent for both lines of the heading is that then both lines must have the same height.

I was proposing only using the TemplatedMultiContent for the file status information, with a two-line-high Label for the file path.

Constrained heights would be a problem.

prl wrote: ↑

Sat Jul 28, 2018 13:21

Using 4 Labels, one for the file path and one each for file size, file modification time and file mode gives the greatest layout flexibility.

Both the TemplatedMultiContent methods and the 4-Label method require changes in both the code and skin to add more fields, but I don't think it's a great idea to try to make the header fields replacements for the file status popup.

The big advantage of the TemplatedMultiContent is that the extra attributes can be programatically made available for each file item but the skin designer can choose which of those items they wish to use.

The enhanced display is not meant to replace the new information but to simply be able to draw on any of the data elements that the skin designer would like to make available as a column heading highlight. If the items are all separate labels then all the elements must be listed in the skin and then hidden from display. The TemplatedMultiContent is easier.

Regards,
Ian.