View Full Version : replacing the U.S. keyboard layout?

04-28-2007, 12:02 PM
i have just got a macbook, and it's my first mac machine. since i'm used to pc keyboards, i find the location of the tilde key (next to the left shift instead of under the escape key) very irritating, so i installed ukelele and created a custom variant of the U.S. keymap, with the tilde and the section keys swapped. all is good and the layout works like charm, except that i cannot disable the standard U.S. layout - obviously OS X requires that at least one of "U.S.", "U.S. Extended" or "Dvorak" layouts to be selected. if i needed only one layout, it wouldn't have been much of a problem, but since i also use the bulgarian layout, paying attention to skip the inconvenient standard U.S. layout is too much of a hassle. so my question is, does anybody know how can i get rid of the unneeded U.S. layout?

05-02-2007, 05:09 PM
I have a similar problem. I am Brazilian, and bought a Mac recently. However, Apple doesn't provide a proper Brazilian kb layout built into OS X (before someone points out there is a Brazilian layout in the International pref pane, it isn't a proper Brazilian layout). I got myself a custom-made layout, but OS X doesn't allow me to deselect the built-in Brazilian kb after selecting the custom one.

Any ideas?

05-02-2007, 06:32 PM
Just from poking around with what is available in the "International" pref pane, it appears that at least one of either the "Roman" or "Central European", or "Japanese" layouts has to be enabled. It appears that layouts whose "script" is Unicode, Cyrillic or Korean cannot be the sole layout . I don't know why this would be, but for example, I may have heard about unicode layouts not being available to older apps or something, in which case it might make sense why at least one non-unicode layout would be required...

While the "Brazillian" layout included with OS X is a part of the Roman set, is it possible that your custom layout is something else, like "Unicode"? I think Ukelele is a unicode layout editor...

To lanzz: Note that the "Select previous input source:" keyboard shortcut effectively serves to toggle between the two most recently used input methods. If these happened to be your custom U.S. and Bulgarian, you might be able to switch back and forth between them without ever encountering the default "U.S." layout.

05-03-2007, 03:16 AM
thanks, i already found the select previous source shortcut, but still having the unused layout there is irritating. and i don't believe your hypothesis about the roman script is correct, my custom U.S. layout is roman.

05-03-2007, 08:43 AM
I admit I've never used ukelele, but am just going on what has been written:
i installed ukelele and created a custom variant of the U.S. keymap

Ukelele is a Unicode Keyboard Layout Editor for Mac OS X versions 10.2 and later.

What is shown in the "script" column in the "Input Menu" tab in the "International" pref pane should indicate whether a given layout is "Roman" or "Unicode".

05-03-2007, 03:49 PM
The International Pane says my custom layout is Roman. Here's an image:


