Are you talking about within the onscreen keyboard?

Maybe I don't quite follow, but doesn't the backspace key work this way in most computer interfaces (for example, in this textarea in your browser)?  It deletes the character to the left of the cursor and the cursor moves left.  The Delete key, on the other hand, deletes the character to the right of the cursor and the cursor stays in place.

So it seems to be correct to me.

Or are you talking about the 'Back' button in the upper left corner of the keyboard screen?

I was searching for a bug regarding that and found this one.  The Back button should take you back a screen, but instead it's doing a delete with a block cursor.

This is with the remote or a USB keyboard, as far as I can tell.

It's not clear to me what the issue is on this bug. Reassigning to Matt for clarification.

My intent was to keep the existing Controller behavior, which is:
delete key (play button on the controller/fab4 remote/touch interface) first deletes any characters to the right of the cursor, then deletes the characters to the left of the cursor.

I have confirmed that this is what I see on the fab4.

Sorry, allow me to clarify: this was using the touch, but was with much older firmware.

I'll re-test on current firmware to verify.

bump, matt can you try this today please.

tried on r5033

still behaves like delete. Normal expected behavior would be:

- Default cursor position for existing text input at END of the input so you can append text or backspace to remove text: current implementation positions cursor at beginning of text input
- Backspace should delete chars to the LEFT of cursor: current implementation deletes chars on the RIGHT of the cursor, then deletes anything on the LEFT only after deleting everything from the RIGHT.

Example: settings -> advanced -> player name

Tested w/ 7.4 r5033

again, this was using the on-screen keyboard via touch

(In reply to comment #7)
> tried on r5033
> 
> still behaves like delete. Normal expected behavior would be:
> 
> - Default cursor position for existing text input at END of the input so you
> can append text or backspace to remove text: current implementation positions
> cursor at beginning of text input


Dean brought this up with bug 11508.  The question to ask might be whether this should be the default behavior when editing _any_ existing string.  I think it's a good idea, but it should be consistent.  The only (small) problem I can see is that in all previous Squeezebox interfaces, the cursor was always positioned in column #1 whenever editing an existing string.


> - Backspace should delete chars to the LEFT of cursor: current implementation
> deletes chars on the RIGHT of the cursor, then deletes anything on the LEFT
> only after deleting everything from the RIGHT.
> 
> Example: settings -> advanced -> player name


I mentioned this in bug 11512.  It has to do with being in overstrike mode (block cursor).  In insert mode, the backspace key behaves correctly.

  >> But then the Backspace key behaves like a PC keyboard's Delete key
  >> and starts deleting the character _under_ the cursor. Backspace on
  >> a PC never does this - even in overstrike mode it always deletes
  >> the character to the _left_ of the cursor.

I strongly question whether the keyboard ever needs an overstrike mode to edit the very short text strings that it's used for.  I think it just adds confusion.  At the very least you should always enter an edit in the same mode - preferably insert.  Even an IP address edit - position the cursor at the far right, in insert mode.

Fixed the behaviour in r5087. The cursor rendering still needs to be addressed.

Fixed r5098.