Up, Down and Sideways

[Richmond]

I'm having the sort of fun I seem to have just about once a year:

mucking around with modifier keys . . . but, am trying to have even more
fun than last year like this:

on mouseUp
--1
if shiftKey() is up and altKey() is up then
put "shUP-altUP" into fld "CRAP"
end if
--2
if shiftKey() is down and altKey() is up then
put "shDN-altUP" into fld "CRAP"
end if
--3
if shiftKey() is up and altKey() is down then
put "shUP-altDN" into fld "CRAP"
end if
end mouseUp

and wondering, quite desperately in fact as quite as it rides on this,

why IF loop #3 doesn't work

if one exchanges '=' for 'is' it makes no difference.

the Documentation states that:

the altKey
altKey()

"Returns the state of the Alt key."

and that just doesn't seem to be happening [Linux].

Richmond.

[Richard Gaskin]

Post by Richmond
the altKey
altKey()
"Returns the state of the Alt key."
and that just doesn't seem to be happening [Linux].

Many Linux window managers are (unnecessarily, IMNSHO) greedy with the
Option/Alt key, using it to move windows and therefore not passing its
state to the app.

Yeah, annoying as all get out. I'd love to have a beer or twelve with
the Gnome folks who decided that was a smart thing to do. I imagine
that decision was made in a smoke house in Amsterdam, under the
influence of some exotic hash too powerful for reason to survive.

It may be possible to turn that off in the keybidings or CompizConfig or
whatever else may be relevant in your distro. But if you're making an
app for others to use it's probably best to just design around
dependency on the Alt/Option key altogether, since 80% of computer users
never change any defaults.

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys

[Richmond]

Post by Richard Gaskin

Post by Richmond
the altKey
altKey()
"Returns the state of the Alt key."
and that just doesn't seem to be happening [Linux].

Many Linux window managers are (unnecessarily, IMNSHO) greedy with the
Option/Alt key, using it to move windows and therefore not passing its
state to the app.
Yeah, annoying as all get out. I'd love to have a beer or twelve with
the Gnome folks who decided that was a smart thing to do. I imagine
that decision was made in a smoke house in Amsterdam, under the
influence of some exotic hash too powerful for reason to survive.

Umm . . . certainly seems that way.

I am currently working on a project for some Professors who are having a
problem with Old Church Slavonic
(come to think of things, Old Church Slavonic is fairly problematic in
its own right).

Anyhow . . . each letter of the OCS alphabet has to exist in 3 states:

Upper Case
Lower Case and
Combining

[if you have a problem understanding what 'combining' means; don't worry
- but it has nothing whatsoever
to do with Adge Cutler and the Wurzels:

].

Therefore I need to lever 2 modifier keys (in an ideal world, ha, ha,
those would be the SHIFT and ALT keys)
on Windows, Macintosh and Linux.

Richmond.

Post by Richard Gaskin
It may be possible to turn that off in the keybidings or CompizConfig
or whatever else may be relevant in your distro. But if you're making
an app for others to use it's probably best to just design around
dependency on the Alt/Option key altogether, since 80% of computer
users never change any defaults.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Dr. Hawkins]

Post by Richmond
I am currently working on a project for some Professors who are having a
problem with Old Church Slavonic
(come to think of things, Old Church Slavonic is fairly problematic in its
own right).

Nothing like the the problems there would be *without* Old Church Slavonic :)

[Richmond]

Post by Dr. Hawkins

Post by Richmond
I am currently working on a project for some Professors who are having a
problem with Old Church Slavonic
(come to think of things, Old Church Slavonic is fairly problematic in its
own right).

Nothing like the the problems there would be *without* Old Church Slavonic :)

Let's be rude, crude and direct:

Old Church Slavonic may have originated in 2 ways:

1. Derived from Bishop Ulfilas's Gothic alphabet.

2. Cooked up by a disciple of Cyril and Methodius.

Either way, this happened at the 'great schism' between the Western
Christian Church
and the Eastern Christian Church; and anybody, with a bit of thought,
can see that this was done
to divide the Catholics from the Orthodox still further.

