Re: Some Dead Keys not supported
On 17.08.2015 01:28, Alexander Roalter wrote: I’m not sure this is the correct place to report this, but I have the following issue with keyboard input in GTK (and this extends to almost my entire Linux). Recently, I installed the german T3 keyboard, which has amongst many special characters also some additional dead keys, namely for the comma below and the stroke. Comma below is used for typing Romanian (ș≠ş, ț≠ţ), the stroke is used for (ħ, ŧ, used in Maltese). In xterm and basic X programs, this works as expected, but in GTK applications, this dead key is simply ignored, so I get an s instead of ș. There is a definition for the Windows keyboard that also implements the T3 keyboard (or rather a subset of it, the T2 keyboard), which uses a special dead key sequence for giving access to Level 5-8 of the keyboard (under Linux, this is done by pressing AltGr+Shift, so no deadkey needed there). Windows-GTK-programs have the same issue. the deadkeys stroke, comma below and this special dead key sequence are ignored (and other keyboard layouts which also use differing keyboard mappings, such as the german NEO layout have similar problems) What I gathered is that GTK brings its very own keyboard stroke to character engine, and apparently simply ignores the dead key sequences it doesn't know about. Is this assumption correct? And is there anything one can do to either let X11 do its thing or have GTK learn about the other deadkey sequences? (the latter one would help with my Windows-GTK-Problems at Work, since thatʹs the only place I have Windows running) I guess it’s a follow up for https://mail.gnome.org/archives/commits-list/2014-September/msg03726.html At home, my olderish gtk doesn’t show it, but xterm does. At work, at a brand new ubuntu 14, neither gtk nor xterm do work (xev still shows the dead_belowcomma) being generated. -- Cheers, Alex -- Cheers, Alex ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some Dead Keys not supported
I’m not sure this is the correct place to report this, but I have the following issue with keyboard input in GTK (and this extends to almost my entire Linux). Recently, I installed the german T3 keyboard, which has amongst many special characters also some additional dead keys, namely for the comma below and the stroke. Comma below is used for typing Romanian (ș≠ş, ț≠ţ), the stroke is used for (ħ, ŧ, used in Maltese). In xterm and basic X programs, this works as expected, but in GTK applications, this dead key is simply ignored, so I get an s instead of ș. There is a definition for the Windows keyboard that also implements the T3 keyboard (or rather a subset of it, the T2 keyboard), which uses a special dead key sequence for giving access to Level 5-8 of the keyboard (under Linux, this is done by pressing AltGr+Shift, so no deadkey needed there). Windows-GTK-programs have the same issue. the deadkeys stroke, comma below and this special dead key sequence are ignored (and other keyboard layouts which also use differing keyboard mappings, such as the german NEO layout have similar problems) What I gathered is that GTK brings its very own keyboard stroke to character engine, and apparently simply ignores the dead key sequences it doesn't know about. Is this assumption correct? And is there anything one can do to either let X11 do its thing or have GTK learn about the other deadkey sequences? (the latter one would help with my Windows-GTK-Problems at Work, since thatʹs the only place I have Windows running) -- Cheers, Alex ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Bug 602733] Extended Input with Xinerama
On 11/25/2009 10:40 PM, gtk+ (bugzilla.gnome.org) wrote:
https://bugzilla.gnome.org/show_bug.cgi?id=602733
gtk+ | gdk | unspecified
Matthias Clasen mclasen changed:
What|Removed |Added
CC||mcla...@redhat.com
--- Comment #1 from Matthias Clasen mcla...@redhat.com 2009-11-25 21:40:52
UTC ---
This will have to be redone against the xi2 branch which we are going to merge
sometime soon. But I am dubious about the claims here.
[...] still behaves as if the tablet weren't
restricted to only a single screen, even though the normal cursor knows
better
and stays at the same screen.
What is restricting the 'normal cursor' to a single screen here ? And is the
'normal cursor' the core pointer, or the tablet ?
Finally, is your setup really two screens, or is it to monitors that form a
single screen ?
Once again I submit the patch for a working tablet (extended input
support) with GTK (e.g. in Inkscape and GIMP) when using Xinerama and
Screen Mode for the Input device.
Patch was made with git diff xinerama.diff, if there's something wrong
with that please let me know
--
Cheers,
Alex
diff --git a/gdk/x11/gdkinput-x11.c b/gdk/x11/gdkinput-x11.c
index 767b070..77f1ef0 100644
--- a/gdk/x11/gdkinput-x11.c
+++ b/gdk/x11/gdkinput-x11.c
@@ -454,11 +454,18 @@ gdk_input_translate_coordinates (GdkDevicePrivate *gdkdev,
if (gdkdev-info.mode == GDK_MODE_SCREEN)
{
- x_scale = gdk_screen_get_width (gdk_drawable_get_screen (window)) / device_width;
- y_scale = gdk_screen_get_height (gdk_drawable_get_screen (window)) / device_height;
-
- x_offset = - impl_window-input_window-root_x - priv-abs_x;
- y_offset = - impl_window-input_window-root_y - priv-abs_y;
+ int core_pointer_x, core_pointer_y, cur_monitor;
+ GdkRectangle mon_geometry;
+ GdkScreen *cur_screen;
+ gdk_display_get_pointer (gdk_drawable_get_display (window), cur_screen, core_pointer_x, core_pointer_y, 0);
+ cur_monitor = gdk_screen_get_monitor_at_point (cur_screen, core_pointer_x, core_pointer_y);
+
+ gdk_screen_get_monitor_geometry (cur_screen, cur_monitor, mon_geometry);
+ x_scale = mon_geometry.width / device_width;
+ y_scale = mon_geometry.height / device_height;
+
+ x_offset = - impl_window-input_window-root_x - priv-abs_x + mon_geometry.x;
+ y_offset = - impl_window-input_window-root_y - priv-abs_y + mon_geometry.y;
}
else/* GDK_MODE_WINDOW */
{
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Xinerama-Setup and Extended Input devices (Screen Mode)
When I use Screen Mode with my Wacom Tablet, Inkscape and GIMP (both
using the gtk xinput) show the following behavior: since I limit the
Tablet to only one screen (1680x1050), but my entire desktop spans over
three screens (1680+1680+1920x1080), if I draw a circle, on the canvas
of Gimp I see an ellipse which is approximately three times as wide as
it is high.
this means, that in screen mode the coordinates are the data from the
tablet (in the 16000x12000 range) converted to the entire screen
(5280x1080) instead of that of the current screen.
I therefore made the following change, which takes into account the
current screen's size, and at least for me now everything works as it
should: a circle on the tablet becomes a circle on the canvas.
Mind you, this happens only in screen mode (but that's apart from Window
mode the only mode where pressure sensitivity works).
--
Cheers,
Alex
diff --git a/gdk/x11/gdkinput-x11.c b/gdk/x11/gdkinput-x11.c
index a793a42..355963e 100644
--- a/gdk/x11/gdkinput-x11.c
+++ b/gdk/x11/gdkinput-x11.c
@@ -454,8 +454,15 @@ gdk_input_translate_coordinates (GdkDevicePrivate *gdkdev,
if (gdkdev-info.mode == GDK_MODE_SCREEN)
{
- x_scale = gdk_screen_get_width (gdk_drawable_get_screen (window)) / device_width;
- y_scale = gdk_screen_get_height (gdk_drawable_get_screen (window)) / device_height;
+ int core_pointer_x, core_pointer_y, cur_monitor;
+ GdkRectangle mon_geometry;
+ GdkScreen *cur_screen;
+ gdk_display_get_pointer(gdk_drawable_get_display(window),cur_screen,core_pointer_x,core_pointer_y,0);
+ cur_monitor = gdk_screen_get_monitor_at_point(cur_screen, core_pointer_x, core_pointer_y);
+
+ gdk_screen_get_monitor_geometry(cur_screen,cur_monitor,mon_geometry);
+ x_scale = mon_geometry.width / device_width;
+ y_scale = mon_geometry.height / device_height;
x_offset = - impl_window-input_window-root_x - priv-abs_x;
y_offset = - impl_window-input_window-root_y - priv-abs_y;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
