We add a custom im module for broadway that calls some broadway
specific APIs to show/hide the keyboard on focus in/out. We then forward this
to the browser, and on the ipad we focus an input field to activate
the keyboard.
Commits the pre-edit string on receipt of focus_out and reset
commands.
Patch refinements by Cody Russell <bratsche@gnome.org> and
Ek Kato <ek.kato@gmail.com>
Replace the deprecated API calls with the updated APIs, and fix the build
of modules/input/gtkimcontextime.c, as we really needed
gdk/gdkkeysyms-compat.h (gdk/gdkkeysyms.h was already included)
https://bugzilla.gnome.org/show_bug.cgi?id=705068
The IME input method has been both ignoring keypresses of
non-spacing characters (ditching these as non displayable),
and not letting IME do anything about those.
Even though, the sparse documentation on IMM/IME seems to
hint that applications can't pipe non-spacing characters to
the input method manager, and experimentation shown that
those characters are indeed handled differently than how
it'd be expected.
Then, add basic handling of dead keys on the IME input method
itself , as it's not mutually exclusive with regular keymaps
with dead keys.
https://bugzilla.gnome.org/show_bug.cgi?id=704937
When an application translates a key event and drop its native event
before passing to imquartz, it can't recognize the NSEvent. On this
case imquartz doesn't emit any signals such as "commit" signal so
that the application doesn't insert any text. To avoid no response,
at least imquartz should fallback to slave GtkIMContextSimple.
https://bugzilla.gnome.org/show_bug.cgi?id=694273#c27
(cherry picked from commit c064e18894)
In gtkimcontextime.c, use gdk_win32_window_get_impl_hwnd() to get to
the impl's existing native window instead of GDK_WINDOW_HWND() which
implicitly ensures a native window for the widget itself. This seems
to work around whatever GDK problem with native subwindows and fixes
the bug.
This is based on Michael Natterer's fix for gtk-2-24.
GDK_WINDOW_XID() has the side-effect of turning a window native;
this in turn can have unexpected effects such as black backgrounds.
Avoid this by using the XID of the toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=682395
Be a bit more careful in get_pango_attr_list() and
get_utf8_preedit_string() to ensure that the client_window is properly
created before proceeding, to avoid access violation/segfault crashes on
Windows with IME installed, especially when running the pickers demo.
https://bugzilla.gnome.org/show_bug.cgi?id=682919
These are just wrappers for the functions, and we want to
deprecate them. Stopping to use them internally is a good
first step. Also define GTK_COMPILATION so we can keep using
gdk_threads_enter/leave without causing deprecation warnings.
Commit de62a1096 broke win32 as it removed the HAVE_X11R6 checks for
building xim, but did not replace them with USE_X11. This made
it try to build xim on non-X targets.
When GTK+ runs with inputim-ime.dll module, there is NULL
pointer reference. Because "context_ime->client_window" may
be NULL in gtk_im_context_ime_reset.
https://bugzilla.gnome.org/show_bug.cgi?id=644906
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
In bug 635207, it was pointed out that it is a bad idea to
rename these tools purely in the name of parallel-installability,
since it forces dependencies to make a choice between running
gtk-update-icon-cache and gtk-update-icon-cache-3.0 (or both ?!).
So, we rename these utilities back to their un-suffixed names
and rely on distributors to resolve the conflict between GTK+ 2.x
and GTK+ 3.0 packages, which can be done e.g. by dropping the
utilities from the gtk3 packages and add a gtk3 -> gtk2 dependency.
This commit does a number of things:
- remove some dead wchar configury from configure.ac and gdkconfig.h
- repurpose gdkconfig.h as header that contains GDK_WINDOWING_foo
macros for each included backend, include it in gdk.h and install
it in $includedir instead of below $libdir
- drop the backend from the library names
- build libgdk-3.0.la as a convenience lib and include it in libgtk-3.0.la
It does not yet enable building multiple backends at the same time.
Some GtkSettings property are registered by other classes. This leads
to the "interesting" issue that setting GtkSettings:gtk-button-images
requires that the GtkButton class is referenced first - or that a
GtkButton is created.
https://bugzilla.gnome.org/show_bug.cgi?id=632538
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
Ha, pango_win32_font_logfontw hasn't been exported from libpangowin32
after all due to a typo. This will have to wait. And actually
libpangowin32 is supposed to be deprecated surely, so that
functionality should be moved to libpangocairo or something.
This reverts commit 804effba99.