Now, as a semi-Christian, I don't have a great deal of time for
Christian Church heirarchies,
but the nastinesses that subsequently took place as a result of that
split had got nothing to
do with anything Christianity's putative founder may or may not have
said. The Crusades saw
Catholic knights slaughtering 'heretic' Orthodox people who they
regarded as worse than Muslims.

Old Church Slavonic was largely used for writing down religious
documents of various sorts
designed (like a very large number of religious documents the world
over) to stop people
using the brains that God (?) had given them and follow, sheeplike, the
anti-life, anti-joy
aescetic stuff peddled by Paul of Tarsus and a load of shrivelled types
who sat on the tops of pillars.

As far as Old Church Slavonic is regarded as of linguistic interest, and
how from it came all the Eastern Slavic languages and their systems of
writing, that's OK; but when it comes for why the writing system was
designed (after Glagolitic turned out to be a complete turkey because it
took donkey's ages to write),
it probably caused more problems than it solved.

Here's a question I kept hearing in Israel in 1980: "Why did the early
Zionists" decide to use
the Aramaic alphabet to write modern Hebrew instead of a modified Latin one?

Here's another point: Mustapha Kemal knew very well what he was doing
when he made the Turks give up the Arabic alphabet for a modified alphabet.

And, further to that: Lenin knew what he was doing when he made all the
Turkic republics in the Soviet Union start using Latin writing systems,
just as Stalin knew what he was doing when he forced them to switch from
Latin to Cyrillic.

Notwithstanding that; history is irreversible, and loads of students and
academics make their bread and cheese with Old Church Slavonic (well,
there we are, it's doing some good at last) and need to type the blessed
language comparatively easily; and, here's Richmond falling foul of his
modifier keys.

I am tending towards using the CTRL key; but am still not completely
sure if a rawKeyUp trapped by Livecode
will stop another sort of command happening in Windows or Linux: for
instance, I don't want, when my end-user presses CTRL + P to get a
"combining П" and ends up making his/her printer do something.

Richmond.

P.S. Pinot Noir 2011.

[Jacques Hausser]

Post by Richmond
1. Derived from Bishop Ulfilas's Gothic alphabet.
2. Cooked up by a disciple of Cyril and Methodius.
Either way, this happened at the 'great schism' between the Western Christian Church
and the Eastern Christian Church; and anybody, with a bit of thought, can see that this was done
to divide the Catholics from the Orthodox still further.

The only alphabet inventor I’m really fond of is Sequoyah

Jacques

P.S. Grenache Syrah 2012

[Richmond]

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.

[Roger Eller]

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.

~Roger

Post by Richmond
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 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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

Post by Roger Eller
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.

Post by Roger Eller
~Roger

Post by Richmond
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 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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Roger Eller]

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.

~Roger

Post by Richmond

Post by Roger Eller
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
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.

Post by Roger Eller
~Roger
So, there I am progging on my Virtual Mac 10.6.7 and I try a script like

Post by Richmond
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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

Post by Roger Eller
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.

Post by Roger Eller
~Roger

Post by Richmond

Post by Roger Eller
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
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.

Post by Roger Eller
~Roger
So, there I am progging on my Virtual Mac 10.6.7 and I try a script like

Post by Richmond
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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[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

Post by Roger Eller
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.

Post by Roger Eller
~Roger

Post by Roger Eller
I suspect that, since you begin your story with a "virtual" computer,

Post by Roger Eller
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
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

Post by Roger Eller
So, there I am progging on my Virtual Mac 10.6.7 and I try a script like

Post by Richmond
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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

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

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

Richmond.

Post by Roger Eller
~Roger

Post by Roger Eller
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.

Post by Roger Eller
~Roger

Post by Roger Eller
I suspect that, since you begin your story with a "virtual" computer,

Post by Roger Eller
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
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

Post by Roger Eller
So, there I am progging on my Virtual Mac 10.6.7 and I try a script like

Post by Richmond
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
"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
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Roger Eller]

I think you missed my point that your Optiplex 745 theoretically could boot
directly into the same 10.6.7 version you are running layered on top of
Linux.

Post by Richmond

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

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

[Richmond]

Post by Roger Eller
I think you missed my point that your Optiplex 745 theoretically could boot
directly into the same 10.6.7 version you are running layered on top of
Linux.

Yes, I did miss your point; it being a bit cryptic.

However as I do most of my graphic work on the Linux side, as well as
use Fontforge for font development,
and run Windows XP and Windows 7 in virtual environments, and an Android
emulator, I need to have
Linux on the bare metal.

Richmond.

Post by Roger Eller

Post by Richmond

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

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

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Roger Eller]

