FileCommander.Inputmod & InputBoxmod

[IanSav]

Hi,

I am very busy testing and merging the new VirtualKeyBoard and NumericalTextInput into other Enigma2 images at the moment so I can't test this code personally.

That said, simply by reading the posts here I am getting confused about the purpose of these changes. What is the benefit to the users? So far the changes appear to be adding confusion rather than improvement.

Can the changes please be restated clearly and succinctly, with some examples, so we can get clarity of what is intended.

Regards,
Ian.

[prl]

My understanding is that adoxa would like to see the path name for the current directory in all displayed path names in the File Commander file list headers. That's the case for all entries in a "normal" directory listing in File Commander, except for the Parent Directory entry, which currently shows the path name of the current directory's parent directory (funnily enough).

Since it's the Parent Directory entry that is in focus when you first enter a directory in the File Commander, the first thing you see in the list header is the name of the current directory's parent directory. It's that, I think that adoxa dislikes, and I can see his point.

However, I don't think his proposed solution is a good one. The current path display when Parent Directory entry is in focus is entirely consistent, though perhaps confusing.

One alternative would be to split the path entry so that the current directory path is shown in one widget and the in-focus name is shown in another.

So for a normal directory /current/directory/adirectory the header display might be:

/current/directory
adirectory

and when Parent Directory is in focus in the same current directory, you might have either:

/current/directory
..

or

/current/directory
<Parent Directory>

[adoxa]

Since it's the Parent Directory entry that is in focus when you first enter a directory in the File Commander, the first thing you see in the list header is the name of the current directory's parent directory. It's that, I think that adoxa dislikes, and I can see his point.

That's right. I save the right side, which is usually /home/root/logs/, but upon starting it displays /home/root/, which is misleading. Same when you select a directory in one pane, then switch to the other - it looks like the selected directory is current (but that's not as much of a problem, since you should be aware of what you're doing).

One alternative would be to split the path entry so that the current directory path is shown in one widget and the in-focus name is shown in another.

I did that initially (dir + "\n" + filename), but restored the single name to keep the longer display. I'm ambivalent, though, as names usually aren't that long (and info can show longer names). Could possibly do both - if the name is longer than the width use a single name, otherwise split it (but that's a bit of extra code for little benefit). It really would need a third header widget, though, as "\n" wouldn't work with a long path.

and when Parent Directory is in focus in the same current directory, you might have either:

/current/directory
..

or

/current/directory
<Parent Directory>

That would work with the split header, but not with a single name (well, I guess "/current/directory/.." would work, but not exactly pretty). Should probably use "<Parent Directory>" (and "<List of Storage Devices>") to match the selection.

[prl]

That would work with the split header, but not with a single name (well, I guess "/current/directory/.." would work, but not exactly pretty).

I was just about to suggest exactly that. I think it's the cleanest and most consistent answer to the problem.

Should probably use "<Parent Directory>" (and "<List of Storage Devices>") to match the selection.

I disagree, I think that the path name for the current focus should always be displayed as the pathname in the header. That includes displaying things like /mnt/hdd for entries in the <List of Storage Devices>.

The <List of Storage Devices> has a slight whiff of DOS device letters to me.

[adoxa]

That would work with the split header, but not with a single name (well, I guess "/current/directory/.." would work, but not exactly pretty).

I was just about to suggest exactly that. I think it's the cleanest and most consistent answer to the problem.

How would "<List of Storage Devices>" be displayed? It's not ".." nor "/" (and ending with "//" isn't a good idea in any event) and anything else goes back to the original problem of hiding the current directory.

[prl]

That would work with the split header, but not with a single name (well, I guess "/current/directory/.." would work, but not exactly pretty).

I was just about to suggest exactly that. I think it's the cleanest and most consistent answer to the problem.

How would "<List of Storage Devices>" be displayed? It's not ".." nor "/" (and ending with "//" isn't a good idea in any event) and anything else goes back to the original problem of hiding the current directory.

I already said: the path name in the header for the "<List of Storage Devices>" file list should show the path name of the mount point currently in focus: /, /media/hdd, /media/usb, /media/automount/MyNAS, and so on. They are, after all, what those list entries represent. The file status header should show the info for the directory path being displayed.

"//" is a perfectly legal Unix path. It means the same thing as "/./." (since the empty path segment name is interpreted as "."), and that, in turn, means the same as "/". That's not to say that it is a sensible name to use

Code: Select all

root@beyonwizu4:/media/hdd/logs# ls / //
/:
bin       etc       lib       picon     run       sys       var
boot      hdd       media     piconlcd  sbin      tmp
dev       home      mnt       proc      share     usr

//:
bin       etc       lib       picon     run       sys       var
boot      hdd       media     piconlcd  sbin      tmp
dev       home      mnt       proc      share     usr
root@beyonwizu4:/media/hdd/logs#

("/.." also means the same as "/", since uniquely, the '..' entry in the root points to the same inode as '.' in the root directory, which is, of course the root directory, inode 2).

"<List of Storage Devices>" doesn't actually represent any real filesystem object, and the items listed in it don't share a common parent directory. It's a figment of enigma2's imagination and looks to me like a list of fancy names for DOS device letters. It's also bizarre that in the File Commander's view of the universe, the list is accessed as though it's the parent of the root directory, when in fact everything in it represents objects at or under the root directory.

[adoxa]

I already said: the path name in the header for the "<List of Storage Devices>" file list [...]

I mean when it's used in lieu of "<Parent Directory>".

"<List of Storage Devices>" [...] looks to me like a list of fancy names for DOS device letters.

No, it's fancy names for *nix mount points.

[prl]

I already said: the path name in the header for the "<List of Storage Devices>" file list [...]

