[Vm-dev] Re: [squeak-dev] shift-enclose broken in trunk...

[Guillermo Polito]

On Mon, Apr 9, 2012 at 11:13 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
>
>
> On Mon, Apr 9, 2012 at 2:07 PM, <juanlists at jvuletich.org> wrote:
>
>> Hi Eliot,
>>
>>
>> Quoting Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>  On Mon, Apr 9, 2012 at 4:04 AM, Bob Arning
>>> <arning315 at comcast.net> wrote:
>>>
>>>
>>> > It works in 4.2 Mac for me. In 4.3, it fails as you reported.
>>>
>>> So the change is then the discarding of shiftEncose: and its use in
>>> initializeShiftCmdKeyShortcuts**.  This change was made when the
>>> signature for enclose: et al was changed to take KeyboardEvents as
>>> arguments instead of the characterStream made in Morphic-nice.566. I
>>> agree with Nicholas' comment in Morphic-nice.566 that
>>> "#shiftEnclose: is hardcoding the keyboard layout, which is not
>>> compatible with foreign keyboards and modern VM, and prevents
>>> correct enclosing to work.".  Looks like there isn't enough
>>> information in a KeyboardEvent, e.g. the shifted and unshifted
>>> characters, for enclose: to do the right thing.  We need both the
>>> shifted and the unshifted character, and then enclose: can do the
>>> right thing.  But the VM does not pass up this information yet.   I
>>> propose we modify the VMs asap to use the "reserved1"
>>> 7th field in a sqKeyboardEvent to contain the modified character as
>>> answered by the OS. For and against?
>>>
>>
>> Yes, yes, yes! While doing this, please include in this new field the
>> character as if [ctrl] was _not_ pressed (even if it actually was pressed).
>> Please take a look at http://lists.squeakfoundation.**
>> org/pipermail/vm-dev/2012-**January/010042.html<http://lists.squeakfoundation.org/pipermail/vm-dev/2012-January/010042.html>, where I describe both issues. In that message I suggest doing this in the
>> existing field; but I agree that adding a new field for this behavior is a
>> much better solution.
>>
>
> Looking at the Mac OS Carbon support, specifically UCKeyTranslate, one can
> provide a keyboard code and a modifier bitmask (state of shift, control,
> meta and option keys) and obtain the Unicode character(s) this results in.
>  So to get the "logical key" the user typed, I *think* one
> supplies UCKeyTranslate with the key code and the state of the shift key,
> i.e. masks out control, option and meta.  See
> https://developer.apple.com/library/mac/#documentation/Carbon/reference/Unicode_Utilities_Ref/Reference/reference.html
> .
>
> Anyone who knows X11 and/or Win32 care to take a look and/or tell me how
> to do the equivalent there-on?  And of course the equivalent would need to
> be done for the iOS Mac VM.
>

I'm looking at the Unix Vm and I think it works nice.  The main problem we
have then is the KeyDecodeTable monster in InputEventSensor, that tries to
unify the three platforms, but it does not do it.

I'm getting the same input in a workspace than in a text editor...


>
>>
>> Cheers,
>> Juan Vuletich
>>
>>
>>
>>> > Cheers,
>>> > Bob >
>>> > On 4/8/12 3:46 PM, Eliot Miranda wrote: >
>>> > > Hi All, > >
>>> > >
>>> > >      in the current 4.3 trunk shift-enclose on Mac doesn't
>>> work,
>>> > it
>>> > > performs the unshifted enclose.  e.g.
>>> command-shift-single-quote
>>> > > (which is double quote) encloses with a single quote.  I think
>>> > this
>>> > > is an image issue.  It has been fine in my Qwaq/Teleplace image
>>> > for
>>> > > ages, but in testing I see it is broken in 4.2 also.  Anyone
>>> have
>>> > > any idea what's going on here?
>>> > > -- > > best, > > Eliot
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120409/6c80bef3/attachment-0001.htm