Opened 14 years ago
Last modified 14 hours ago
#6366 assigned enhancement
Merge Keymap and Keyboad preflets
Reported by: | rq | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Preferences/Keymap | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I suggest to merge Keymap and Keyboard preflets, because Keyboard preflet is a really compact one (only has three options), and basically both of them affect keyboard behaviour. The combined preflet could then be called Keyboard, and (I think) it would make stuff less ambigous, because the user would always know that they want to click on Keyboard for keyboard related preferences. I don't think a resulting unified preflet would be too complex.
Attachments (1)
Change History (27)
comment:1 by , 14 years ago
comment:2 by , 13 years ago
Type: | bug → enhancement |
---|---|
Version: | R1/alpha2 → R1/Development |
This would be nice to have this for R1, but I don't think it is necessary. Is it too much for a GCI task? If so, it could be marked as a GoS task.
comment:3 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:4 by , 10 years ago
End result, having Keyboard as an option in the menu File in Keymap.
Step to do this?
- Move over files from Keymap to Keyboard and remove keymap. As I don't know Git, are there any preferd way of doing this?
- Merge there application classes.
- Rename Keymap to Keyboard
- Rename Keymap klasses to Keyboard?
Anything missed or are there any better ways??
comment:5 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 6 years ago
Attachment: | TastaturPrefs-Kompakt.png added |
---|
comment:7 by , 6 years ago
There is a larger GSoC project for a generic "input preferences" panel, which would also merge Mouse and Trackpad preferences, and likely add Joystick preferences in there as well. Maybe Shortcuts too.
The idea is also to allow setting different settings for each device. For example different speeds for mouse/touchpad/trackpoint, different layouts for different keyboards, etc.
comment:8 by , 31 hours ago
We've now merged the Keyboard preferences into Input preferences. Should we then just close this as "no change required"?
follow-up: 10 comment:9 by , 31 hours ago
The keymap preferences is still separate from all the other input things, and it's still not possible to set different keymaps for different keyboards (admittedly an usual setup, but it's a thing I do for a variety of reasons).
comment:10 by , 31 hours ago
Could keymap prefs still fit into the unified preflet?
Replying to pulkomandy:
and it's still not possible to set different keymaps for different keyboards (admittedly an usual setup, but it's a thing I do for a variety of reasons).
IMO that should be filed as a separate ticket.
comment:11 by , 31 hours ago
There may be a separate ticket for it already, but it is related, because it's simpler to do this in the UI by reusing the Input preflet (that already shows each keyboard as a separate device). So, these things go together:
If you put the keymap selection into the Input preflet, it has to be filed under a specific device (one of the keyboards, not all of them). Currently the preflet doesn't have a space for options that are global to all devices (it probably should, for example focus follows mouse should be global and not per pointing device). If the keymap is listed under each keyboard device, it should apply separately to each of them. Otherwise, it's a global thing and doesn't really fit into how the Input preferences work currently.
comment:12 by , 30 hours ago
I want to hope that the user will be able to configure same keymaps for all keyboards without going through the hassle of doing that for each one of them. Overriding that is okay, but I'm pretty confident that the vast majority won't need the override.
comment:13 by , 30 hours ago
The Input preference panes are right now all about the same size, and all are relatively simple. The Keymap preferences window, on the other hand, is quite large. It would be unwieldy inside the input preferences. And it does change different settings, so I think it should remain separate.
Per-keyboard keymaps should be settable in Input preferences, to be sure, but that should just present a list of the default and custom keymaps as configured in Keymap preferences, which a button to open Keymap preferences and edit them, probably. (And probably the "per-keyboard keymap" should itself be a setting that's turned off by default, as on most setups people will want just one keymap.)
comment:14 by , 29 hours ago
on most setups people will want just one keymap.
That makes no sense to me. Keymaps are keyboard specific, why would I want the same for all keyboards? Clearly it should be per-keyboard per default.
I have a french azerty keyboard in a laptop, if I connect a german keyboard I want a german keymap. And if the keyboard has a proper language defined like on apple ones It should pick the proper one even without intervention.
Connecting a second keyboard to a laptop is quite common, and atleast at my small sample size here at home usually involves keyboards with different layouts (my non-techy sibling has an american keyboard layout for the laptop for example)
comment:15 by , 29 hours ago
Well, if you're an American with all American keyboards, then you probably want the same keyboard layout for all keyboards. But it's also rare to plug in more than one keyboard, I suppose...
follow-up: 19 comment:16 by , 28 hours ago
It's not necessarily about the entire layout, for example I would like to switch some keys around just on m laptop keyboard to swap page up/down with home/end because the manufacturer put them in an unconvenient place. But I don't want this to affect an external keyboard when I use one.
comment:17 by , 28 hours ago
I agree. Per keyboard settings may be undesired in many cases. Personally I consider it as misfeature that makes more harm than benefits. When I connect external keyboard, I expect it will work the same and will have the same layout as existing one.
comment:18 by , 28 hours ago
Also users of multiple keymaps such as English/Russian usually use keymap switching by some shortcut instead of 2 separate physical keyboards.
comment:19 by , 21 hours ago
Replying to pulkomandy:
It's not necessarily about the entire layout, for example I would like to switch some keys around just on m laptop keyboard to swap page up/down with home/end because the manufacturer put them in an unconvenient place. But I don't want this to affect an external keyboard when I use one.
I thought this might be something like this. Or something like moving around the Cmd/Ctrl/Alt to make your Mac and non-Mac keyboards match. But I think this is something an advanced user would do. Maybe it would make sense to allow selecting layouts without actually generating the big editable preview, and instead allow to customize them further in a separate pop-up dialog? Or is this against the HIG?
comment:20 by , 21 hours ago
Also users of multiple keymaps such as English/Russian usually use keymap switching by some shortcut instead of 2 separate physical keyboards.
Every situation is different. As nephele mentionned, he wants to use both azerty and qwertz to match his hardware. My setup is similar: I use my laptop in azerty but my external keyboard in spanish qwerty.
I agree that this is an unusual setup, and that the default should be that the keymap applies to all keyboards. But I think it should still be possible to do it.
Maybe it is uncommon enough that I should write some variant of keymap switcher for this, and not have it in the main os.
follow-up: 24 comment:21 by , 17 hours ago
Also users of multiple keymaps such as English/Russian usually use keymap switching by some shortcut instead of 2 separate physical keyboards.
If you have a completely different alphabet that does make sense, but for european keyboards with latin keymaps but different key positions this is usually not the case. If you want to enter a letter from another european (latin based alphabet) language you can just use alt-gr for that. (This is even easier in Haiku since you can just drag/drop keys into the keymap) Here the annoyance that some keys are switched for example z and y for qwertz vs qwerty or even more keys with azerty vs qwerty or azerty vs qwertz.
The system *should* configure default keymaps correctly when possible, and for unknown ones make an educated guess what is wanted. That can be the same keymap as the previously configured one, but this for example should already be discarded if the number of keys differs. Keymaps simply can't have the same layout for different keyboards that have different numbers of keys. ISO keyboards have an extra key compared to ANSI, and also have two different modifiers alt and alt-gr where ANSI only has alt twice.
On another note detecting the keymap by asking the user to press one or two specific keys is not that hard. For example macos asks to press the key right to the left shift key. https://www.techowns.com/wp-content/uploads/2021/12/How-to-connect-keyboard-to-Mac-3-1024x746.png
Anyway, I don't think the question here is *if* the keymap should be openable from the Input preferences but rather how. One option for example would be to have a tree view in Input preferences having a top-level "Keyboard" entry you can configure directly with specific keyboards children of that to configure a specific one. (and use defaults if none is set there)
As for opening it either the keymap can be put into the preferences there directly or there should be a button for "Edit keymap" Which would then open a keymap preference with the title "Keymap for <device>"
Personally I don't see any problem with adding the keymap directly into Input, it really isn't that big, and it deals with a property specific to one input device.
Before pref/Input we also had a setting for "all mice" and that also was annoying, the per-device preference is not that complicated. Most users already have only one or two devices. And on another note for the keymap switching shortcut or switcher deskbar entry, what that configured can be defined by that software directly, it's not relevant to pref/Input.
I thought this might be something like this. Or something like moving around the Cmd/Ctrl/Alt to make your Mac and non-Mac keyboards match. But I think this is something an advanced user would do. Maybe it would make sense to allow selecting layouts without actually generating the big editable preview, and instead allow to customize them further in a separate pop-up dialog? Or is this against the HIG?
As a side note: these should *already* match (by key location) you have to select the " (mac)" variant of your keymap for this. But mac keyboards (from apple) properly declare their language and keymap in their descriptor, so we can just autoconfigure those in the future so you don't have to deal with that as a user.
comment:22 by , 17 hours ago
About keymap autodetection: note that some users are intentionally using keymap that is different from physical keyboard keymap. For example user who have a laptop with keyboard with wrong localization (bought in another country etc.). Also some users can type without looking at keyboard (so they don't care what is printed on keys) and prefer some non-standard keymap.
So I think it should be an option to globally force specific keymap and do not attempt to save per-keyboard keymap or use HID descriptors to identify keymap.
comment:23 by , 16 hours ago
Yes, autodetection is only useful to preselect a keymap in FirstBootPrompt (giving the user the option to adjust it) and maybe when a new keyboard is plugged, but then it should be under an option (and otherwise use the same keymap as all other keyboards, which is the most likely thing the user wants, even if it is not what *I* want :) )
comment:24 by , 16 hours ago
The recent comments got me thinking about some "things": Problem 1. If Haiku allows configuring different keymaps per keyboard (e.g. English US on one and French on the other), what should the keyboard indicator be showing if installed?
Problem 2. I think that Haiku's "keymaps" currently cover two conceptually very different modifications.
When Pulko wants to swap PageUp/Down with Home/End, he most likely wants that change to always be in force on that particular keyboard, regardless of whether he switches to English, Spanish, French or whatever other language he needs to type at the moment. Same goes for the case when somebody may want to map different hardware keys on different keyboards to Cmd/Ctrl/Alt (e.g. to have matching key positions on their Mac and PC keyboards).
On the other hand, changes between "national" keymaps will most likely be desired for all keyboards simultaneously. If I want to type Lithuanian, I don't want to turn that on for each keyboard independently. If I want to switch to russian, I want that to happen on all keyboards as well. Even if it's very unlikely that I'll be switching between physical keyboards four times a minute, I would still expect both my keyboards to use same layout at any given moment.
When these two types of modifications are grouped, managing them becomes quite painful, because:
- as it stands, Pulko would have to create a separate keymap for his laptop keyboard for each and every language that he intends to type.
- and if he wants to switch from EN to FR, for example, and his two keyboards require two different keymaps, how should the switch work for both keyboards at the same time?
Perhaps what "keymaps" mean should be reviewed? Maybe a more traditional approach would do better here? By "more traditional", I mean splitting keymaps into two distinct things: "keymaps1", which should cover differences between AZERTY/QWERTY/etc., and "keymaps2" (not sure about the name, maybe "keyboard remappings" or something?), which would work one level deeper and allow remapping scancodes or whatever?
This would allow simple and consistent switching between national keyboard layouts, while retaining the keys that have been remapped.
follow-up: 26 comment:25 by , 16 hours ago
This is the most likely thing, yes, but I also happen to use different layouts on different keyboards for, let's say, personal and historical reasons.
My main keyboard is a Spanish qwerty one, I use it to write French. But my laptop I use in French azerty. I don't think I need to give any justification about how it ended up this way, this is how I use my laptop, and I have to go to keymap preferences everytime I disconnect the laptop from its dock.
But it doesn't matter: I agree that this is a quite special use case, and I should be able to deal with it on my own with some kind of script or input_server filter, it is quite specific and doesn't need to be solved by the main UI, or even collaborate nicely with keymapswitcher.
So let's keep this discussion about what it should be: the keymap preferences should be merged into the input preferences. You can ignore all my weird setup for this. That means keeping a single keymap for all keyboards, and so this needs to be a separate view not belonging to any specific device. The design should be quite similar to Media preferences, where you have global "audio" and "video" sections with a few global settings, and then the specific devices under that. Here we would have "keyboards" and "pointing devices" with the specific devices under it. And the keymap would be at the global "keyboard" level.
comment:26 by , 15 hours ago
Replying to pulkomandy:
So let's keep this discussion about what it should be: the keymap preferences should be merged into the input preferences.
Sure. What I meant to say was that I don't think your wish to remap some keys is uncommon, and I see enough merit in having that as a separate functionality, which would sit below what is currently considered a "keymap". I myself would rather use that layer than duplicate "Lithuanian" keymap as "Lithuanian (Windows)" just to remap Ctrl, Alt and Cmd.
This could very well be keyboard-specific and maybe should be filed as a separate ticket?
EDIT: it would sit below, not above.
That's been on my TODO list for a long time now, a ticket surely doesn't hurt there :-)