Up, Down and Sideways
roger.e.eller at sealedair.com
Sun Dec 15 11:34:52 EST 2013
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.
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.
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
> 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).
>> 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
>>> 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
>>> 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.
>>> P.S. 2 double cups of extra macho, highly sugared, black coffee; served
>>> 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:
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode