| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This can be used with ‘guix shell --manifest=manifest.scm’ to get a ready-to-go
build environment with all required dependencies.
|
| | |
|
| |
|
|
|
| |
Finally, a use case for ‘goto’ that I think solves the issue pretty nicely. Not
so evil after all, perhaps.
|
| |
|
|
|
|
|
|
| |
I want to know specifically which keys I use the most that _aren't_ just
letters.
I have a keyboard layout that I like just fine, but I want to know which special
keys I actually use the most.
|
| | |
|
| |
|
|
| |
just a shields api change: https://github.com/badges/shields/issues/8671
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #5, perhaps fully this time.
It seems non-zero keysym groups work such that if no keysym is defined
in it, the default 0 group's keysym is assumed.
In other words, common keys that would otherwise just be duplicated in
the group's definition, such as Return, Backspace, Delete, Shift, Space,
or the numpad keys, just have no symbol mapped to them at all in the
group (XkbKeycodeToKeysym returns NoSymbol). In such cases, it seems
the receiving program is expected to just fall back to group 0 and read
the keysym from there instead.
This is about XKeycodeToKeysym, but XkbKeycodeToKeysym which we're using
(note the different prefix) seems to function the same:
https://stackoverflow.com/questions/54483276/xkeysymtokeycode-and-keyboard-layout
This seems to be correct with the keyboard layouts I've tested.
- - -
Other Xlib users have replaced XKeycodeToKeysym with XGetKeyboardMapping
instead. These patches to that effect imply XKeycodeToKeysym is
deprecated:
- https://lists.freedesktop.org/archives/piglit/2012-January/001795.html
- https://github.com/ArcticaProject/nx-libs/commit/c79f2d289004d419d8bb76cf8bf731980d40da5d
XkbKeycodeToKeysym is not deprecated though, and seems a much better fit
here than doing heap allocations in a loop, so I'll go with it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in issue #5, xkbcat would previously not react at all to
keyboard layout changes; it would continue to print keysyms according to
the first keyboard layout X was started with.
Keyboard keysym group changes (i.e. keyboard layout changes) are
listened to as separate events, so if you only use 1 layout, this causes
no performance overhead.
Closes #5.
Thanks to @unxed for very helpful research.
|
| | |
|
| |
|
|
|
|
|
|
| |
This was always invalid input, but there was no special handling, so if
the `-display` option was given in the last position, the value could be
read 1 entry off the end of the `argv` array.
This catches that, and gives an informative error.
|
| |
|
|
| |
In case this wasn't clear.
|
| |
|
|
| |
Clearer.
|
| |
|
|
| |
Maintenance. No functionality changes.
|
| |\
| |
| |
| |
| | |
Since Travis won't run the build anymore (unless I register for the new
.com one that is annoying for OSdev), going for Github Actions instead.
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
I think this is the right way to express this, let's see what Github's
build server thinks.
|
| |\
| |
| |
| | |
Fixes #4.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Re #4. Apparently this matters; https://stackoverflow.com/a/409470.
The previous order (source file last) has worked for me locally on gcc
and clang on Void Linux the whole time, and it works in clang on Travis
too. Either way, Travis GCC will catch regressions.
|
| | |
| |
| |
| |
| |
| |
| | |
In addition to clang that is; re issue #4.
Ubuntu Focal only has gcc 9.3.0 like my local machine, so I'm expecting
this to pass too but at least it's a second opinion.
|
| | |
| |
| |
| |
| | |
Should have newer versions of stuff. Perhaps including GCC, to repro
https://github.com/anko/xkbcat/issues/4.
|
| |/
|
|
|
| |
Inaccurate for it to go red when some speculative feature branch or PR
fails.
|
| |
|
|
| |
Closes #3.
|
| | |
|
| |
|
|
| |
Saves cycles.
|
| |
|
|
| |
Saves cycles.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is necessary to guarantee the same API in case future versions of
XInput decide to break backward compatibility in their defaults.
Quoting `man 3 xiqueryversion`:
> Clients are required to use XIQueryVersion instead of
> XGetExtensionVersion if they use XI2 calls. The server may treat a
> client differently depending on the supported version announced by the
> client.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Ref issue #2.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
GCC is failing with "undefined reference"
https://travis-ci.org/anko/xkbcat/jobs/636386190 for reasons I cannot
comprehend or reproduce anywhere else, but clang is passing like it's
supposed to, so I guess that's our life now.
|
| |/
|
|
|
|
| |
I have no idea how the build is failing with the $(CC) change. Flags
look the same. Only difference is it's defaulting to gcc. Let's see if
this changes anything.
|
| |
|
|
| |
The fancy one was unreliable.
|
| | |
|
| |
|
|
|
| |
Who knows what C compiler users like to use. This should cause the
right one to be chosen automatically.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Whoops.
|
| |
|
|
|
| |
Avoids errors when nothing is there to be cleaned up: that's a
successful cleanup too.
|
| |
|
|
|
| |
I think this is a remnant from some time ago when output executable
wasn't called "xkbcat", but it is now, so the .PHONY is unnecessary.
|
| | |
|
| | |
|
| |
|
|
| |
Simpler, now that we don't need the time structs anymore.
|
| |
|
|
| |
Neater implementation, better performance.
|
Tom Willemse
Antti Korpimäki
Antti Korpi