GTK+ tries to automatically assign the best input module based on the
'system locale'. In the specific case of the IME input method, it will
be the default for the whole GTK+ application if the system locale is
either Japanese (ja), Korean (ko) or Chinese (zh). Other defaults are
equally applicable, e.g. if system locale is Catalan (ca), the special
'Cedilla' input module is chosen.
System locale can be changed (e.g. Win7) through the following sequence
(reboot required):
Control Panel
Region and Language
Administrative
Language for non-Unicode Programs
Change system locale...
The problem with this behaviour is that changing the 'default input
language' (e.g. from English to Japanese+IME) doesn't affect the GTK+
application. Therefore, I can have an English system locale (where GTK+
will choose Simple IM by default) but then have Japanese+IME as input
language.
Default input language can be changed (e.g. Win7) through the following
sequence (no reboot required):
System locale can be changed (e.g. Win7) through:
Control Panel
Region and Language
Keyboards and Languages
Keyboards and other input languages
Change keyboards...
Default input language can also be changed using the language bar directly.
So, instead of using the system-wide default locale to decide which input
method to use as default, better use the input language specified by the
user, which may be the same as the system-wide default locale, or different.
Following the previous example, with an English system locale and a
Japanese+IME input language, the default input method will now be IME
instead of Simple, which is closer to what's expected by the user.
This change only affects the application during startup; i.e. if the user
changes the input language while the application is running, we wouldn't be
changing the default input method to use. We could do this processing the
WM_INPUTLANGCHANGE messages, though.
https://bugzilla.gnome.org/show_bug.cgi?id=700428
The fix for child properties made the a11y dump for the assistant
case change. After close inspection, the new output is what the
code intends to produce, so update the expected result.
Call gtk_widget_get_mapped() in a couple of places before looking at the
widget's parent, since it might be set to a widget that has been
finalized, causing an invalid read.
GtkAssistant is bending the rules about child properties
of non-direct children, and the recent fix to accomodate
GtkInfoBar changes broke things. The effect was that child
properties of assistant pages in ui files were just not
applied, so all pages ended up without titles and with
the normal page type, leading to broken assistants all
over the place.
https://bugzilla.gnome.org/show_bug.cgi?id=706756
We need to copy the GDK .lib/.dll from Release_Broadway\<Platform>\bin
or Debug_Broadway\<Platform>\bin to Release\<Platform>\bin or
Debug\<Platform>\bin respectively during the build of Broadway flavors of
GDK, as the MSVC introspection builds expects the GDK .lib/.dll to be
in Release\<Platform>\bin or Debug\<Platform>\bin.
Use a new property sheet to do so for Broadway builds of GDK-during the
builds of Win32-only GDK, the broadway builds of the GDK .lib/.dll would
be cleared out prior to the build of the Win32-only GDK.
GtkAssistant supports not showing the sidebar with the page
titles (if the page have no titles). Unfortunately, we were
hiding the sidebar in this case, but still rendering the frame
behind it, leading to a broken appearance.
Horizontal scrolling is unusual, but specifying some extra offscreen
space for it in free in the normal case where the viewport is the
same width as the canvas anyway, so lets do it.
If the new requested surface size is enough larger than the previous
one (but the old is still larger than the absolute minimum),
reallocate it anyway.
This fixes an issue where the text view initially requested a really
small extra size which was then increased but that didn't "take".
This patch uses GtkPixelCache to render the contents of the widget,
and typically a bit more, to an offscreen surface. The pixel cache in
turn manages rendering to the actual surface for the widget.
The current strategy for the size to render is the size of the widget
plus half the height.
https://bugzilla.gnome.org/show_bug.cgi?id=701125
