Up, Down and Sideways

[Roger Eller]

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.  :)

~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
>