[squeak-dev] Incorrect keyboard mapping with Ctrl key in latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Dec 11 09:27:37 UTC 2019


Hi Christoph,
you might have to restart the image, or just evaluate:

    LanguageEnvironment clearDefault.
    HandMorph clearInterpreters.


Le mer. 11 déc. 2019 à 10:11, Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> a écrit :

> German umlauts (äöü) don't work for me either, despite I just installed
> all Trunk updates.
> <http://www.hpi.de/>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Thiede, Christoph
> *Gesendet:* Mittwoch, 11. Dezember 2019 09:22:26
> *An:* John Pfersich via Squeak-dev
> *Betreff:* Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in
> latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
>
>
> Hi Marcel!
>
>
> My preferences match your screenshot exactly, the problem resists.
>
>
> Concerning Alt F4 quit, I have to retract my statement. If I use the
> setting from your ini file, I get the right dialog.
>
> However, why is this setting not included into the VM release? Who wants
> to see this unsqueaky, OS-dependent window instead of a beautiful,
> explorable DialogWindow? :D
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> *Gesendet:* Mittwoch, 11. Dezember 2019 08:46:36
> *An:* John Pfersich via Squeak-dev
> *Betreff:* Re: [squeak-dev] Incorrect keyboard mapping with Ctrl key in
> latest Smalltalk VM release (Windows 1903 64bit, squeak.cog.spur)
>
> Hi Christoph,
>
> could you double check both .ini and preferences? [Ctrl] and [Alt] kind of
> work here on Windows 10 with a German keyboard layout as follows:
>
>
>
> Seems to be that only [alt], which is likely [cmd], is working. Without
> key duplication, [ctrl] does strange things. Even on my machine. Yes, those
> mappings in the image side are a mess.
>
> Best,
> Marcel
>
> Am 10.12.2019 20:28:11 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Dec 10, 2019 at 11:26 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>>
>> On Tue, Dec 10, 2019 at 10:31 AM tim Rowledge <tim at rowledge.org> wrote:
>>
>>>
>>>
>>> > On 2019-12-10, at 10:05 AM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>> >
>>> > Hi Christoph,
>>> > The image side is totally messy,
>>> > The VM side is also messy, so finding a combination that might work is
>>> a sport.
>>>
>>> You're not wrong. I had a bit of fun with this stuff making the
>>> Raspberry Pi Scratch system handle linux non-ascii type keyboard input. An
>>> interesting problem there was that enabling the linux extension completely
>>> broke something else (that I can't remember at all) and made the whole
>>> attempt moot.
>>>
>>>
>>> > To summarize: we have reached a point where we cannot change/add one
>>> feature without breaking one other (at least).
>>> > The consequence is that we have some sort of "stable" status because
>>> we cannot change anything (the statu quo).
>>>
>>> I suspect this is what happens to almost every complex project. I mean,
>>> look at how all the OS's get messed up and stall for years. They're all
>>> terrible right now.
>>>
>>> Supporting old images means keeping the old messy VM code around. Doing
>>> something new and clean means a lot of work and probably using new
>>> primitives or some variety of flag to request use of the new code. Then
>>> we'd want to decide on a time to drop the old mess.
>>>
>>
>> See can at least comment it and corral the old messy code in ifdef's such
>> as
>>
>> #if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
>> ...
>> #endif
>>
>> so that we don't have to think too hard about what we delete the next
>> time we have a major release that breaks image backward compatibility.  I
>> personally don't mind the old cruft being there.  What I hate is not
>> knowing what the cruft is.  The code, especially the C VM code, must be
>> properly documented so that it doesn't require intimate knowledge with
>> older versions, the history, but twiddling hacks, etc, etc.
>>
>
> I mean:
> We can at least comment it and corral the old messy code in ifdef's such as
>
> #if VERSION <= FOO
> # define SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP 1
> #endif
> ....
> #if SUPPORT_OLD_IMAGE_CHARACTER_MAPPING_CRAP
> ...
> #endif
>
> so that we don't have to think too hard about what we delete the next time
> we have a major release that breaks image backward compatibility.  I
> personally don't mind the old cruft being there.  What I hate is not
> knowing what the cruft is.  The code, especially the C VM code, must be
> properly documented so that it doesn't require intimate knowledge with
> older versions, the history, but twiddling hacks, etc, etc.
>
>>
>>> Lovely project! ;-)
>>>
>>> tim
>>> --
>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>> Strange OpCodes: DPC: Double Precision Crash
>>>
>>>
>>>
>>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191211/33174b28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 74879 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191211/33174b28/attachment-0001.png>


More information about the Squeak-dev mailing list