Feature request: On-screen keyboard in File Commander.

[sub3R]

Is it possible to make the on-screen keyboard available in File Commander for renaming & editing a file?

I usually use a USB Logitech keyboard for this or use the PC if I'm away from the beyonwiz, but sometimes it would be nice to have an on-screen keyboard available in File Commander to rename a file or to make a quick short edit of a line in a file.

I find the number/letter buttons on the remote pretty much useless for doing this.

[adoxa]

I think I tried doing this quite a while ago, but it wasn't as simple as I thought. I'll give it another go, sometime...

[sub3R]

Thanks. I suspected previously there wasn’t enough interest shown by other users or it was put in the too hard basket.

[MrQuade]

Definitely doesn't smell like a trivial task. The File Commander uses a different method of handling keyboard entry to other parts of the GUI.

I think the interest factor was not high since these keyboard controls would only be expected to be "very occasional use" features to be used when you lack more convenient alternatives.

[prl]

Definitely doesn't smell like a trivial task. The File Commander uses a different method of handling keyboard entry to other parts of the GUI.

But no really good reason for doing so. The FileCommander uses a patched-up Components.InputBox and a wider InputBoxWide for its text input. The media selection screen, MovieSelection, simply goes straight to VirtualKeyBoard for its input.

Now that text scrolling works correctly in VirtualKeyBoard, there's probably a less compelling case to use InputBox rather than VirtualKeyBoard in File Commander. Also, IanSav's new VirtualKeyBoard has a wider text entry box that the older one, too.

I think the interest factor was not high since these keyboard controls would only be expected to be "very occasional use" features to be used when you lack more convenient alternatives.

I tend to agree, but I don't think there'd be much work in changing the InputBoxes to use VirtualKeyBoard instead. FileCommander could even reskin an otherwise empty subclass of VirtualKeyBoard, VirtualKeyBoardWide, in the same way that it reskins InputBox as InputBoxWide.

[prl]

I've created a proposal in the issue tracker so it doesn't get forgotten:
Issue #760: Use VirtualKeyBoard instead of InputBox for text entry in FileCommander

[sub3R]

Thanks Peter. Much appreciated.

[prl]

Thanks Peter. Much appreciated.

There's some discussion going on in the proposal that you might like to look at.

[sub3R]

There's some discussion going on in the proposal that you might like to look at.

I’ve had a look. Pressing TEXT to bring up the keyboard or bring it up by some other method (e.g. via MENU) doesn’t matter to me. I think it would be a shame to have the keyboard available at the expense of losing something that other users find useful though.

I don’t do much text editing in File Commander, but as mentioned before, having a keyboard available would be handy for quick short edits when sitting in front of the Wiz without having to get out the Logitech USB keyboard.

[Grumpy_Geoff]

I’ve had a look. Pressing TEXT to bring up the keyboard or bring it up by some other method (e.g. via MENU) doesn’t matter to me. I think it would be a shame to have the keyboard available at the expense of losing something that other users find useful though.

I sometimes use the FC editor to view long lines of a text file (log or script). I'd rather that "feature" not be lost.

[adoxa]

That's how I use it, too, and the keyboard would just get in the way. There's a couple of possibilities: use TEXT directly on the line to bring up the keyboard, keeping OK for line input/viewing; or use TEXT to bring up a message box for viewing the line, OK would be the keyboard. I was going to wait until it's decided what's happening with the new keyboard.

[sub3R]

There's a couple of possibilities: use TEXT directly on the line to bring up the keyboard, keeping OK for line input/viewing; or use TEXT to bring up a message box for viewing the line, OK would be the keyboard.

How about using TEXT to view the file contents as it does now (I use this quite often). With a line in the file contents highlighted use TEXT to open the keyboard to edit that line. Leave the other coloured button functions as they are.

Having said that, I’ve no idea how hard that would be to do or what complications it would cause.

Edit: I’m not sure how that would work for renaming a file with the keyboard.[/edit]

I was going to wait until it's decided what's happening with the new keyboard.

Perhaps that would be a good idea.

[prl]

There's a couple of possibilities: use TEXT directly on the line to bring up the keyboard, keeping OK for line input/viewing; or use TEXT to bring up a message box for viewing the line, OK would be the keyboard.

How about using TEXT to view the file contents as it does now (I use this quite often). With a line in the file contents highlighted use TEXT to open the keyboard to edit that line. Leave the other coloured button functions as they are.

Having said that, I’ve no idea how hard that would be to do or what complications it would cause.

In Addon - File-Viewer, GREEN Edit already pops up InputBoxWide to edit the line. Having TEXT do the same would be trivial. In my proposal GREEN (and possibly TEXT) would open a wide version of VirtualKeyBoard to do the line editing instead.

Edit: I’m not sure how that would work for renaming a file with the keyboard.[/edit]