I mean when it's used in lieu of "<Parent Directory>".

Sorry, my misunderstanding. It should probably be just "<List of Storage Devices>" with an empty file status area, since it doesn't correspond to any file system object.

"<List of Storage Devices>" [...] looks to me like a list of fancy names for DOS device letters.

No, it's fancy names for *nix mount points.

*nix systems should simply be politely hiding the details of where mount points are to the greatest extent possible.

[adoxa]

Sorry, my misunderstanding. It should probably be just "<List of Storage Devices>" with an empty file status area, since it doesn't correspond to any file system object.

And we're back where we started, with no indication of the current directory. I think the only solution is the three-line header: current directory, selection, stats of the selection (if applicable; I agree with the current implementation in that the parent should not have stats, as I see it as more of an abstract rather than specific directory). If you don't agree maybe this is another one I'll keep to myself...

[IanSav]

Hi Adoxa,

If you can't see a clean solution then perhaps you should hold off until a better alternative makes itself known.

Regards,
Ian.

[adoxa]

For me, the clean solution is the three-line header. You'd lose the extra display of having the full name across two lines, but you'd always know what the current directory is. The question is: do others agree? If not, I'll keep it for myself. If so, would it be okay to move head2 to head3 or should I preserve it and make the new one head3? (For myself I'd keep it simple and just risk a newline in head1.)

[IanSav]

Hi Adoxa,

Are you suggesting that the file path always be split onto two line, one for the path component and the other for the filename component?

This could work except that a long path or a long filename will result in on screen data loss. At the moment the single entry can now be shared between the two available lines. I think I would prefer to leave things as they are now.

Regards,
Ian.

[adoxa]

I've decided to keep the headers as I posted; I won't submit.

Here's something else that probably won't interest many (or any), but still warrants a mention. I sometimes want to take a peek at the .eit file. Rather than writing a viewer for it, I do a hex dump if there's a zero in the first 4096 bytes (which is also all that's dumped).

hexdump.png (64.11 KiB) Viewed 4502 times

You'll notice it's not lined up - turns out that 0 is a little smaller than the rest. (For the standard tuxtxt, it appears OverlayHD has a different version with a dotted zero, but I don't like that. I don't care enough to try tuxtxt_nonbold, which should work, or andale, but that also has a dotted zero).

[MrQuade]

I am having XTree flashbacks!

[prl]

Here's something else that probably won't interest many (or any), but still warrants a mention. I sometimes want to take a peek at the .eit file. Rather than writing a viewer for it, I do a hex dump if there's a zero in the first 4096 bytes (which is also all that's dumped).

I think that it would be useful to have, though when I want to look at a .eit file, I use the strings command. It's strange that 0 has a non-standard width in what's supposed to be a fixed-width font.

[adoxa]

I think that it would be useful to have, though when I want to look at a .eit file, I use the strings command.

I generally want to see the raw bytes, to see the encoding. But there's another option, run strings on a file. A detected binary file could run strings and long TEXT could dump binary, or vice versa. Nah, not worth it.

It's strange that 0 has a non-standard width in what's supposed to be a fixed-width font.

It's even stranger that it hasn't apparently been fixed (the font was released in 2003).

[IanSav]

Hi Adoxa,

Have you tried out the new DejaVu fonts? They are now in OpenPLi, OpenViX and OverlayHD 1.66 and later.

Regards,
Ian.

[adoxa]

Since they're not available for people who haven't installed OverlayHD, they're not really an option (plus they have the dotted zero I don't like).

[IanSav]

Hi Adoxa,

Since they're not available for people who haven't installed OverlayHD, they're not really an option (plus they have the dotted zero I don't like).

The dot aside these fonts are now standard in OpenPLi and OpenViX. If Beyonwiz was keeping up then they would be standard here as well.

Regards,
Ian.

[prl]

You'll notice it's not lined up - turns out that 0 is a little smaller than the rest. (For the standard tuxtxt, it appears OverlayHD has a different version with a dotted zero, but I don't like that. I don't care enough to try tuxtxt_nonbold, which should work, or andale, but that also has a dotted zero).

Here's a more obvious example of the problem:

[Grumpy_Geoff]

Crash in File Commander - run 'file' command.
Crash occured whilst doing a silly thing - '6' (file command) on selection '<List of Storage Devices>'

Code: Select all

{732}<  2488.800> KEY: 7 make KEY_6 ('6',)
{732}<  2488.800> [ActionMap] NumberActions 6
{732}<  2488.801> Traceback (most recent call last):
{732}<  2488.801>   File "/usr/lib/enigma2/python/Components/ActionMap.py", line 51, in action
{732}<  2488.801>   File "/usr/lib/enigma2/python/Plugins/Extensions/FileCommander/addons/key_actions.py", line 288, in run_file
{732}<  2488.801>   File "/usr/lib/enigma2/python/Plugins/Extensions/FileCommander/addons/key_actions.py", line 307, in run_prog
{732}<  2488.801> AttributeError: 'NoneType' object has no attribute 'startswith'
{732}<  2488.802> [ePyObject] (CallObject(<bound method HelpableActionMap.action of <Components.ActionMap.HelpableActionMap instance at 0xae92e990>>,('NumberActions', '6')) failed)

[prl]

It's an instance of a problem common to several commands:
"3": "File/directory status information"
"4": "Change execute permissions (755/644)"
"6": "Run 'file' command"
"7": "Run 'ffprobe' command"
"9": "Calculate file checksums"

All due to not handling a None value for the filename in focus, which is what's returned for '<List of Storage Devices>'.

[prl]

Bug #699: File Commander crashes on some actions on <List of Storage Devices>

[prl]

Bug #699: File Commander crashes on some actions on <List of Storage Devices>

Fix submitted.