These widgets have ancestors other than GObject which could eventually
implement the notify vfunc for their properties. For correctness, they
should chain up the notify vfunc.
https://bugzilla.gnome.org/show_bug.cgi?id=673478
While shadow-type *properties* can make sense, to opt-out of the
padding/border machinery programmatically, having it as a style
property doesn't make any sense, since we have a better way to change
the bevel style from the theme already.
This commit deprecates the shadow-type style property in GtkToolbar.
This is a regression from commit
d0d21a4f00.
We are requesting the CSS padding twice: once unconditionally and
another time if SHADOW_TYPE != NONE, which is usually the case.
gtk_widget_path_copy() currently calls g_array_append_val() in a loop,
which is inefficient due to reallocating the array's memory. Calling
g_array_set_size() before entering the loop reduces the number of CPU
cycles used by roughly 30%.
Patch by John Lindgren,
https://bugzilla.gnome.org/show_bug.cgi?id=679978
The widget is already calling gtk_render_frame, but is not measuring css
border and padding when negotiating its size. This patch replaces the
already existing get_internal_padding static helper with a function that
sums the old internal-padding value with the values specified via css.
When the tab label gets removed from the notebook on widget
desctruction, we should still unconditionally unparent it from the
notebook, since failing to do so will keep a stray reference alive.
In case applications rely on the tab label being destroyed to release
other references (e.g. because the tab label is a custom object, or
another object's lifecycle is tied to it using g_object_set_data_full()),
this will also possibly cause other references to get leaked.
In Nautilus, the result was we were failing to release the reference to
a NautilusWindowSlot, and other parts of the application relied
on it being destroyed at a specific time instead, causing the
application to crash when closing a window.
This is a regression from commit
325cf071d1.
This commit restores the previous unparenting behavior in case we're not
in a DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=680349
We need to do this here so that an explicit gtk_widget_destroy
on either the widget or a container that holds it will kill the
reference to the menu or model.
https://bugzilla.gnome.org/show_bug.cgi?id=680803
We now support independent selection and primary clipboards, and avoid
wiping clipboard on modifying its contents from the same owner. This fixes
most of the interaction issues with clipboard and selection.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
GSequence iterators point at the position between two elements so an
iterator pointing at the N tree model node is actually between the N-1
and N sequence elements. This means that asking for the previous
sequence iterator first and then checking if it is the begin iterator
would yeld true for an iterator pointing at the 2nd tree model node
and make us return FALSE mistakenly.
https://bugzilla.gnome.org/show_bug.cgi?id=679910
This program launches an application specified by its desktop name
optinally taking list of URIs which are passed as arguments.
Uses GdkAppLaunchContext to get proper startup notification and
display handling for graphical apps.
https://bugzilla.gnome.org/show_bug.cgi?id=679342
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
