Up, Down and Sideways

Richmond richmondmathewson at gmail.com
Sun Dec 15 11:51:20 EST 2013 

On 15/12/13 18:49, Roger Eller wrote:
> I'm looking out the window, and the sun is shining.  I am warm, so I might
> "believe" that I would also be warm outside.  That is, until I try it.  :)

Not having the money to buy an up-to-date Mac running 10.9 I will just 
have to stay indoors right now.

Richmond.

>
> ~Roger
> On Dec 15, 2013 11:42 AM, "Richmond" <richmondmathewson at gmail.com> wrote:
>
>> On 15/12/13 18:34, Roger Eller wrote:
>>
>>> Without promoting breaking Apple's EULA, I have to say that anytime you
>>> are
>>> emulating some other hardware, there will be differences.  Macs with
>>> Windows and Linux VMs inside seem to work better because more information
>>> is published for developers to allow it to.  Apple doesn't want there OS
>>> to
>>> run on foreign hardware.
>>>
>>> This isn't a setup to debate whether one should or should not.  The setup
>>> is to say that an OS running directly on the hardware is more likely to
>>> "more completely" act like the real McCoy.
>>>
>>> Have a look at how your physical hardware could in-theory be transformed.
>>> http://www.tonymacx86.com/search.php?googleSearch=Optiplex%20745
>>>
>>> Without another host sitting between the keyboard and the Mac, plus a
>>> generic virtual keyboard driver interpreting the keys, I believe rawkey
>>> signals would be more accurate.
>>>
>> I have a PPC macMini that runs 10.4.11 and have this hooked up in another
>> room for occasional use,
>> and have little or no reason to belive that the rawkey signals with that
>> machine will differ materially from an INTEL Mac running 10.9.
>>
>> Richmond.
>>
>>
>>> ~Roger
>>> On Dec 15, 2013 10:20 AM, "Richmond" <richmondmathewson at gmail.com> wrote:
>>>
>>>   On 15/12/13 16:44, Roger Eller wrote:
>>>>   I suspect that, since you begin your story with a "virtual" computer,
>>>>> that
>>>>> whatever real keys are being recognized on your host machine (the real
>>>>> one), will be all that the virtual one has access to.  Only a guess.
>>>>>
>>>>>   When one considers that virtualisation is a very important concept re
>>>> computing then developing
>>>> software within a virtualised machine is not quite as daft as it may
>>>> seem.
>>>>
>>>> If I connect a Mac keyboard to my virtualised Mac (obviously via the
>>>> physical
>>>> machine virtualisation is taken place within), or a PC keyboard, I get
>>>> the
>>>> same rawKeyDowns.
>>>>
>>>> I am currently working on Mac OS 10.6.7 virtualised on a DELL Optiplex
>>>> 745
>>>> running UbuntuStudio 13.10,
>>>> right next to a G3 iMac running Mac OS 9.2.2 (!!!); now, currently on
>>>> that
>>>> machine I am running RR/LC 2.0
>>>> and a stack that contains a single field "OOT", and a card script:
>>>>
>>>> on rawKeyDown RAWK
>>>>      put RAWK into fld "OOT"
>>>> end rawKeyDown
>>>>
>>>> with identical Mac keyboards connected to the two machines I am getting
>>>> the same rawKeyDown codes.
>>>>
>>>> The really funny thing is that with that stack on the underlying Linux
>>>> the
>>>> stack takes 4 times as long to respond with the rawKeyDown codes as does
>>>> the G3. As the G3 iMac has a 400MHz PPC processor with 384 MB RAM,
>>>> while the Linux box has a 2.7 MHz dual core INTEL processor with 6 GB RAM
>>>> that seems very odd indeed; unless, of course, LC 6.5.0 is suffering from
>>>> some sort of memory bloat compared with LC 2.0.
>>>>
>>>> In the virtualised environment (with 4.6 GB RAM apportioned to it) the
>>>> speed of the rawKeyDown codes
>>>> is almost exactly the same as the Linux box (unsurprisingly).
>>>>
>>>> Richmond.
>>>>
>>>>   ~Roger
>>>>> On Dec 15, 2013 5:43 AM, "Richmond" <richmondmathewson at gmail.com>
>>>>> wrote:
>>>>>
>>>>>    So, there I am progging on my Virtual Mac 10.6.7 and I try a script
>>>>> like
>>>>>
>>>>>> this:
>>>>>>
>>>>>> if shiftkey() is down and ctrlKey() is up then
>>>>>>          set the unicodeText of the selectedText to numToChar(MAGIC)
>>>>>>       end if
>>>>>>       if shiftkey() is up and ctrlKey() is down then
>>>>>>          set the unicodeText of the selectedText to numToChar(11744)
>>>>>>       end if
>>>>>>       if shiftkey() is up and ctrlKey() is up then
>>>>>>          set the unicodeText of the selectedText to numToChar(1073)
>>>>>>       end if
>>>>>>
>>>>>> and bu**er me (that's a technical term) if, when I'm pressing the
>>>>>> ctrlKey
>>>>>> if
>>>>>> the IDE doesn't pick that up and I end up with numToChar(1073) rather
>>>>>> than numToChar(11744) - Aha, the Documentation seems to be telling
>>>>>> big, fat porkies again:
>>>>>>
>>>>>> "Returns the state of the Control key." supposedly on Linux, Mac and
>>>>>> Win.
>>>>>>
>>>>>> So this leaves me in the Sh*t (another technical term) really, as,
>>>>>> unable
>>>>>> to leverage
>>>>>> the altKey as a modifier on Linux, the ctrlKey on Mac (at least), I
>>>>>> don't
>>>>>> seem to
>>>>>> have anything beyond the shiftKey and the capsLockKey (and that is a
>>>>>> problem because
>>>>>> of its stickiness) that are going to behave themselves cross-platform.
>>>>>>
>>>>>> Just set me up in the 'right' sort of mood for Sunday; stroppy,
>>>>>> petulant
>>>>>> and so forth.
>>>>>>
>>>>>> Richmond.
>>>>>>
>>>>>> P.S. 2 double cups of extra macho, highly sugared, black coffee; served
>>>>>> in
>>>>>> a cup that states
>>>>>> 'I heart coffee' on its outside.
>>>>>>
>>>>>> _______________________________________________
>>>>>> use-livecode mailing list
>>>>>> use-livecode at lists.runrev.com
>>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>>> subscription preferences:
>>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>>
>>>>>>    _______________________________________________
>>>>>>
>>>>> use-livecode mailing list
>>>>> use-livecode at lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>>
>>>>>
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>
>>>>   _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the use-livecode mailing list