I wish Apple included a proper Brazilian layout built-into OS X:( ...

EDIT: btw, I'm not sure, but I think the custom layout was made using Ukelele.

05-03-2007, 04:23 PM
Ok, you've convinced me.

Another distinction is that the "Central European", Japanese" and "Roman" bundles are different from the xyz.keylayout files that Ukelele seems to edit (Japanese isn't Roman per se, but includes a Roman mode). That in itself can't be the only distinction since "Cyrillic" is also a bundle, but a member of that set can't be the sole active layout either, so maybe the requirement is a combination of being a bundle and using Roman script...

Are you able to run "ResEdit" (a "Classic" app)? I.e. if you have a PPC Mac or have an Intel Mac with one of the emulators to run pre-OS X Mac OS, ResEdit might let you edit one of the Roman Bundle layouts...

Edit: Do you have a link to the Brazillian layout, or can you upload it to this site? It might have to be zipped first... You've got me curious about what a "proper" Brazilian layout looks like.

05-03-2007, 05:03 PM
This is how a proper Brazilian kb layout should be like (it's called ABNT2):


Apple's "Brazilian" layout is actually a US International layout (which is useless for me).

I have uploaded my layout to this site:

Brasileiro ABNT2F Layout (http://rapidshare.com/files/29337355/BrasileiroABNT2F.keylayout.zip.html)

To install it, unzip it and copy it to ~\Library\Keyboard Layouts and log in again. You will now be able to select it from the International pane.

Thanks for your interest:)

EDIT: Most non-Brazilian keyboards don't have the 12th key of the bottom row (which does "/" and "?" in ABNT2).

05-04-2007, 06:13 AM
i don't see any connection between the script of the layout you have selected and the ability to disable the U.S. layout. selecting any cyrillic encoding (whether built-in or custom) does not permit disabling the U.S.; selecting unicode variants of latin-based layouts (U.S. extended, finnish extended, etc) allows disabling the U.S., while selecting greek, arabic and other non-lating unicode scripts does not allow disabling U.S.; the central european layouts also allow disabling the U.S. (these are all latin with various diacritics). even vietnamese allows disabling the U.S. (i guess that's since vietnamese is written with latin with diacritics too, and thus provides the whole latin character set too).

the only conclusion i can make is that the list of "approved" layouts is hard-coded somewhere, and you are required to have one of these hard-coded layouts enabled at any time. all keyboard layouts have a numeric ID, which is configurable in ukelele, and may be the required layouts are hard-coded by ID. the ukelele docs state that in case of a duplicate ID, OS X will automatically assign a different one, and obviously it is favoring the IDs of the built-in layouts and reassigns the IDs of the custom layouts.

all of this is obviously a mechanism to protect the user from shooting themselves in the foot by leaving their machine with no way to input latin characters, but unfortunately in this case prevents useful customizations.

05-04-2007, 09:11 AM
Yeah, I've given up on figuring out what determines that a given layout can be selected as the sole layout. As you say, the U.S. Extended is a unicode ".keylayout" type layout and it qualifies. It may not be ID either since IDs other than the ones present by default can also be used (although maybe the IDs I happened to try are unused but have been pre-approved). The name of the layout matters - changing the name of an accepted layout is enough for it to no longer be accepted, but creating a .keylayout with an acceptable name is not enough...

In terms of workarounds, using "ResEdit", I tried scratching together a keyboard resource based on the "BrasileiroABNT2F" layout, but since I don't have access to a Brazilian physical keyboard, I couldn't figure out where to put all the keys (eg. my North American keyboard only has 10 keys between the two shift keys), and I couldn't find some of the characters (eg. superscripted 1,2 and 3). The same would apply if I were to try a custom US - I don't have any keys between the "z" and the left shift so I don't know what changes to make.

But on my system, the custom layout can be selected as the sole layout so if you can get access to "Classic", it should be possible for you to create something similar that works on your keyboard.

I have attached what I have so far in case it helps. The keyboard resources are in the "Brasileiro.bundle/Contents/Resources/Roman.rsrc" file, but since "ResEdit" can only work on resource forks, it will have to be copied to the resource fork of a dummy file. I left a copy in the same folder (the file called "Current"). After editing with "ResEdit", copy the resource fork back to a resource file - eg. after backing up the existing Roman.rsrc file:cd ~/Library/Keyboard\ Layouts/Brasileiro.bundle/Contents/Resources
cp Current/..namedfork/rsrc Roman.rsrcIt might be necessary to clear out the "com.apple.IntlDataCache.kbdx.###" file belonging to the user, in the computer's main "/Library/Caches" folder, and logging out and back in before any changes take effect.

Edit: For the U.S. layout, it turns out there is an easier solution - just make a copy of the "/System/Library/Keyboard Layouts/Unicode.bundle", and edit the "USExtended.keylayout" file (it's XML so Ukelele should be able to handle it).

The un-needed layouts can be discarded, and place the whole bundle in "~/Library/Keyboard Layouts".

05-04-2007, 12:17 PM
i already tried to replace the USExtended.keylayout in /System/Library/Keyboard Layouts/Unicode.bundle, but even after a reboot, the layout i get when i select U.S. Extended is the standard one - i would guess the keylayout in /System/Library is not actually the location where the U.S. Extended is taken from.

05-04-2007, 12:36 PM
I don't know about replacing the real file, but editing a user copy is working here - all other layouts can be deselected and the edited layout is definitely in effect. The only hitch is that following a logout, the Canadian layout reenables itself for some reason, but that can be blocked by locking the user's com.apple.HIToolbox.[MACADDRESS].plist file.

Just a guess, but after editing the actual keylayout, you might have to delete the system's com.apple.IntlDataCache.kbdx file, but I don't want to mess with my system files to test that myself...

05-07-2007, 02:34 AM
doesn't work here. "US Extended" appears as a separate layout in international, and selecting it does not allow disabling the standard layouts. also it is obvious that the USExtended.keylayout in the Unicode.bundle is not the location of the in-effect U.S. Extended layout, as even the name in the USExtended.keylayout is different ("US Extended" vs "U.S. Extended" for the built-in layout).

05-07-2007, 07:27 AM
grep -a U.S /System/Library/Keyboard\ Layouts/Unicode.bundle/Contents/Resources/English.lproj/InfoPlist.strings
"US Extended" = "U.S. Extended";

05-07-2007, 09:41 AM
oh, sorry, still not very used to the internals of osx, did not occur to me the name was localized.

05-07-2007, 09:44 PM
From tinkering during the course of this thread, I get the impression that caching complicates efforts to see the effects of changes - I suspect that may be causing the confusion.

To try to avoid this, try creating a fresh account and log in to it.
Copy the entire "/System/Library/Keyboard Layouts/Unicode.bundle" to the Desktop in that account.
Edit the USExtended.keylayout" file in the copy of the bundle. Do not change the 'name="US Extended"' property in the third line.
Drag the whole Unicode.bundle (containing the modified file) into the new user's "~/Library/Keyboard Layouts" folder
Log out.
Log back in and try to select the customized layout.

If it works, try copying that bundle into the "Keyboard Layouts" folder of your usual account, and clear out the "/Library/Caches/com.apple.IntlDataCache.*.uid" files associated with the account. Log out and back in and try to select the custom layout.

If that works, then go ahead and clean up the bundle (all of those unmodified layouts will appear as duplicates in the pref pane).

By following all of these steps, I can reproducibly use the modified layout as the "required" layout and deselect other layouts. Note that I am editing the layout by hand in TextEdit - I still haven't used Ukelele so can't say if it does something else to the file that might interfere with the process.

05-08-2007, 07:08 AM
wonderful, clearing the cache worked great - there even was no need to log out, changes are seen instantly in the international prefs pane.

05-08-2007, 07:31 AM
just on a hunch, i copied /System/Library/Keyboard Layouts/Roman.bundle/ to my ~/Library/Keyboard Layouts/, then gutted it - removed the Roman.rsrc file from it, removed all non-U.S. descriptions in the Info.plist, removed even all translations (*.lproj), and put my custom roman (not unicode) U.S. layout in Roman.bundle/Contents/Resources; i changed the name of the layout (in the .keylayout file itself) to "U.S." (the name of the built-in US layout), and after clearing my cache, to my surprise, it turned out the international prefs pane now allows me to select it and disable the system US layout! obviously the things that are checked are the actual name of the layout (not just the ID - i haven't tested if the ID is checked at all) and some characteristics of the Roman.bundle - also haven't done much testing here, might be the actual name of the bundle, might be some of the nodes in its Info.plist file (CFBundleIdentifier = "com.apple.keyboardlayout.roman" perhaps?).