I was proposing that in the main screen of FileCommander, BLUE Rename and MENU>Rename file/directory both pop up VirtualKeyBoard instead of InputBox. That's the same behaviour that you get in MovieSelection when you do MENU>Rename.

[sub3R]

I would be happy with both those proposals & I think they would work well.

But unless I’m wrong, that would be doing away with the current editor which I understand both Geoff & adoxa like.

I was trying to come up with a suggested compromise to keep everyone happy.

[prl]

I was trying to come up with a suggested compromise to keep everyone happy.

I didn't see any mention in your post of having access to VirtualKeyBoard to edit the text. I though that having that ability was a key aspect of this topic, so I'm now not sure what you were suggesting. Both InputBox and VirtualKeyBoard can be used to edit text.

[adoxa]

I have no problem directly using the Virtual Keyboard for rename. However, for the line in the file viewer, it might not be used for editing, but simply for viewing a long line, where the keyboard is inappropriate. That's what my proposal was focused on. There's three ways that could go:

• add TEXT to view the line in a message box, OK becomes the keyboard to edit it;
• add TEXT for the keyboard, OK remains as input for editing/viewing;
• change input itself so TEXT brings up the keyboard, like what happens with config strings.

[prl]

I still think that's overcomplicating it.

[sub3R]

I didn't see any mention in your post of having access to VirtualKeyBoard to edit the text. I though that having that ability was a key aspect of this topic, so I'm now not sure what you were suggesting. Both InputBox and VirtualKeyBoard can be used to edit text.

Perhaps my brief terminology is to blame. My mention of Keyboard means Virtual Keyboard (unless of course where I mention Logitech USB keyboard). I’ll use the name Virtual Keyboard in future.

So that I’m on the same page as everyone else, this is what I meant:

When I mentioned Keyboard this is an example of what I meant – the Virtual Keyboard. This, or its replacement, is what I requested for editing & renaming:

This is what I meant when I said ‘view the file contents’. This is called the Addon File-Viewer & is currently available by highlighting the file & pressing TEXT to display the file contents (OK doesn't work will all file types). I think this useful feature should be kept.

This is currently what pressing GREEN (Edit) in the Addon File-Viewer displays for editing a line in the file contents. (Is this called the InputBox?) I don’t have any use for this but my understanding is Geoff & adoxa do for viewing long lines, which is the reason why I didn’t want that removed. It would be good if this could be retained & access to the Virtual Keyboard for editing & renaming added.

[prl]

Yes, that's what I thought you meant.

It's a pity that IanSav's overwhelming preference for full-screen interactive screens extends to VirtualKeyBoard.

[sub3R]

It's a pity that IanSav's overwhelming preference for full-screen interactive screens extends to VirtualKeyBoard.

I remember quite a while ago Ian was trying to get someone with graphics skills to do some changes. I’m not sure which parts though.

While the keyboard button area is smaller on OverlayHD than either of the two default skins, the available text area for editing is better.

Out of the three I prefer OverlayHD’s Virtual Keyboard, but you probably knew I was going to say that.

Below is the easy-skin-au-hd for comparison. The Full-Metal-Jacket skin looks the same except for the font.

[prl]

While the keyboard button area is smaller on OverlayHD than either of the two default skins, the available text area for editing is better.

My skin for IanSav's updated VirtualKeyBoard uses a smaller font and a wider entry box than the current pre-loaded skins use:
viewtopic.php?f=54&t=14850&p=196404#p196366

[sub3R]

That’s a nice improvement.

[prl]

The extra width comes from a wider on-screen keyboard and having the button hint icons on the right-hand edge.

Having the button hint icons comes with IanSav's changes.

[sub3R]

Having the button hint icons comes with IanSav's changes.

That’s good. So that Virtual Keyboard will appear similar in the current version of OverlayHD?

[prl]

Having the button hint icons comes with IanSav's changes.

That’s good. So that Virtual Keyboard will appear similar in the current version of OverlayHD?

It depends on what you mean by "current". If you mean the current Beyonwiz version 1.70, then IanSav's new VirtualKeyBoard won't work, because the skin will be wrong, and so will the pixmaps that make up the keyboard area. It should work in the non-Beyonwiz 1.82E: for testing, I've put the 1.82E VirtualKeyBoard skin into the 1.70 skin, and this is how it looks:

[sub3R]

Yes, I meant the current Beyonwiz version 1.70.

I was aware that it wouldn’t work in that version but knowing you had been doing some testing I was interested in how it looks so far in version 1.70. Exactly what you have attached - thanks.

I think that looks quite good.

[prl]

I've submitted the VirtualKeyboard changes to the code repository. If they're accepted, I don't expect them to be made part of the next official release.

[sub3R]

Thanks for all your work getting to that stage.

[prl]

I've just realised that I've posted in the wrong topic. I suspect that anyone who's interested will see it here anyway