The code that was trying to limit preview size changes was
running into some width-for-height pitfalls. It turns out
that the dialog behaves quite ok without this code, so just
remove it.
Now that filters may affect sensitivity of rows, we need
to clear the sensitivity column from the cache when the
filter changes. This fixes the problem where selecting a
different filter does not update the sensitivity of folders
until you change directories.
This way we remove paired function calls (compute/set pairs), and also make
it possible to avoid computing a filter twice, as setting the visibility
depends on filteredness.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This was a copy-paste leftover from node_set_visible(). Filters are not
concerned with model freezes, so node_set_filtered() does not
need to handle freezes, either.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Specially in the case of comboboxes, those menus could enable scrolling
even if the contents could fit in the work area, and could show blank
space in order to line up the selected item with the combobox.
When such thing happens, take into account scroll_offset when relocating
the menu contents so contents don't jump directly onscreen, and apply
it so scrolling is allowed in the direction that brings the menu onscreen
and blocked in the opposite direction.
Also, wait for cancelling the scroll operation until the touch is released
even if the scrolling arrows disappeared, so the menu item underneath isn't
selected right away.
https://bugzilla.gnome.org/show_bug.cgi?id=678113
Entries don't expand vertically if they are given pixbufs larger
than the calculated height for the current font, resulting in
cropped icons, so force the pixbuf to be rescaled so it fits
on the entry allocated size.
https://bugzilla.gnome.org/show_bug.cgi?id=678087
If the symbolic icon has other size than 16x16, the embedder
SVG that overrides colors would still force that size, resulting
in clipping instead of resizing. So fetch the original pixbuf
size the first time a symbolic icon is requested for a GtkIconInfo,
and use that size for the embedder SVG so it can be scaled properly
afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=677567
Both GtkListStore and GtkTreeStore had a few methods that allowed
-1 to mean 'append' when specified as a position, but others that
demanded positive position arguments. Make this consistent by
always allowing -1.
https://bugzilla.gnome.org/show_bug.cgi?id=667808
The recently-used.xbel storage for recently used files is located inside
the $XDG_DATA_HOME directory; there's no actual guarantee that the
directory has been created already, even though it's very highly
probable on any modern distribution. We should create it, along with its
intermediate parents, before constructing the file monitor that we use
to get change notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=671817https://bugzilla.gnome.org/show_bug.cgi?id=667808
nitems is never guaranteed to be defined in sys/params.h as it is meant
to be defined within a protected ifdef __KERNEL conditional.
Use G_N_ELEMENTS from GLib which is the proper way of doing this.
In gtk_entry_get_icon_pixbuf() we unreference the pixbuf that
_gtk_icon_helper_ensure_pixbuf() gives us back, since the function
doesn't return a reference, and by doing so we're able to return the
reference owned by the cached icon helper.
Since the icon helper method can return NULL though, if no icon
properties have been set on it, guard for != NULL before unreffing the
pixbuf, as that would cause a critical warning.
https://bugzilla.gnome.org/show_bug.cgi?id=679537
Right now, when we create a GtkModelMenu for a GMenuModel, we listen to
changes to the menu's attach-widget to detect when a toplevel
GtkApplicationWindow becomes available to fetch actions from it.
This unfortunately breaks this simple code:
GtkWidget *application_window = gtk_application_window_new();
GtkWidget *menu_button = gtk_menu_button_new();
GMenuModel *menu_model = get_menu_model();
gtk_menu_button_set_menu_model(menu_button, menu_model);
gtk_container_add(GTK_CONTAINER(application_window), menu_button);
Since GtkMenuButton creates a GtkModelMenu and sets itself as its attach
widget before it's added to a hierarchy containing a
GtkApplicationWindow.
Fix the bug by simply listening for changes in the window hierarchy, and
creating the menu model when the attach widget is added to an
application window.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
When the menu is detached, the attach-widget property changes value to
NULL, so we should notify a property change, like
gtk_menu_attach_to_widget() does.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
This is fallout from commit 257b42e2f9 -
those fields were already getting freed in
gtk_application_shutdown_x11() and my commit caused crashes on quit
instead.
Thanks to Rico Tzschichholz for reporting the bug and testing this fix.
As an addition to 1042372670, themes might
want to avoid using the hardcoded GTK defaults for legacy GtkStyle
values. Add a gtkstyle-fallback style class that can be used by themes
to tweak the legacy GtkStyle defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=679092
Since we explictly call popup_menu with NULL when it's
keyboard-activated, we need to be careful and not access event->device
without checking for event != NULL before.
The signals for the action group were being disconnected when the action
group was explicitly removed from the GActionMuxer but the same was not
being done when it was finalized.
This means that a change in the state of an action group that used to be
associated with a finalized GActionMuxer would result in a crash. This
would happen for stateful application actions after closing a window.
We can't expose colors with alpha in the GtkStyle colors, since
GdkColor has no alpha. Currently we throw away alpha completely,
which fails very badly for completely transparent backgrounds,
which now is the default for most widgets, as it typically
end up with black-on-black.
We handle this by falling back on the default/previous colors for
transparent colors. This is is simple and avoids complete failure.
https://bugzilla.gnome.org/show_bug.cgi?id=671437