If you have a spare USB hard-drive, or even a 16GB thumb-drive, you could
occasionally reboot the machine into OS X natively from USB. This would
prevent any need to modify (or accidentally hose) your current setup.

~Roger

Post by Richmond

Post by Roger Eller
I think you missed my point that your Optiplex 745 theoretically could boot
directly into the same 10.6.7 version you are running layered on top of
Linux.

Yes, I did miss your point; it being a bit cryptic.
However as I do most of my graphic work on the Linux side, as well as use
Fontforge for font development,
and run Windows XP and Windows 7 in virtual environments, and an Android
emulator, I need to have
Linux on the bare metal.
Richmond.

Post by Roger Eller

Post by Roger Eller
I'm looking out the window, and the sun is shining. I am warm, so I

Post by Roger Eller
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.
_______________________________________________

use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[J. Landman Gay]

Post by Roger Eller
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.

As a data point, this works correctly on my Mac, inside the 6.5.1 rc 1 IDE:

on rawkeyup pKey
if shiftkey() is down and ctrlKey() is up then
put "SHIFT"
end if
if shiftkey() is up and ctrlKey() is down then
PUT "CONTROL"
end if
if shiftkey() is up and ctrlKey() is up then
PUT "NONE"
end if
end rawkeyup

[J. Landman Gay]

Post by Richmond
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
"Returns the state of the Control key." supposedly on Linux, Mac and Win.

One more thing to consider: the Mac does not notify the app when the
control, command, option, or shift key goes down alone. They are
combined into a single keypress when an alpha-numeric character is
typed. You can't catch them alone.

So the docs don't really lie, but they do assume you are typing Control
along with another character.

[Richmond]

Post by J. Landman Gay

Post by Richmond
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
"Returns the state of the Control key." supposedly on Linux, Mac and Win.

One more thing to consider: the Mac does not notify the app when the
control, command, option, or shift key goes down alone. They are
combined into a single keypress when an alpha-numeric character is
typed. You can't catch them alone.
So the docs don't really lie, but they do assume you are typing
Control along with another character.

However, if I press CTRL + X, I get "x" just as if I didn't press CTRL
at all in this sort of script:

on rawKeyDown RK
if RK = 100 then
if ctrlKey() is down then
put "Q" after fld "TEXTBOCKS"
else
put "x" into fld "TEXTBOCKS"
end if
end rawKeyDown


Howeevr, the CMD/Apple/Windows key DOES work the way I want, so that is
what I am now using.

Richmond.

[Dr. Hawkins]

and wrong :)

Post by Richmond
1. Derived from Bishop Ulfilas's Gothic alphabet.
2. Cooked up by a disciple of Cyril and Methodius.
Either way, this happened at the 'great schism' between the Western
Christian Church
and the Eastern Christian Church; and anybody, with a bit of thought, can
see that this was done
to divide the Catholics from the Orthodox still further.

Except C&M were nearly 200 years before the Schism . . . and, for that
matter, after having been sent from Constantinople, they were called
upon the carpet in Rome--at which point Pope Nicholas ordained
Methodius, told his own archbishop in the dispute to back off, and
sent C&M back . . .

Post by Richmond
P.S. Pinot Noir 2011.

But that won't be very Noir any more, will it?

:)

[Richmond]

Post by Dr. Hawkins
and wrong :)

Post by Richmond
1. Derived from Bishop Ulfilas's Gothic alphabet.
2. Cooked up by a disciple of Cyril and Methodius.
Either way, this happened at the 'great schism' between the Western
Christian Church
and the Eastern Christian Church; and anybody, with a bit of thought, can
see that this was done
to divide the Catholics from the Orthodox still further.

Except C&M were nearly 200 years before the Schism . . . and, for that
matter, after having been sent from Constantinople, they were called
upon the carpet in Rome--at which point Pope Nicholas ordained
Methodius, told his own archbishop in the dispute to back off, and
sent C&M back . . .

Post by Richmond
P.S. Pinot Noir 2011.

