OSX: ALT stolen by shortcuts, cannot type special characters

unfortunately, this is a global OSX/X11 problem. The alt key
on a mac keyboard is normally set by SHIFT+option (because
the alt is on the top of the key) but this does not work
under X11. I have not found a workaround though medling with
the keymaps in X11 should help to solve the problem.

Is there no way to map (or hardcode into Inskcape) the ctrl
key to the apple one and the alt key to ctrl ?
It would be more mac friendly...

The program xev says that the ctrl key is mapped to
Control_L, the option key is mapped to Mode_switch and the
apple one to Meta_L... Just a thought...

another possibility is to help with the native port of gtk
to the mac...

Strange. I can't make this not work! I don't know what
settings I have different to you guys but the option key
works fine for me as ALT on both machines I have tried (iMac
and Powerbook running 10.4.4).

Under keyboard settings my modifier for the option key is
unchanged. All three options are selected under the X11
Input preferences. I've never hacked any of the keymaps.

I didn't even know this was a problem for anyone!

What machines/OS versions are people on?

And gpiroux, xev says the same thing for me.

ok, it is due to a bug with X11 on Tiger.

The OOo2.0 folk had found a workaround so that If I start
X11 from the OOo2.0 docklet, an option is passed to X11 to
enable the special characters like "\", "|" (respectively
Alt+Shift+/ and Alt+Shift+l) on non qwerty keyboard. And
then, the problem occurs with Inkscape.

And If I close X11 and start Inskape, there is no problem
with Inkscape but it is not possible to enter character like
"\", "|"... as well in Inkscape as in OOo2.0.

This means that I cannot use at the same time OOo2.0 and
Inkscape...

gpiroux

OK the same for me here: alt works when X11 is not started by open
office.
from what I've read before there is a problem with the keymap used by X11

for non qwerty mac keyboards (in particular french keyboards). I ran into
this
problem with ubuntu where I could not type any special characters (such as
\
or | as pointed before). I had to modify the keymap according to some
comments on the forums:
http://ubuntuforums.org/showthread.php?t=9127
https://bugzilla.ubuntu.com/show_bug.cgi?id=5989#c15
en francais:
http://www.linux-france.org/macintosh/clavier_v4.html
http://www.linux-france.org/macintosh/clavier_gentoo.html

maybe this would work with OS X too. but I'm afraid I won't have time to
test
before a while.

I am not quite sure what is being asked for.

Is it the case that using the 'Opt' key under X11 does not
work in the way that the 'Alt' key does on other platforms?

If so, is this X11's bug? or Apple's bug?

If so, do we need a workaround?

Is it being asserted that there is such a workaround in Open
Office, and if so, should the same be applied to Inkscape.

Personally, I would prefer a less fragile solution.

Using a packaged Inkscape compiled by me in February on
Panther and running on Panther today, I double click the
Inkscape icon - Apple's X11 and the fink Gnome startup and
Inkscape starts.

QWERTY keyboard, EN-gb system.

I can confirm the bug - Opt-D switches to the Dropper tool,
and does not clone the selected object. In fact the Opt key
seems to do nothing at all!

It is possible that X11/Inkscape regards the Cmd key as the
actual Alt key, as holding down the Cmd key toggles the 'Alt
key' status bar message, but does not enable actions such as
Alt-D = Clone.

These findings don't seem to be influenced either way by the
X11 preference for using the Opt-click and Cmd-Click as
middle and right click respectively.

If the 'Cmd key shows status bar Alt annunciator, but Cmd-D
does not Clone' behaviour is still in, then this is almost
certainly a bug.

