This was added a few years ago, as a way to have _no_ im context
at all. But it didn't actually work. Make it work, and streamline
the handling of none by moving it all to gtkimmodule.c.
As part of this, add context to the translated names of all
im modules we ship.
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
When loading SVGs from ICON_THEME_DIR_UNTHEMED GtkIconInfos,
such as those created for a GLoadableIcon, the size of the pixbuf to
load is set as a product of icon_info->scale.
But a few lines above, icon_info->scale is set to -1 for
ICON_THEME_DIR_UNTHEMED GtkIconInfos, so we'll end up always passing a
negative size to the GdkPixbuf loader, which is interpreted as the
nominal size of the image file.
Instead load the SVG at the desired scaled size in that case.
This fixes blurry icon in the notification panel in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
When loading a GResource-backed GFileIcon into a GtkIconInfo we
currently fail to populate the is_resource private field.
Also, since is_svg is set by looking at the filename, and
g_file_get_path() returns NULL for a GResourceFile, is_svg was always
FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
Add a way to set a delay factor that can be used
to make the long press more or less sensitive.
Making this a factor instead of exposing the delay
itself preserves the value of the setting as an
overall 'slow down long press' setting.
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
While a popover is hiding, the modal grab is already gone and the toggle
button is clickable again, but clicking again at that time will result in
gtk_widget_show() trying to show an already shown widget (although fading
out and hidden soon) and the toggle button activated.
So let the menubutton set the active status only if the menu/popover
widget wasn't already shown, and ensure this doesn't get triggered by
double/triple button press events.
As an implementation detail, the popover hooks the fade out animation
on ::hide. Destroying the popover right away here is not a problem, but
prevents the animation from actually running. ::unmap will be run after
the animation is finished, so destroy the popover there.
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
gtk_scrolled_window_allocate_scrollbar was calling
gtk_scrolled_window_allocate_child just to get the relative
allocation, overlooking the fact that that function is only
safe to call if the scrolled window _has_ a child. Unfortunately,
gtk_scrolled_window_allocate_scrollbar will sometimes get called
when that is not the case. Since we are really only interested
in the relative allocation, just get that directly. This
fixes a segfault in the style-properties-nth-child reftest.
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
At the time of creating the indicator window, the scrollbar allocation is
poked and reused as the initial window dimensions. This usually happens
on two circumstances, either initially (so a ::size-allocate is emitted,
relocating the windows in the right places), or post-initialization when
calling set_overlay_scrolling() (so the scrollbars already have a valid
size allocation)
However, if the scrolledwindow is unrealized, and later re-realized again,
the scrollbars will already have a valid allocation, although 0,0 based
due to being contained in the previous indicator window. This comes out
wrong then, and the indicator window is given 0,0 based coordinates too.
Fix this by refactoring the scrollbar allocation code out of size_allocate,
and also use that given size at the time of creating the indicator windows,
this will provide the right widget-relative allocation anytime.
Currently, GtkGLArea will leak GError instances set during the context
creation, if an error is set.
If any error is set post-context creation, it should be displayed even
in the case a GL context exists; for instance, we can use the error
display facility for shader compilation errors.
Make that variable go from 0.0 to 1.0 where 0.0 means inactive (slider
is on the left) and 1.0 means active (slider is on the right).
The math is simpler that way and most importantly the value is
independent of size.
Add a button to allow restricting search to the current
folder (and subdirectories). This makes the search more
useful, and makes the file chooser more similar to
nautilus.
In search, we show files from differnt locations, and it makes
sense to show where they come from. This makes the file chooser
more similar to nautilus, too.
Folders that show up among search results were unexpectedly
returned even for GTK_FILE_CHOOSER_ACTION_OPEN. Change things
around so that we switch to the folder instead, which is the
behavior we had in GTK+ 2.x.
https://bugzilla.gnome.org/show_bug.cgi?id=744204
