The reason may be ergonomic. We Germans use almost the same keyboard layout as US. The only obvious difference is that Y and Z are changed. For some weird reason they chose to keep the undo shortcut at ⌘Z instead of mapping it to the same key position (Y), rather than its letter. So every time someone wants to undo here, they have to reach to the middle of their keyboards.
Some countries may have just decided they want to keep key positions for ergonomical reasons.
Some countries may not even have X in their alphabet. There’s a multitude of reasons really. It’s just something programmers have to keep in mind. Time calculations are no fun either.
In AppleScript you’re right (as well as numeric calculations depending on the current locale).
But in Objective-C it’s very easy and reliable using the appropriate API
I know about the Z, having been forced to use German layout for odd reasons. A lot of stuff have been mapped due to its placement.
I think it is really all up to Apple to make a norm for their key-bindings for the individual countries, and programmers to adhere to them.
If you find date calculations in C/C++ difficult, then at least ICU can help you on your way if you aren’t lucky enough to program in Objective-C- I have come to loathe freeing pointers, and finding memory leaks in C!
Edit
There is actually this saa/cua standard (Systems Application Architecture/Common User Access) that was this great thing, that all operating systems was more or less to adhere to in the beginning of the Nineties.
This seems to have floated out a little, as for Apple Applications for instance, it seems to be, kind of voluntarily if you want to implement ctrl-F4 to cycle through windows for instance. (Personally I think all apps should acquiesce to this.) But I think there should be one such standard, that all User Interfaces should adhere to, as it would lead to a whole lot less confusion. Also when it comes to any national peculiarites.
They are a lot of « rules » defined for instance in « Mac OS X Human Interface Guidelines » which are violated by third party developer and alas by Apple developers too.
If you are curious like me, under 10.8.2, open the System Preference « Desktop and Energy Saver » and close it.
Open Disk Utility and select the Partition tab and quit the app.
After that, open the Console and search for the word « deprecated » and you will see how Apple apply its own rules.
So, why third party developers would apply them ?
As you are using AppleScript, you will also see deprecated calls which were already flagged in 10.7.
Sorry for digging this old thread out, but I’m just about to work on the release of Markdown for Keyboard Maestro 2. This used to work, but now I’m on Mavericks beta 3 and it doesn’t anymore. I tested this with a virtual Mountain Lion and it still works there. Does anyone know how to make this work again? Accessibility for AppleScript Editor and System Events need to be ticked on in the privacy settings.
Here’s the script, just in case.
tell application "System Events"
tell (first application process whose frontmost is true) -- Or a named, frontmost process.
set CutEnabled to (enabled of first menu item of menu 1 of menu bar item 4 of menu bar 1 whose value of attribute "AXMenuItemCmdChar" is "X" and value of attribute "AXMenuItemCmdModifiers" is 0)
end tell
end tell
I’m puzzled by Mavericks behavior.
I tested with Safari but it behave the same in other applications.
menu item 2 of menu 4 is cmd + shift + Z
its attribute “AXMenuItemCmdModifiers” is true (10.8.4 → 1)
menu item 4 of menu 4 is cmd + X
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)
menu item 5 of menu 4 is cmd + C
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)
menu item 6 of menu 4 is cmd + V
its attribute “AXMenuItemCmdModifiers” is false (10.8.4 → 0)
menu item 7 of menu 4 is cmd +option + shift + V
its attribute “AXMenuItemCmdModifiers” is true (10.8.4 → 3)
I don’t know if it’s a new feature or if it’s a bug.
Alas, since 2013/06/11 I am unable to enter the SEEDs area (Apple is aware of that) so I can’t report oddities.
I hope that somebody here will be able to file a report about this new behavior to get the truth about it.
Yvan KOENIG (VALLAURIS, France) samedi 20 juillet 2013 14:27:33
I’m back under 10.8.4. and added the vlues returned in this system.
As you may see, the new behavior is annoying because it’s not so precise than the old one.
Thanks, Yvan, very helpful. I did not know about the odd behavior you mention. I’m a bit farther though with my problem.
The script errors on this line:
tell application "System Events"
tell (first application process whose frontmost is true)
tell menu 1 of menu bar item 4 of menu bar 1
set cutEnabled to (first menu item whose value of attribute "AXMenuItemCmdChar" is "X")
-- Invalid index
end tell
end tell
end tell
Although the following:
tell application "System Events"
tell (first application process whose frontmost is true)
tell menu 1 of menu bar item 4 of menu bar 1
get properties of attribute "AXMenuItemCmdChar" of menu item 4
end tell
end tell
end tell
Some things are really bad.
I tested with TextEdit so I was able to run the script with nothing selected : menu item inactive
or with something selected : menu item active
(1) the whose filter is no longer usable. We must use something like that :
tell application "System Events"
set theProcess to (first application process whose frontmost is true)
set theProcess to process "TextEdit"
tell theProcess
tell menu 1 of menu bar item 4 of menu bar 1
#set cutEnabled to (properties of (get first menu item whose value of attribute "AXMenuItemCmdChar" is "X"))
-- Invalid index
set theValues to value of attribute "AXMenuItemCmdChar" of every menu item
set {maybe, cutenabled} to {0, false}
repeat with i from 1 to count theValues
if item i of theValues is "X" then
set maybe to i
exit repeat
end if
end repeat
if maybe = 0 then
# no item whose shortcut letter is X in the menu
else
# test the value of attribute "AXMenuItemCmdModifiers"
tell menu item maybe
properties of every attribute
set cutenabled to value of attribute "AXMenuItemCmdModifiers" is in {1, true}
end tell
end if
end tell
end tell
end tell
In both cases the properties of the attributes of menu item Cut were the same :
{
{value:“AXMenuItem”, class:attribute, settable:false, name:“AXRole”},
{value:“commande de menu”, class:attribute, settable:false, name:“AXRoleDescription”},
{value:menu “Édition” of menu bar item “Édition” of menu bar 1 of application process “TextEdit” of application “System Events”, class:attribute, settable:false, name:“AXParent”},
{value:false, class:attribute, settable:false, name:“AXEnabled”},
{value:{0, 54}, class:attribute, settable:false, name:“AXPosition”},
{value:{298, 19}, class:attribute, settable:false, name:“AXSize”},
{value:“Couper”, class:attribute, settable:false, name:“AXTitle”},
{value:missing value, class:attribute, settable:false, name:“AXHelp”},
{value:false, class:attribute, settable:true, name:“AXSelected”},
{value:“X”, class:attribute, settable:false, name:“AXMenuItemCmdChar”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemCmdVirtualKey”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemCmdGlyph”}, {value:false, class:attribute, settable:false, name:“AXMenuItemCmdModifiers”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemMarkChar”},
{value:missing value, class:attribute, settable:false, name:“AXMenuItemPrimaryUIElement”}}
For sure filing a bug report is needed but as I wrote I am unable to do that since 2013/06/11
Worse, as I wrote here about Mavericks, maybe Apple will ban me from SEEDs :roll eyes:
Yvan KOENIG (VALLAURIS, France) samedi 20 juillet 2013 15:56:59
Whose is down for the test upon the value of attribute “AXMenuItemCmdChar” only in Mavericks. It behaves flawlessly in Mountain Lion.
As I can’t file a report, I will not waste time switching between two systems.
I will continue to test new products only when Apple engineers will decide to wake up and restore my broken access.
whose seems to be usable for value of attribute “AXMenuItemCmdModifiers” but alas, it’s the value itself which is no longer meaningful. It’s set to false when the menu item is active and when it’s inactive.
KOENIG Yvan (VALLAURIS, France) samedi 20 juillet 2013 16:28:39
Gotcha. I have been unsuccessful getting this to work. The code always returns, no matter whether the Cut item is enabled or not. I can’t wrap my head around the code any longer at the moment. Will try again later. Thanks for all the help!
set theApp to "TextEdit"
activate application theApp
tell application "System Events"
#tell (first application process whose frontmost is true) -- Or a named, frontmost process.
tell process theApp
set CutEnabled to false
set maybe to first menu item of menu 1 of menu bar item 4 of menu bar 1 whose value of attribute "AXMenuItemCmdChar" is "X"
if value of attribute "AXMenuItemCmdModifiers" of maybe is in {0, false} then
set CutEnabled to enabled of maybe
end if
end tell
end tell
Don’t forget that if you run the script from the Script Editor, it’s the Editor which is at front.
In my late code, I failed to activate TextEdit before calling System Events.
Due to that the tested parameters were those of the Editor, not those of TextEdit.
KOENIG Yvan (VALLAURIS, France) samedi 20 juillet 2013 17:13:05
tell application "TextEdit" to activate
tell application "System Events"
tell (first application process whose frontmost is true)
set {AXMenuItemCmdCharVals, AXMenuItemCmdModifierVals, enabledVals} to {value of attribute "AXMenuItemCmdChar", value of attribute "AXMenuItemCmdModifiers", enabled} of every menu item of menu 1 of menu bar item 4 of menu bar 1
end tell
end tell
repeat with i from 1 to (count AXMenuItemCmdCharVals)
if ((item i of AXMenuItemCmdCharVals is "X") and (item i of AXMenuItemCmdModifierVals is in {0, false})) then
set cutenabled to item i of enabledVals
exit repeat
end if
end repeat
cutenabled
I just had to replace a test upon 0 to a test upon the list {0, false}.
Just for info, under pre Mavericks systems, I saw these values for the attribute “AXMenuItemCmdModifiers” :
0, 1, 2, 3, 8, 10, 24 and I’m sure that I missed some other ones.
Under Mavericks we get only true or false.
Yvan KOENIG (VALLAURIS, France) samedi 20 juillet 2013 21:47:37
Since my last message I discovered other numerical values for the attribute “AXMenuItemCmdModifiers”
The entire list is :
0 cmd +
1 cmd + maj +
2 cmd + option +
3 cmd + option + maj +
4 cmd + ctrl +
6 cmd + option + ctrl +
8
10
12 ctrl +
13 ctrl + maj +
24 fn fn
To identify menu items whose shortcut contains Escape, Delete, up arrow, down arrow, left arrow, right arrow it’s useful to extract also :
value of attribute “AXMenuItemCmdVirtualKey”
value of attribute “AXMenuItemCmdGlyph”
Here is a script which return the descriptions of menu items (1st level) of an application.
set theApp to "Safari"
activate application theApp
set params to {}
tell application "System Events" to tell process theApp to tell menu bar 1
set nbM to count menu bar items
repeat with i from 1 to nbM
tell menu 1 of menu bar item i
copy theApp & ", menu " & i & " ( " & name & " )" to end of params
repeat with j from 1 to count menu items
set maybe to {}
tell menu item j
copy name to end of maybe
try
copy value of attribute "AXMenuItemCmdChar" to end of maybe
on error
copy "" to end of maybe
end try
try
copy value of attribute "AXMenuItemCmdVirtualKey" to end of maybe
on error
copy "" to end of maybe
end try
try
copy value of attribute "AXMenuItemCmdGlyph" to end of maybe
on error
copy "" to end of maybe
end try
try
copy value of attribute "AXMenuItemCmdModifiers" to end of maybe
on error
copy "" to end of maybe
end try
end tell # menu item j
copy my recolle(maybe, tab) to end of params
end repeat
end tell # menu 1 of .
copy "" to end of params
end repeat
end tell # System Events .
set params to my recolle(params, return)
set nomDuRapport to (path to desktop as text) & theApp & (do shell script "date +_%Y%m%d_%H%M%S.txt")
my writeto(nomDuRapport, params, text, false)
#=====
on recolle(l, d)
local oTIDs, t
set {oTIDs, AppleScript's text item delimiters} to {AppleScript's text item delimiters, d}
set t to "" & l
set AppleScript's text item delimiters to oTIDs
return t
end recolle
#=====
(*
Handler borrowed to Regulus6633 - http://macscripter.net/viewtopic.php?id=36861
*)
on writeto(targetFile, theData, dataType, apendData)
-- targetFile is the path to the file you want to write
-- theData is the data you want in the file.
-- dataType is the data type of theData and it can be text, list, record etc.
-- apendData is true to append theData to the end of the current contents of the file or false to overwrite it
try
set targetFile to targetFile as text
set openFile to open for access file targetFile with write permission
if not apendData then set eof of openFile to 0
write theData to openFile starting at eof as dataType
close access openFile
return true
on error
try
close access file targetFile
end try
return false
end try
end writeto
#=====
As is, it apply to Safari.
KOENIG Yvan (VALLAURIS, France) mercredi 24 juillet 2013 12:39:43