Running OS X 10.4.6 (Tiger) and Apple's X11 1.1 - Xfree86 4.4.0 I see a
few
problems.
I have "Enable keyboard shortcuts under X11" turned off. (This is
annotated
with "If you select this option, using keyboard shortcuts for menu
commands
may interfere with X11 applications that use the Meta modifier")

For me, the Apple/Command key is mapped to be Meta (defaults, no
tweaking on my part). If I hold Apple, I get the "Alt" message in the
status bar,
but niether Apple-click, alt-click nor option-click gets me select under
(with
alt-click being shift-option-click actually).

Apple-d switches to the eyedropper tool

option-d creates a clone

shift-option-d unlinks a clone.

So it appears to me that there's probably some confusion in the code from

the Meta key getting mapped to Alt on Linux, and things not properly
taking
into account that those might not be the same on other keyboards. With it

showing up in later versions of OS X, there's a better likelyhood that
it's OS X
getting more precise with it's behavior.

Jon,

Some of these things (such as select-under issues) are
probly due to the following. (posted previous on
inkscape-devel.

The following is true for my Mac, with no xmodmap changes:

Apple keysyms are GDK_Meta_L and GDK_Meta_R
Apple key modifier is GDK_MOD2_MASK

Alt/Option keysym is GDK_Mode_switch
Alt/Option modifier is GDK_MOD1_MASK

I point out the behaviour of Alt since the Alt/Option key on
Macs does not return GDK_Alt_{L,R} as might be expected.
Though it does return the same modifier as on Linux. This
means Alt works in the places in Inkscape that check with
modifiers but not places where the key press itself is checked.

Originator: NO

A test on latest SVN with OS X 10.4.9 reveals that ALT is working as
expected for all the shortcuts it is mapped to (clone, unlink clone, menu
shortcuts, etc. all work). There is no interference with the APPLE key now,
no matter if "Enable keyboard shortcuts under X11" is checked or not in X11
preferences.
The problem remaining is that many special characters are typed by
pressing a character key+ALT. For example on a US keyboard, ALT+a is œ,
ALT+s is ß etc. On French keyboard this is even more of a problem because
many useful special characters surch as \ or | are mapped to some SHIFT+ALT
combinations. All those characters cannot be typed in the Text tool because
ALT is stolen for keyboard shortcuts (ALT+D clones instead of typing ð for
example). This occurs bothnon canvas and in the Text tab of the Text and
Font dialog.

Is this still an OS X specific problem? It looks that this probably occurs
on all systems.

What can be done? Could ALT be supressed as a modifier when using the text
tool? This will probably break things a bit (i.e. one will not be able to
clone a text without switching to the selector tool). Could ALT be anabled
as a way to type special characters in the Text tab of the Text and Font
dialog at least?

Release 0.46 nor latest svn (20898) still does not work in my OSX Tiger nor Leopard English USA setups. I have tried the xmodmap tricks which work if you run xmodmap after starting X11.app but does not work with the Inkscape.app launching X11.app.

In testing, the pressing of Alt does indeed result in GDK_Alt_L and GDK_Alt_R key press events, but then subsequent keys do not get their rightful GDK_MOD1_MASK bit set. (Even more perverse, the mouse motion and mouse button press messages DO get the right GDK_MOD1_MASK bit set.)

Someone else added an undocumented preference (post-0.46) called "options/mapalt/value" that tries to adjust the alt key mapping, but even this does not solve the problem. I think this was intended to allow the Command key to act as an Alt key.

I have made a private patch to the main.cpp snooper() routine which supports a different undocumented preference called "options/trackalt/value" that tries to monitor the pressing and releasing of the Alt key itself, and then asserting the GDK_MOD1_MASK bit into any subsequent keyboard input. This seems to work for me (Alt+F pops file menu, Alt+B makes bitmap copies, Alt+D clones, all kerning works, etc.), but I think it needs a lot more testing with other OSX and Linux users, especially non-English users, before I go too much farther with committing it.

(As for JiHO's astute observation that you can't type Alt+ABCDEEF and get the special characters å∫ç∂éƒ, I think this is more of a bug with X11.app, not Inkscape in particular. You also can't enter Cyrillic or Chinese or Japanese text with the system-wide International input method, like you could with most native OSX applications.)

If anyone tries builds from 20924 onward, they can try the options/trackalt/value = 1. The default is 0 which is the current behavior of trusting Gdk's interpretation of keyboard state. A non-zero setting will attempt to track the Alt key manually by watching for GDK_KEY_PRESS events of GDK_Alt_L and GDK_Alt_R types. This works for me, and I tried to make this as benign and safe as possible, but I want to know if it works for other people, or if it causes problems for other people.

Unfortunately, Halley, trackalt=1 does not seem to help here (OS X 10.5 i386, X11.app from Xquartz). When I push the alt (Opt) key, the status bar text changes to indicate the alt-click, alt-drag action available, but any subsequent modified keypress gets treated like a normal keypress.

Since there have been no comments for a few months, I just wanted to say all the keymapping are still weird (as described many times above) on my OSX (10.5.7) machine, with the 0.46-developer build. No change.

As I am trying to experiment with it replacing a native drawing app, and switch apps a lot, this is troublesome behavior, and takes a lot of conscious thought (and undo keystrokes) to get any actual work done in inkscape.

To restart discussion on this very annoying bug, I have an approximative workaround. It has been tested with Leopard and X11 2.4.0.

# Background

Using xev, I find that the mapping of control keys from left to right on a US keyboard is:
        control = keycode 67 = Control_L
        option = 66 = Mode_switch
        command = 63 = Meta_L
        space
        command = 71 = Meta_R
        option = 69 = Mode_switch (with the additional message XKeysymToKeycode returns keycode: 66)

And xmodmap gives
        $ xmodmap
        xmodmap: up to 2 keys per modifier, (keycodes in parentheses):

        shift Shift_L (0x40), Shift_R (0x44)
        lock Caps_Lock (0x41)
        control Control_L (0x43), Control_R (0x46)
        mod1 Mode_switch (0x42), Mode_switch (0x45)
        mod2 Meta_L (0x3f), Meta_R (0x47)
        mod3
        mod4
        mod5

In this configuration, with X11 options "Follow system keyboard layout" and do NOT "Enable key equivalent under X11", Inkscape's behaviour is:
        control works as control
        option can be used to type accents
        option+letter does not activate menus, option+D does not clone (i.e. option does not work as alt)
        command does not do anything except switching to drawing selection mode (the red path) so in that case, and in that case only, it works as alt

# Workaround:

Use ~/.Xmodmap to remap keys under X11:

! Switch meta and control
keycode 67 = Meta_L
keycode 63 = Control_L
keycode 71 = Control_R
clear mod2
clear control
add mod2 = Meta_L
add control = Control_L Control_R

! Switch the left alt key to be alt
! and leave the other as Mode_switch, for accents
keycode 66 = Alt_L

In that configuration, xmodmap gives:
        $ xmodmap
        xmodmap: up to 3 keys per modifier, (keycodes in parentheses):

        shift Shift_L (0x40), Shift_R (0x44)
        lock Caps_Lock (0x41)
        control Control_L (0x3f), Control_R (0x46), Control_R (0x47)
        mod1 Alt_L (0x42), Mode_switch (0x45)
        mod2 Meta_L (0x43)
        mod3
        mod4
        mod5
which is not completely clean but at least, keys work in a sensible way. In Inkscape:
        control is meta (hence has little use, except to switch modes in the tweak tool for example)
        left-option works as alt: it opens menus, clones, etc.
        left-command works as control: copy, paste, ... many other shortcuts.
        right-command works the same
        right-option retains the old behaviour (Mode_switch) and allows to type special characters such as œéāß etc.

Now I don't really know where we should be going with this.
Include this "fix" as a part of the installation of Inkscape will disrupt the behaviour of all other X11 apps. A soft change for Inkscape only, if possible, should detect whether Xmodmap is already used. Anyhow, the fix is here at least.

Thank you for this in-depth analysis and workaround for the X11 keymapping issue!

This basic mapping works fine on my MBP with 10.5.8 and XQuartz 2.3.2 - 2.4.0 (though I only use the minimum: left Option key to 'Alt_L', nothing else). It does not interfere with other X11 GTK2 apps like the GIMP - if anything it helps because (like Inkscape) GIMP relies on the real 'Alt_L' keycode for some of the shortcuts (like e.g. moving a selection).

My main concern - should any xmodmap mechanism be included into the osx package - is the ongoing development process of X11/XQuartz:
1) some current versions of the XQuartz server seem to expose a bug that can loose or ignore the keymap configuration in ~/.Xmodmap (see <http://lists.macosforge.org/pipermail/xquartz-dev/2009-October/002560.html>). It's not clear to me from the occasionally mentioning I found in the mailing list archives of xquartz-dev and X11-users if this will be fixed in the next XQuartz releases for Leopard and SL. I haven't experienced the bug on my system though.
2) any future release might change the default key-mappings again - as has happened before (like changing the Option-key from Alt_L to Mode_Switch AFAIK)?

Another question I could not find an answer yet:
3) Do you know if the keycodes listed above (the hex codes) are the same on all models (laptop/desktop) and localized keyboards?

I'm hesitant to changing the keymapping when installing or launching Inkscape - OTOH I know from reading numerous postings in Inkscape and GIMP user forums that tinkering with dotfiles like .Xmodmap is a major obstacle for many users who are not familiar with the terminal and the command line and who just want to use font kerning within Inkscape.

The xmodmap bug in X11/Xquartz still confirmed for latest beta 2.4.1 for Snow Leopard:
<http://lists.macosforge.org/pipermail/xquartz-dev/2009-October/002564.html>
> [Xquartz-dev] 2.4.1_alpha2
>
> Known Issues:
> You'll need to manually run 'xmodmap' if you have a ~/.Xmodmap file

Interesting news from the release notes of Xquartz 2.5.1_beta4:
- Added a preference to toggle between Alt_L, Alt_R and Mode_switch (#374)

which fixes Xquartz ticket #374 (Alt key mapping, in Wine games):
«(…) added a preference option for this which you can use instead of ~/.Xmodmap in the next release (…)
<http://xquartz.macosforge.org/trac/ticket/374#comment:10>

Has anyone on Snow Leopard been able to test this already?

Hey! Installed XQuartz 2.6.1 (on Snow Leopard 10.6.6), logged out&in, opened Inkscape, set the option key preference in XQuartz (X11 on menu line) preferences, alt-key kerning works again!

No need to manually edit .Xmodmap :)

Just wondering... was this issue addressed or is it still happening? Please give us some update on this matter. Thanks!

Might depend on the question if people follow suggestions at https://inkscape.org/en/release/0.92.2/mac-os-x/107/dmg/

Closing because INVALID.

With the release of the non-X11-reliant 1.0 on macOS, this becomes a non-problem.

If you feel this issue has been injustly closed, please feel free to open a new issue at http://inkscape.org/report . Thank you.

Closed by: https://gitlab.com/greytomorrow