Age | Commit message (Collapse) | Author | Files | Lines |
|
A "nodeadkeys" variant had better not contain any dead symbols.
(This should have been part of commit b615e54f02, to compensate
the including layout for the changes in the included one.)
This fixes issue #420.
Reported-by: Fabian Bläse
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
This follows https://iks.cs.ovgu.de/~elkner/keyboard/mac/germankbd.html,
level 3: https://iks.cs.ovgu.de/~elkner/keyboard/mac/german-option.gif,
level 4: https://iks.cs.ovgu.de/~elkner/keyboard/mac/german-alt.gif.
This fixes issue #304.
Reported-by: Laszlo Lebrun
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Adding the specifiers "(Italian keyboard)" and "(German keyboard)"
may look over the top, as xkeyboard-config is all about keyboards,
but it makes things the most clear for the user.
Also, move the Ladin layout for the basic German keyboard to the file
for Italy, as the places where Ladin is spoken are all there.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Key names of the form <AXnn> always refer to the same keys, whereas
names like <LatA>, <LatM>, and <LatZ> can refer to different keys,
depending on whether the first group is Qwerty, Azerty, or Qwertz.
For <LatA>, <LatQ>, <LatW>, <LatY>, and <LatZ> this is fine as they
get aliased always to other _letter_ keys. But for <LatM> this is
troublesome as for Azerty layouts it gets aliased to <AC10>, which
in most layouts is a punctuation key, which means that either the
punctuation sign or the phonetic equivalent of the letter M is lost
when a "phonetic" layout is used together with the Azerty aliases.
Resolve this by using almost always the <AXnn> key names -- keeping
only the five non-troublesome aliases, where appropriate, in order to
not change anything for people who use a second-group phonetic layout
together with a first-group Qwertz layout.
This fixes issue #401.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
|
|
|
|
The included `de(nodeadkeys)` variant includes `de(basic)` which already
includes `latin(type4)`, so there is no need to include the latter here.
|
|
The Sorbian layouts were added fifteen years ago in commit 775b0342af,
with the Euro sign (`€`) on level 4 of the `T` key, and the Ghanaian
cedi sign (`₵`, U+20B5) on level 3. It is obvious that the cent sign
(`¢`) was meant instead, as Sorbian has nothing to do with Ghana.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The keysyms ezh (`ʒ`) and EZH (`Ʒ`) are clearer than their codes.
|
|
The two are equivalent, but the latter is clearer.
|
|
This leaves one dead symbol in the Finnish "nodeadkeys" variant,
and five dead symbols in the Hungarian one, but... they are all
on the fourth level, so... let them be.
The upper-level dead symbols are replaced with the marginally useful
ezh (`ʒ`), dagger (`†`), radical (`√`), and ellipsis (`…`).
This partially addresses and closes issue #339.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
The "EIGHT_LEVEL_LEVEL_FIVE_LOCK" name was too condensed to make sense.
With "EIGHT_LEVEL_WITH_LEVEL5_LOCK" the reader has at least a chance
of understanding it.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Also, replace "NoSymbol" with the equivalent but shorter "any",
and reshuffle the LSGT key into its usual place.
|
|
In the E1 layout, the keys with letters on the first two levels
contain symbols (not letters) on the third level, and nothing on
the fourth level. So, CapsLock should not affect the third level,
otherwise AltGr plus a letter key would do nothing when CapsLock
is engaged.
This fixes issue #333.
Problem existed since the E1 layout was introduced three years ago
in commit b9063591ec.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
Or standardize on a four-digit code and add comments that show
the corresponding character.
|
|
Symbol codes could change, while symbol names will stay the same.
Note that the € sign on the sixth level of <AE04> is a duplicate with
the third level of <AD03>, but it makes sense when seeing the sterling
sign (£) to its left on <AE03>.
|
|
When a key defines fewer levels than its type has room for, xkbcomp
fills in the unspecified upper levels automatically with 'NoSymbol'.
Specifying 'NoSymbol' explicitly is just unneeded verbosity.
|
|
In symbols/pc, <LVL3> gets ISO_Level3_Shift assigned and mapped to Mod5,
and <LVL5> gets ISO_Level5_Shift assigned and mapped to Mod3, and there
is not any layout nor any option that changes anything in this. Thus,
repeating these assignments and mappings is entirely superfluous.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
In XKB, the keywords Mod1 to Mod5 have a specific meaning: they are
the identifiers of actual modifier bits in the keyboard state. It
was therefore confusing to see the comments for the Neo layout use
the words "Mod3" and "Mod4" with a different meaning: as abstracted
names for certain keys. When grepping the XKB files for Mod[1-5],
one wants to find only occurrences that refer to the actual modifier
bits, and not occurrences that mean something else. So, reword the
latter occurrences to avoid false positives.
[To document the confusion: the Neo "Mod three" key affects the Mod5
modifier bit (LevelThree), while the "Mod four" key affects the Mod3
modifier bit (LevelFive) when just setting it, and Mod2 (NumLock) when
locking it.]
Additionally make a few esthetic tweaks.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
|
|
|
|
|
|
Also normalize some inconsistent whitespace,
replace leading comments with trailing ones,
and reorder three keys.
|
|
|
|
Those keys are already defined as such by the included layouts.
(Possibly the intent was to clear the upper levels of those keys,
but the definitions didn't do that. And what would be the point?)
|
|
As Lower Sorbian is spoken in parts of Germany, it makes far more sense
to base the Sorbian QWERTZ layout on the standard German QWERTZ layout
that is engraved on most keyboards, and not on a QWERTY layout.
Fixes #253.
|
|
(So that subsequently the three components can be applied separately.)
|
|
Five months ago, '<' and '>' were replaced with '‹' and '›' on many
layouts by commit b17b586087. It seemed like a logical thing to do:
put single guillemots on the fourth level when the double ones are
on the third. However, this made '<' and '>' untypable for a bunch
of people because most keyboards do not have a LSGT key and their
layouts did not contain any other key with 'less' or 'greater'.
There were reports for Latin American, Turkish, Spanish, Italian.
And Norwegian and Portuguese are also affected, from a quick check.
So, revert the change, also because these single guillemots are
useful to hardly anyone.
Fixes #286.
Reported-by: Eduard Tolosa
|
|
|
|
Signed-off-by: Michael von Glasow <michael -at- vonglasow.com>
|
|
Signed-off-by: Michael von Glasow <michael -at- vonglasow.com>
|
|
The defined character differs from the official Neo reference and should be a fraction slash (U+2044).
|
|
No functional effect but it makes simple parsers easier and grep more
reliable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
|
|
And transform a few others into a more useful form.
|
|
The "Sun dead keys" variants for Austria, Germany, the Netherlands,
and Turkey were identical to the basic layout for those countries.
Listing a variant in the layouts-choosing dialog that isn't really
a variant doesn't make sense, so remove them.
|
|
These variants are not referenced from rules/base.xml, and are always
the same layout as the one with a lowercase "sun". The capitalized
variants are referenced only from the symbols/sun_vndr/* files, so...
simply adjust the references there and delete the capitalized layouts.
|
|
|
|
Also remove four useless comments.
|
|
To avoid the name getting overridden by a name in those includes.
|
|
|
|
Manually checked the keymap against the standard document
(DIN 2137-1:2018-12, doi:10.31030/2890217).
|
|
|
|
|
|
|
|
|
|
|
|
Too old to be supported
|
|
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/144
|