| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
- fullcolor app icon
- symbolic
- emblem for gitlab
Fixes https://gitlab.gnome.org/GNOME/libgnomekbd/-/issues/15
|
|
|
|
|
|
|
|
|
| |
The `X-GNOME-Bugzilla-*` entries were for use by bug-buddy, a GNOME 2
technology that's been gone for over a decade. These entries are
obsolete and can be removed from the desktop file.
The desktop file then has no variables so does not need to be
configured. It is renamed from `*.in.in` to `*.in` to reflect that and
build files and POTFILES are updated for this change.
|
|
|
| |
This reverts commit 2ed57e840ed8df1a38db226becb3ba3dfaf992db
|
|
|
|
|
| |
The X-GNOME-Bugzilla-* entries were for use by bug-buddy, a GNOME 2
technology that's been gone for over a decade. These entries are
obsolete and can be removed.
|
| |
|
|
|
|
|
| |
And rename the option 'gir' to 'introspection' to match other GNOME
projects.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the meson build system would install:
- libgnomekbd.so.3.28.0 with symlinks from
- libgnomekbd.so.8.0.0
- libgnomekbd.so
This didn't match the autotools build system, which installed:
- libgnomekbd.so.8.0.0 with symlinks from
- libgnomekbd.so.8
- libgnomekbd.so
The ABI didn't change between v3.26.1 (which only had autotools) and
v3.28.0, so I don't think we should install .so.3.28.0 shared objects.
This change makes meson install the same shared objects and symlinks as
autotools.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://docs.gtk.org/Pango/method.Layout.set_auto_dir.html says:
> When the auto-computed direction of a paragraph differs from the
> base direction of the context, the interpretation of
> PANGO_ALIGN_LEFT and PANGO_ALIGN_RIGHT are swapped.
Now that symbols are placed based using alignment, we don't want RTL
symbols placed on the wrong side of the key rendering. To do this, we
invert the alignment for RTL symbols.
Closes: #8
|
|
|
|
|
| |
This information (whether a symbol is LTR or RTL) will be useful in
figuring out how to align the symbol on the drawing of the key.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, left-displayed symbols (those produced without AltGr) are
drawn on a key rendering in a full-width cell, but right-displayed
symbols (those produced with AltGr) are only drawn in half-width cells
on the key rendering.
This means that left-displayed symbols can still overlap with
right-hand symbols if they happen to be wide, but right-hand symbols
are more likely to be truncated ("ellipsized").
This change still allows the symbols to overlap, but makes
right-displayed symbols less likely to be ellipsized. We do this by
using alignment to place right-displayed symbols to the right, instead
of using a half-width cell.
|
|
|
|
|
| |
Previously would crash when running:
$ gkbd-keyboard-display -l nosuchlayout
|
|
|
|
| |
GkbdStatus is a GtkStatusIcon subclass.
|
|
|
|
| |
Use GLib helper macro to define the indicator.
|
| |
|
|
|
|
| |
warning in build.
|
|
|
|
| |
Also make all the constant arrays internal.
|
|
|
|
|
|
| |
Allows to use autoptr and to reduce verbosity.
Also add sanity checks to API endpoints.
|
|\
| |
| |
| |
| | |
Avoid some deprecated Gdk/Gtk codepaths
See merge request GNOME/libgnomekbd!10
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The only places that were using GdkScreen were using it to get monitor
width and height.
All the gdk_screen_* calls that were being used are explicitly
deprecated. Use GdkDisplay instead.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Use Unicode in translatable strings
See merge request GNOME/libgnomekbd!1
|
| |/
| |
| |
| |
| |
| | |
See https://developer.gnome.org/hig/stable/typography.html
https://bugzilla.gnome.org/show_bug.cgi?id=772762
|
|/
|
|
| |
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
|
|
|
|
| |
it conflicts with the newly added g_strv_equal in glib
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=778089
|
|
|
|
| |
So they appear in .po files.
|
|
|
|
| |
Commit a0c98a08 left us with uninstallable schemas.
|
|
|
|
| |
This code is heavily dependent on X11 API.
|
|
|
|
|
| |
Asking for a keyboard device's position doesn't even make sense
anyway.
|
|
|
|
| |
It's not needed with modern gtk+ .
|
|
|
|
| |
This isn't needed and in fact causes runtime warnings.
|
| |
|
|
|
|
|
|
| |
XkbGetKeyboard() might fail but we might still be able to work with a
XkbGetKeyboardByName() later in gkbd_keyboard_drawing_set_keyboard()
so don't abort the initialization if it fails.
|
|
|
|
|
|
| |
We need to tell gtk+ we handled the key event otherwise gtk+ keynav
key events will move focus to the close button and it looks like the
dialog stopped working.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When drawing the keyboard without having set the groups and levels there
is a segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffe49ae8c9 in draw_key_label (is_pressed=<optimized out>, xkb_height=<optimized out>, xkb_width=<optimized out>, xkb_origin_y=<optimized out>,
xkb_origin_x=<optimized out>, angle=0, keycode=<optimized out>, drawing=0xa540e0, context=0xca6080) at gkbd-keyboard-drawing.c:1017
1017 if (drawing->groupLevels[glp] == NULL)
Fix that.
The widget now is able to draw a keyboard without the keys labels, which
can be useful when testing just the keyboard geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=760988
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When track_modifiers is true and a modifier key gets pressed, do not
free and reallocate the data and, in particular, do not reallocate
drawing->keys zeroing it; this would result in the modifier keys pressed
states to be forgotten and the modifier keys not to be shown as pressed
when in fact they are (the keyboard symbols reflect the shift level
correctly).
Fix the current situation, allowing the modifier keys pressed state to
be drawn correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=734621
|
|
|
|
|
|
|
|
|
|
|
| |
Some keys like the function key "FN" are described in geometry files but
they have no keycode associated to them. You can find such keys in the
thinkpad and in the hhk geometry files.
Allow drawing the shape of these keys with invalid keycodes, and just
skip looking for the labels as the label is derived from the keycode.
https://bugzilla.gnome.org/show_bug.cgi?id=734618
|
|
|
|
|
|
|
| |
* Cleans up a bunch of warnings, and gets g-ir-scanner to actually
recognize the annotations.
https://bugzilla.gnome.org/show_bug.cgi?id=675729
|
|
|
|
|
| |
Implemented in g-s-d through custom scripts
https://bugzilla.gnome.org/show_bug.cgi?id=674874
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=674873
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Spurious double quotes around uidir and iconsdir makes
install attempt to install in '<DESTDIR>"<iconsdir>"'
ie
'/opt/gnome/_jhbuild/root-libgnomekbd\"/opt/gnome/share/libgnomekb/icons\"'
Then install fails to install the data files into the correct directory:
'/opt/gnome/_jhbuild/root-libgnomekbd/opt/gnome/share/libgnomekb/icons'.
It looks like the for loop to install items expands the icons and ui
dirs while the mkdir -p does not.
Fix this issue by removing the double quotes in th Makefile.am around
the iconsdir and uidir assignments.
|
|
|
|
|
|
|
|
| |
Since gkbd_keyboard_config_split_items uses static storage, if
we want to call it twice and compare the results we have to
make a copy.
https://bugzilla.gnome.org/show_bug.cgi?id=673539
|
|
|
|
| |
A part of https://bugzilla.gnome.org/show_bug.cgi?id=660000 fix. The xmodmap config patching should happen regardless of the configuration changes (even if from xkb POV there was no change).
|