parent
a0fc9066ef
commit
540feef3bb
|
@ -752,7 +752,7 @@ HandlePrivate(struct xkb_keymap *keymap, union xkb_action *action,
|
|||
* It's possible for someone to write something like this:
|
||||
* actions = [ Private(type=3,data[0]=1,data[1]=3,data[2]=3) ]
|
||||
* where the type refers to some existing action type, e.g. LockMods.
|
||||
* This assumes that this action's struct is layed out in memory
|
||||
* This assumes that this action's struct is laid out in memory
|
||||
* exactly as described in the XKB specification and libraries.
|
||||
* We, however, have changed these structs in various ways, so this
|
||||
* assumption is no longer true. Since this is a lousy "feature", we
|
||||
|
|
|
@ -129,7 +129,7 @@
|
|||
*
|
||||
* When set to 'level1', the interpret will only match levels which are
|
||||
* the first level of the first group of the keys. This can be useful in
|
||||
* conjuction with e.g. a virtualModifier statement.
|
||||
* conjunction with e.g. a virtualModifier statement.
|
||||
*
|
||||
* - action statement:
|
||||
* action = LockMods(modifiers=NumLock);
|
||||
|
|
|
@ -294,7 +294,7 @@ AddKeyName(KeyNamesInfo *info, xkb_keycode_t kc, xkb_atom_t name,
|
|||
if (report)
|
||||
log_warn(info->ctx,
|
||||
"Multiple identical key name definitions; "
|
||||
"Later occurences of \"%s = %d\" ignored\n",
|
||||
"Later occurrences of \"%s = %d\" ignored\n",
|
||||
lname, kc);
|
||||
return true;
|
||||
}
|
||||
|
|
|
@ -417,7 +417,7 @@ AddMapEntry(KeyTypesInfo *info, KeyTypeInfo *type,
|
|||
}
|
||||
else {
|
||||
log_vrb(info->keymap->ctx, 10,
|
||||
"Multiple occurences of map[%s]= %d in %s; Ignored\n",
|
||||
"Multiple occurrences of map[%s]= %d in %s; Ignored\n",
|
||||
MapEntryTxt(info, new), new->level + 1,
|
||||
TypeTxt(info, type));
|
||||
return true;
|
||||
|
@ -518,7 +518,7 @@ AddPreserve(KeyTypesInfo *info, KeyTypeInfo *type,
|
|||
/*
|
||||
* Map does not exist, i.e. preserve[] came before map[].
|
||||
* Create a map with the specified mask mapping to Level1. The level
|
||||
* may be overriden later with an explicit map[] statement.
|
||||
* may be overridden later with an explicit map[] statement.
|
||||
*/
|
||||
new.level = 0;
|
||||
new.mods.mods = mods;
|
||||
|
|
|
@ -217,7 +217,7 @@ typedef uint32_t xkb_mod_mask_t;
|
|||
* Layout indexes are consecutive. The first layout has index 0.
|
||||
*
|
||||
* Each layout is not required to have a name, and the names are not
|
||||
* guarenteed to be unique (though they are usually provided and unique).
|
||||
* guaranteed to be unique (though they are usually provided and unique).
|
||||
* Therefore, it is not safe to use the name as a unique identifier for a
|
||||
* layout. Layout names are case-sensitive.
|
||||
*
|
||||
|
@ -297,13 +297,13 @@ struct xkb_rule_names {
|
|||
const char *rules;
|
||||
/** The keyboard model by which to interpret keycodes and LEDs. */
|
||||
const char *model;
|
||||
/** A comma seperated list of layouts (languages) to include in the
|
||||
/** A comma separated list of layouts (languages) to include in the
|
||||
* keymap. */
|
||||
const char *layout;
|
||||
/** A comma seperated list of variants, one per layout, which may
|
||||
/** A comma separated list of variants, one per layout, which may
|
||||
* modify or augment the respective layout in various ways. */
|
||||
const char *variant;
|
||||
/** A comma seprated list of options, through which the user specifies
|
||||
/** A comma separated list of options, through which the user specifies
|
||||
* non-layout related preferences, like which key combinations are used
|
||||
* for switching layouts, or which key is the Compose key. */
|
||||
const char *options;
|
||||
|
@ -331,7 +331,7 @@ struct xkb_rule_names {
|
|||
* @returns The number of bytes in the name, excluding the NUL byte. If
|
||||
* the keysym is invalid, returns -1.
|
||||
*
|
||||
* You may check if truncation has occured by comparing the return value
|
||||
* You may check if truncation has occurred by comparing the return value
|
||||
* with the length of buffer, similarly to the snprintf(3) function.
|
||||
*
|
||||
* @sa xkb_keysym_t
|
||||
|
@ -449,7 +449,7 @@ xkb_context_unref(struct xkb_context *context);
|
|||
/**
|
||||
* Store custom user data in the context.
|
||||
*
|
||||
* This may be useful in conjuction with xkb_context_set_log_fn() or other
|
||||
* This may be useful in conjunction with xkb_context_set_log_fn() or other
|
||||
* callbacks.
|
||||
*
|
||||
* @memberof xkb_context
|
||||
|
@ -629,8 +629,8 @@ xkb_context_get_log_verbosity(struct xkb_context *context);
|
|||
* function allows you to replace the default behavior with a custom
|
||||
* handler. The handler is only called with messages which match the
|
||||
* current logging level and verbosity settings for the context.
|
||||
* level is the logging level of the message. format and args are the
|
||||
* same as in the vprintf(3) function.
|
||||
* level is the logging level of the message. \c format and \c args are
|
||||
* the same as in the vprintf(3) function.
|
||||
*
|
||||
* You may use xkb_context_set_user_data() on the context, and then call
|
||||
* xkb_context_get_user_data() from within the logging function to provide
|
||||
|
@ -1082,7 +1082,7 @@ xkb_state_update_key(struct xkb_state *state, xkb_keycode_t key,
|
|||
*
|
||||
* @param[in] state The keyboard state object.
|
||||
* @param[in] key The keycode of the key.
|
||||
* @param[out] syms_out An immutible array of keysyms corresponding the
|
||||
* @param[out] syms_out An immutable array of keysyms corresponding the
|
||||
* key in the given keyboard state.
|
||||
*
|
||||
* As an extension to XKB, this function can return more than one keysym.
|
||||
|
@ -1178,7 +1178,7 @@ enum xkb_state_match {
|
|||
/**
|
||||
* Update a keyboard state from a set of explicit masks.
|
||||
*
|
||||
* This entrypoint is really only for window systems and the like, where a
|
||||
* This entry point is really only for window systems and the like, where a
|
||||
* master process holds an xkb_state, then serializes it over a wire
|
||||
* protocol, and clients then use the serialization to feed in to their own
|
||||
* xkb_state.
|
||||
|
@ -1332,7 +1332,7 @@ xkb_state_mod_indices_are_active(struct xkb_state *state,
|
|||
* Num Lock modifier does not affect this translation at all, even if it
|
||||
* active, so it is not consumed by this translation.
|
||||
*
|
||||
* It may be desireable for some application to not reuse consumed modifiers
|
||||
* It may be desirable for some application to not reuse consumed modifiers
|
||||
* for further processing, e.g. for hotkeys or keyboard shortcuts. To
|
||||
* understand why, consider some requirements from a standard shortcut
|
||||
* mechanism, and how they are implemented:
|
||||
|
|
Loading…
Reference in New Issue