Re: [Bug-XBoard] [bug #35000] Temporary previous position ('.' key, former Ctrl) conflicts with start of Type a move

[Arun Persaud]

Hi

>> I still have some bad feelings about this fix. It seems to me that using
>> a two-key stroke
>> or this funtion pretty much destroys its usefulness completely. I don't
>> see much of a reason
>> for its existence in the first place; highighting shows you pretty
>> learly what the last move was,
>> when you use arrow highlighting even more so than the traditional
>> square-boundary highlighting.
>> Perhaps it is a remnant of the monochrome era? I am not sure at all if
>> XBoard would still work
>> in monochrome...
> 
> I vote to keep the function. I find the arrow highlightning intrusive
> and disturbing, so that is IMHO not a good alternative. The temporary
> back-function have the big advantage that it is only active when you
> need it and ask for it by pressing the right key.

I also don't use the arrow highlighting for the same reason and think we
should keep this functionality, perhaps we should add it to Winboard if
it is missing there?
I guess the normal highlighting works, but having the piece move is nice
IMO:)

>> Anyway, if we want to keep this feature, I would be in favor of
>> continuing to use a plain .
>> rather than Ctrl+. , now that the auto-repeat problem is fixed
> 
> Indeed. It is better to have to press one key than two. Just make sure
> that the key will not do more than one thing.

I don't see a big problem with using two keys, especially a ctrl+<key>
for this function. You probably only use it a few times per game, say
when you where observing another game with long time control and want to
know the last move because you haven't been paying attention for a
while... if you play a game yourself you probably know the last move ;)
So hitting the ctrl key doesn't seem that problematic... We also have
almost all functions/menu items on ctrl+... keys, so why make an
exception for this one?

If we want to get rid of the key up/down behavior I would suggest to
move the piece to the last location wait a few ms and then automatically
move it back and don't wait for the key-up event.

>> Then we can drop this paying
>> attention to the Ctrl key
>> in the MoveTypeIn callback as well (normally this is automatic, but
>> there is no such ASCII character
>> as Ctrl+. !) It would be better to only pop up the move type-in only for
>> alphanumerics, not in the least
>> because that is what WinBoard does too.
> 
> If input notation can be localized at some point in the future, as I
> think it should, then the first character of a move will not necessary
> be a ASCII letter (A-Z) or number.

good point

Arun