Opened 13 years ago

Closed 11 years ago

#7428 closed bug (fixed)

Alt-Plus won't work in WebPositive

Reported by: js Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

When pressing Alt-Plus in WebPositive, the zoom is not increased. However, when pressing Alt-Minus, it works. I'm running WebPositive hrev577 on Haiku hrev41168 in VMware Fusion.

Change History (7)

comment:1 by taos, 13 years ago

Running Haiku hrev41168 (gcc2hybrid) and WebPositive hrev577 on real hardware,

Alt-Plus (as well as Alt-Minus and Alt-0) works - zoom is increased.

Might be a problem only with virtual hardware? I don't have VMWare Fusion but I could test this with VirtualBox.

comment:2 by axeld, 13 years ago

It's a bug we inherited from BeOS (its poor shortcut handling), and is keymap depending; ie. some keymaps require other/extra modifiers to generate a certain key, others don't, and that confuses the shortcut mechanism.

There is probably already a ticket out there for this.

comment:3 by tangobravo, 13 years ago

#6692 is another report of the same issue in Tracker, but I can't find a general bug.

I wonder how it could be fixed in the general case, as we do allow shift to be part of a shortcut. How to tell the difference between "alt-shift-equals" and "alt-plus" (shift-equals is plus on a UK keymap)? Prioritise the one with the shift as part of the shortcut, but if nothing is found then fall back to trying other combinations? It's not simple, as different modifier keys can produce different characters on other keymaps, not always shift...

in reply to:  3 comment:4 by X512, 13 years ago

Replying to tangobravo:

#6692 is another report of the same issue in Tracker, but I can't find a general bug.

Mayble #2499?

comment:5 by leavengood, 12 years ago

I think we need a way to ask the keymap what is required to get a certain character, and then the shortcut handling will take that into account. So for example in this ticket, the plus sign (+) is on the equals (=) key on US and UK keymaps. So for Cmd-+ to work on those keymaps, we really need to look for Cmd-Shift-+. The reason we would not look for Cmd-Shift-= is that the key will already have been offset (in the parlance of keymaps) to + from = in the keyboard handling, since Shift was down. The good thing about that is that Cmd-Shift-= could in theory still be a shortcut for something else, and it would still work, given there was another way to get an = while Shift was down (such as in the numpad.) Of course that isn't a smart way to set up shortcuts in an app, but it could work.

Checking out the Keymap code there is not yet any facility for this, but it should be possible to build inverse maps from characters to modifiers needed to get those characters. Though I guess shift is the main one we would be concerned with for this purpose.

So maybe:

uint32
BKeymap::ModifiersNeededForCharacter(uint32 c)
{
   // Something which builds an inverse map if it doesn't yet exist, caches
   // it, and looks up the modifiers needed for c. Probably just the shift_map
   // to start.
}

When a shortcut is set up (and when the keymap changes), the above can be called, and the modifiers returned can be added to the shortcuts modifiers list. And then it should all magically work. Of course letters would not have this done (since we want Cmd-q and Cmd-Q to work the same.)

Add translatable shortcuts as I discussed in https://dev.haiku-os.org/ticket/2499#comment:17 and I think Haiku no longer has a shortcut problem.

Last edited 12 years ago by leavengood (previous) (diff)

comment:6 by leavengood, 12 years ago

Turns out I'm wrong and pressing Cmd-Shift-= on a US keymap will not send Cmd-Shift-+ into the shortcut handling but Cmd-Shift-=. This is probably because all the modifiers are taken into account when offsetting within the keymap, so Cmd+Shift uses a different offset table than Shift alone (actually looking at the code whenever Cmd is pressed the key is never offset.) But I think similar logic as described above can be used when matching the key, just instead of adding modifiers, both the key and the modifiers need to be changed internally.

Just an additional caveat is that this means developers could define two shortcuts in the same app which are ambiguous, depending on the keymap (Cmd-+ and Cmd-Shift-= being the obvious ones in this case.) So some sort of warning should come up for that maybe, just unfortunately that can really only be done at runtime, and it depends on the user keymap.

I may just need to research and see what other OSes do for this, because I know that Cmd-+ works fine on the Mac for instance.

comment:7 by jscipione, 11 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev46262

Note: See TracTickets for help on using tickets.