But that won't be very Noir any more, will it?

Wait a minute: I am writing about the Cyrillic alphabet; NOT Glagolitic.

Glagolitic was cooked up by C&M, Cyrillic (despite being named after
Cyril) was not, and there
is a lot of argy-bargy about who cooked it up.

If you take a look at the map of Europe you will see that Orthodox
Slavic countries use variants of the Cyrillic alphabet, and Catholic
Slavic countries use variants of the Latin alphabet.

Still Noir, and still gurgling around in the pipes :)

Richmond.

Post by Dr. Hawkins
:)

[Dr. Hawkins]

Post by Richmond

Post by Dr. Hawkins
Except C&M were nearly 200 years before the Schism . . . and, for that
matter, after having been sent from Constantinople, they were called
upon the carpet in Rome--at which point Pope Nicholas ordained
Methodius, told his own archbishop in the dispute to back off, and
sent C&M back . . .

Wait a minute: I am writing about the Cyrillic alphabet; NOT Glagolitic.

Oh, I though you meant the language itself.

Post by Richmond
Glagolitic was cooked up by C&M, Cyrillic (despite being named after Cyril)
was not, and there
is a lot of argy-bargy about who cooked it up.
If you take a look at the map of Europe you will see that Orthodox Slavic
countries use variants of the Cyrillic alphabet, and Catholic Slavic
countries use variants of the Latin alphabet.

*shrug* Moscow has always fancied itself to be the "Third Rome."

Post by Richmond

Post by Dr. Hawkins

Post by Richmond
P.S. Pinot Noir 2011.

But that won't be very Noir any more, will it?

Still Noir, and still gurgling around in the pipes :)

Mmm. Gurgling wine.

I need to make beer again soon . . .

[Richmond]

Obviously the Documentation needs to be changed:

currently it states that altKey WILL detect the state of the Alt Key in
Linux.

Richmond.

[Richard Gaskin]

Post by Richmond
currently it states that altKey WILL detect the state of the Alt Key in
Linux.

It does. It's Gnome (IIRC), rather than Linux, that traps the Alt key,
and not even all Gnome-based distros do, nor all configs. It depends on
the key bindings in place, which can potentially override any key. Or
none at all.

You're welcome to add a note in the User Comments section of that
Dictionary entry.

And of course if you feel strongly about it you can file a request to
have that elevated into the Dictionary proper, though to do that I'd
suggest finding an authoritative source outlining the specific use-cases
where it may apply.

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys

[Richmond]

Post by Richard Gaskin

Post by Richmond
currently it states that altKey WILL detect the state of the Alt Key in
Linux.

It does. It's Gnome (IIRC), rather than Linux, that traps the Alt
key, and not even all Gnome-based distros do, nor all configs. It
depends on the key bindings in place, which can potentially override
any key. Or none at all.

Funny (the remark about GNOME); I'm having this problem on UbuntuStudio
13.10 which uses XFCE, not GNOME.

Post by Richard Gaskin
You're welcome to add a note in the User Comments section of that
Dictionary entry.
And of course if you feel strongly about it you can file a request to
have that elevated into the Dictionary proper, though to do that I'd
suggest finding an authoritative source outlining the specific
use-cases where it may apply.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richard Gaskin]

Post by Richmond

Post by Richard Gaskin

Post by Richmond
currently it states that altKey WILL detect the state of the Alt Key in
Linux.

It does. It's Gnome (IIRC), rather than Linux, that traps the Alt
key, and not even all Gnome-based distros do, nor all configs. It
depends on the key bindings in place, which can potentially override
any key. Or none at all.

Funny (the remark about GNOME); I'm having this problem on UbuntuStudio
13.10 which uses XFCE, not GNOME.

And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys. But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys

[Warren Samples]

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys. But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I can
grab and move the LiveCode tools palette is using alt. It may not be on
by default in all distros. I can turn it on and off as well as change
the modifier key. I have seen references in forum posts which indicated
that at least some KDE users who had never used these shortcuts had to
turn them on.

When I change the modifier key for window resizing and moving to "Meta"
(option), Richmond's script runs as expected. LiveCode works as stated,
so long as the OS isn't hijacking the signal for its own purposes
further up the hierarchy.

Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.

Warren

[Richmond]

Post by Warren Samples

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys. But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I
can grab and move the LiveCode tools palette is using alt. It may not
be on by default in all distros. I can turn it on and off as well as
change the modifier key. I have seen references in forum posts which
indicated that at least some KDE users who had never used these
shortcuts had to turn them on.
When I change the modifier key for window resizing and moving to
"Meta" (option), Richmond's script runs as expected. LiveCode works as
stated, so long as the OS isn't hijacking the signal for its own
purposes further up the hierarchy.
Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.
Warren

That's a good point, but the problem I have is that I am putting a
program together for use by Professors of Old Church Slavonic who have
computers running Mac, Win and Linux and know nothing at all about how
to muck about the mod. keys on their machines.

Therefore my standalone should "just work" when it ends up on some
Prof's machine, regardless of
what system s/he is running. AND, the mod. keys used should be the same
ones regardless of OS as well.

Richmond.

[Martin Baxter]

Post by Richmond

Post by Warren Samples

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys. But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I
can grab and move the LiveCode tools palette is using alt. It may not
be on by default in all distros. I can turn it on and off as well as
change the modifier key. I have seen references in forum posts which
indicated that at least some KDE users who had never used these
shortcuts had to turn them on.
When I change the modifier key for window resizing and moving to
"Meta" (option), Richmond's script runs as expected. LiveCode works as
stated, so long as the OS isn't hijacking the signal for its own
purposes further up the hierarchy.
Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.
Warren

That's a good point, but the problem I have is that I am putting a
program together for use by Professors of Old Church Slavonic who have
computers running Mac, Win and Linux and know nothing at all about how
to muck about the mod. keys on their machines.
Therefore my standalone should "just work" when it ends up on some
Prof's machine, regardless of
what system s/he is running. AND, the mod. keys used should be the same
ones regardless of OS as well.
Richmond.

On my (elderly) Ubuntu, variant/high bit characters are typed using
combinations of:

Alt Gr
shift

Rather than alt + shift. And that is the stock configuration. You might
perhaps be able to use the keysdown to detect these, but the returned
keycodes may vary across systems I guess.

Easier for left-handers anyway.

Might be nice for linux users if livecode could detect the state of Alt
Gr key.

On my Ubuntu, the keysdown gives me:

R Shift 65506
L Shift 65505
Alt [nothing]
Alt Gr 65027
L Shift + Alt 65505,65511
R Shift + Alt Gr 65506,65312

I don't know if this helps you at all, but it seemed worth mentioning.

I would expect that alt + shift should work for windows and mac though,
so this issue is presumably Linux specific.

Martin

[Richmond]

Post by Martin Baxter

Post by Richmond

Post by Warren Samples

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys. But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I
can grab and move the LiveCode tools palette is using alt. It may not
be on by default in all distros. I can turn it on and off as well as
change the modifier key. I have seen references in forum posts which
indicated that at least some KDE users who had never used these
shortcuts had to turn them on.
When I change the modifier key for window resizing and moving to
"Meta" (option), Richmond's script runs as expected. LiveCode works as
stated, so long as the OS isn't hijacking the signal for its own
purposes further up the hierarchy.
Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.
Warren

That's a good point, but the problem I have is that I am putting a
program together for use by Professors of Old Church Slavonic who have
computers running Mac, Win and Linux and know nothing at all about how
to muck about the mod. keys on their machines.
Therefore my standalone should "just work" when it ends up on some
Prof's machine, regardless of
what system s/he is running. AND, the mod. keys used should be the same
ones regardless of OS as well.
Richmond.

On my (elderly) Ubuntu, variant/high bit characters are typed using
Alt Gr
shift
Rather than alt + shift. And that is the stock configuration. You might
perhaps be able to use the keysdown to detect these, but the returned
keycodes may vary across systems I guess.
Easier for left-handers anyway.
Might be nice for linux users if livecode could detect the state of Alt
Gr key.
R Shift 65506
L Shift 65505
Alt [nothing]
Alt Gr 65027
L Shift + Alt 65505,65511
R Shift + Alt Gr 65506,65312
I don't know if this helps you at all, but it seemed worth mentioning.
I would expect that alt + shift should work for windows and mac though,
so this issue is presumably Linux specific.
Martin

That seems a helpful idea.

However, I'm not sure what you mean by 'Alt Gr'.

Richmond.

[Martin Baxter]

Post by Richmond

Post by Martin Baxter

Post by Richmond

Post by Warren Samples

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys.
But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I
can grab and move the LiveCode tools palette is using alt. It may not
be on by default in all distros. I can turn it on and off as well as
change the modifier key. I have seen references in forum posts which
indicated that at least some KDE users who had never used these
shortcuts had to turn them on.
When I change the modifier key for window resizing and moving to
"Meta" (option), Richmond's script runs as expected. LiveCode works as
stated, so long as the OS isn't hijacking the signal for its own
purposes further up the hierarchy.
Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.
Warren

That's a good point, but the problem I have is that I am putting a
program together for use by Professors of Old Church Slavonic who have
computers running Mac, Win and Linux and know nothing at all about how
to muck about the mod. keys on their machines.
Therefore my standalone should "just work" when it ends up on some
Prof's machine, regardless of
what system s/he is running. AND, the mod. keys used should be the same
ones regardless of OS as well.
Richmond.

On my (elderly) Ubuntu, variant/high bit characters are typed using
Alt Gr
shift
Rather than alt + shift. And that is the stock configuration. You might
perhaps be able to use the keysdown to detect these, but the returned
keycodes may vary across systems I guess.
Easier for left-handers anyway.
Might be nice for linux users if livecode could detect the state of Alt
Gr key.
R Shift 65506
L Shift 65505
Alt [nothing]
Alt Gr 65027
L Shift + Alt 65505,65511
R Shift + Alt Gr 65506,65312
I don't know if this helps you at all, but it seemed worth mentioning.
I would expect that alt + shift should work for windows and mac though,
so this issue is presumably Linux specific.
Martin

That seems a helpful idea.
However, I'm not sure what you mean by 'Alt Gr'.
Richmond.

The "other Alt key". It's found to the right of the space bar usually I
believe. That's where it is on my MS keyboards anyway. Possibly some
keyboards don't support it.

I suspect it may be what livecode calls the extend key?

Anyway.

Martin

[Richmond]

Post by Martin Baxter

Post by Richmond

Post by Martin Baxter

Post by Richmond

Post by Warren Samples

Post by Richard Gaskin
And that's why we need an authoritative source. I've never looked into
it deeply enough to find which component is handling the Alt keys.
But
if it's not Gnome, it may be something lower (though almost certainly
not the kernel), or something higher (possible Ubuntu's keybindings
interface, which I had thought were inherited from Gnome, but may be
part of what they get from Debian).

These seem to be common shortcuts under Linux. I use them under KDE. I
like alt+drag to resize in particular, and note that the only way I
can grab and move the LiveCode tools palette is using alt. It may not
be on by default in all distros. I can turn it on and off as well as
change the modifier key. I have seen references in forum posts which
indicated that at least some KDE users who had never used these
shortcuts had to turn them on.
When I change the modifier key for window resizing and moving to
"Meta" (option), Richmond's script runs as expected. LiveCode works as
stated, so long as the OS isn't hijacking the signal for its own
purposes further up the hierarchy.
Conflicts in creating shortcuts are always a possibility and require a
little caution, and it's good to make people aware of the high
probability that "alt+mouseX" will be unavailable to LiveCode under
Linux, but I think it's not quite right to suggest it's broken.
Warren

That's a good point, but the problem I have is that I am putting a
program together for use by Professors of Old Church Slavonic who have
computers running Mac, Win and Linux and know nothing at all about how
to muck about the mod. keys on their machines.
Therefore my standalone should "just work" when it ends up on some
Prof's machine, regardless of
what system s/he is running. AND, the mod. keys used should be the same
ones regardless of OS as well.
Richmond.

On my (elderly) Ubuntu, variant/high bit characters are typed using
Alt Gr
shift
Rather than alt + shift. And that is the stock configuration. You might
perhaps be able to use the keysdown to detect these, but the returned
keycodes may vary across systems I guess.
Easier for left-handers anyway.
Might be nice for linux users if livecode could detect the state of Alt
Gr key.
R Shift 65506
L Shift 65505
Alt [nothing]
Alt Gr 65027
L Shift + Alt 65505,65511
R Shift + Alt Gr 65506,65312
I don't know if this helps you at all, but it seemed worth mentioning.
I would expect that alt + shift should work for windows and mac though,
so this issue is presumably Linux specific.
Martin

That seems a helpful idea.
However, I'm not sure what you mean by 'Alt Gr'.
Richmond.

The "other Alt key". It's found to the right of the space bar usually I
believe. That's where it is on my MS keyboards anyway. Possibly some
keyboards don't support it.

Aha, got it.

Well, on the old Mac keyboard I have connected to a Linux box here at my
school (lunch break), there's 2 ALT buttons,
and on all the other ones I have except for the KEYNEEDS learner
keyboards I have here for the 7-12 year old
crowd.

Mind you, typing with a mod key on the right, rather than the left, is a
bit awkward, specially
for right-handed folk.

Most programs use mod keys on the left-hand side of the keyboard, and
using the Alt Gr key may be
a bit counter-intuitive.

I thought about using the Caps-lock key, but then realised that with its
locking mechanism that
wouldn't really do.

Richmond.

Post by Martin Baxter
I suspect it may be what livecode calls the extend key?
Anyway.
Martin
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

R Shift 65506
L Shift 65505
Alt [nothing]
Alt Gr 65027
L Shift + Alt 65505,65511
R Shift + Alt Gr 65506,65312
I don't know if this helps you at all, but it seemed worth mentioning.
I would expect that alt + shift should work for windows and mac
though, so this issue is presumably Linux specific. Martin

And just to show you what a minefield this is, here are my keyDowns on
Ubuntu 12.04 GNOME 'Classic' with an Apple keyboard:

Left SHIFT 65505
Right SHIFT 65506
Left CTRL 65507
Right CTRL 65508
Left ALT 65513
Right ALT 65027
Left CMD 65515 Apple Key
Right CMD 65516

different to yours.

Bl**dy unhelpful I'm afraid.

Richmond.

[Martin Baxter]

Post by Richmond

On my Ubuntu, the keysdown gives me: R Shift 65506 L Shift 65505 Alt
[nothing] Alt Gr 65027 L Shift + Alt 65505,65511 R Shift + Alt Gr
65506,65312 I don't know if this helps you at all, but it seemed worth
mentioning. I would expect that alt + shift should work for windows
and mac though, so this issue is presumably Linux specific. Martin

And just to show you what a minefield this is, here are my keyDowns on
Left SHIFT 65505
Right SHIFT 65506
Left CTRL 65507
Right CTRL 65508
Left ALT 65513
Right ALT 65027
Left CMD 65515 Apple Key
Right CMD 65516
different to yours.
Bl**dy unhelpful I'm afraid.
Richmond.

Not *very* different ;)

Left SHIFT 65505
Right SHIFT 65506
Left CTRL 65507
Right CTRL 65508
Left ALT [nothing] (presumably because Gnome eats it first)
Right ALT 65027
Left CMD 65515 (windows key)
Right CMD 65312 (right windows key)

It differs in that I get no code for left Alt, and the right command key
gives a different code - BUT, note that I have reassigned the right
windows (CMD) key as the "compose" key for my system. (used for typing
characters with diacriticals and various other stuff).

I agree AltGr is awkward for a right-hander, however I think it must be
fairly standard use for this sort of purpose, so for you to use it so
would not be eccentric.

Note that in my testing AltGR alone produces 65027, but ALtGr + R Shift
yields 65506,65312. 65312 being the same code as my compose key the
right windows key or right CMD key

You may like to see:

https://en.wikipedia.org/wiki/AltGr_key

Martin

[Richmond]

Well, Linux seems to have no problem with ctrlKey, so I am wondering
about going for SHIFT and CTRL as
my modifier keys . . .

. . . However, I am well aware that on both Linux and Windows CTRL +
some other key (e.g. CTRL + V) does something;
what I am not sure is that if I am running these things inside a keyUp
statement, such as this one:

on rawkeyUp RUP
switch
case RUP= whatever the flipping rawkey number is for 'C'
if ctrlKey() is down then
do something jazzy
else
do something else jazzy
end if
break
end switch
end rawkeyUp

the SWITCH condition will over-ride what the OS would normally do with
CTRL + C (copy something).

Richmond.