The model_cancellables have an extra ref when we get them from gtk_tree_model_get().
So, we need to unref them always. On the other hand, the cancellables that get
passed as arguments to the callbacks in question are memory-managed by
GtkFileSystemModel.
Reported by Morten Welinder <mortenw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646460
Instead rely on state_flags & GTK_STATE_FLAG_INSENSITIVE to tell us if a
widget is sensitive.
This has the huge benefit that the way the widget is actually rendered
corresponds to the return value of gtk_widget_is_sensitive().
As a side effect, we do not ever allow unsetting the
GTK_STATE_FLAG_INSENSITIVE for a widget the is set to not be sensitive
(via gtk_widget_set_sensitive()). This way we stop propagation of making
stuff sensitive at insensitive widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=642918
This commit makes GTK_ALIGN_START/_END pay attention to
the text direction when used in horizontal context.
This is how similar parameters in GtkMisc and GtkAlignment work,
and is generally expected of GTK+ positioning parameters. And this
is new GTK+ 3 api, so it is basically still unused at this point.
If explicit right/left turn out to be needed at some point, we
can expand the enumeration with new values.
This code has been useless for a while, and now it's breaking things.
Moving the paned in tests/testheightforwidth's wrapping label shows that
bug.
Broken since 9992efdb0e
Use the _NET_SYSTEM_TRAY_ICON_SIZE property set by the tray mananger as
a hint that we should use a specific icon size. This allows the tray to
instruct us that it expects 16x16 icons, for example.
Bug #645232
Oftentimes we want to measure a layout that is as wide or wider than the
current layout's maximal width. In that case we can safely reuse the
current layout.
It's always FALSE.
Note that this patch changes the layout for allocations that are
smaller than 1px, but that's just the default layout that is never
rendered.
Async callbacks are delivered in idles, so we need to make sure
we get the gdk lock before calling any gdk/gtk stuff. This was
missing in a few places.
Dumps the widget path into a string representation. It tries to match the CSS
style as closely as possible (Note that there might be paths that cannot be
represented in CSS).
The main use of this code is for debugging purposes, so that you can
g_print() the path or dump it in a gdb session.
This ensures that widgets that aren't ported and rely on the style-set
signal being emitted work as well as before. They should not rely on
style-set being emitted however.
Note that this function is a no-op if the initial style has been set
already and is very cheap if it has not been set yet. It only becomes
relevant if the resulting style actually gets used.
https://bugzilla.gnome.org/show_bug.cgi?id=639584
The intention of this patch is to make the code clearer, shorter and
most of all to avoid recreating the widget path and setting it path
twice on the style context when the style context was recreated.
Now that we have wesome macros in glib 2.0, we can use them. Woohoo, GTK
2.0 will be so awesome in the future.
(Did anybody touch dnd code this millenium?)
This patch optimizes window resizes by assuming that if a widget
has the same height at a width of 50 as with a width of 150, the
height for width 100 will also be the same.
The patch also further optimizes the cache allocator, now there
are 2 pointer arrays of up to a maximum of 5 requests, the arrays
will only be allocated if a request is ever made in that orientation
and the array will be sparse until each request is made (i.e. if a
label can only wrap to 3 lines, there will only be 3 out of a
possible 5 SizeRequest structures allocated to cache it).
This patch makes contextual height-for-width request caching
optional (the contextual cache is not allocated for widgets that
report GTK_SIZE_REQUEST_CONSTANT_SIZE).
The constant size request mode defines a request mode where
height-for-width geometry is unneeded, thus optimizing GTK+
by reducing the overall amount of requests that need to be
performed and cached while resizing an interface.
gtk_settings_get_default() was used to monitor the
"gtk-application-prefers-dark-theme" setting, rather
than the GtkSettings object associated with the window's
screen.
Fixes Bug 639584 - initial emission of GtkWidget:style-set is
not happening.
GtkWidget was filtering out ::style-updated (and ::style-set)
emissions until the widget was realized in order to avoid often
useless updates during widget construction and placing.
This is now done instead until the widget has a parent/screen,
which ensures the initial emission happen prior to the first
size negociation, while still filtering out all early emissions
during construction.
You can select something, but moving the focus somewhere else, or bringing up
the context menu makes the selection go away. This makes it impossible to
copy-paste the text.
The reason for this regression is that gtk_label_state_changed was sloppy and
assumed that it would only ever be called when a labels goes insensitive, which
is no longer the case.
The patch fixes things by explicitly checking if the widget is insensitive, and
only resetting the selection in that case, which is the same behaviour we have
for e.g. GtkEntry.
It turns out the bug is more complicated than I originally understood.
Not replacing the font description fields while merging here makes it
impossible for application's CSS to override fonts.
This reverts commit 89c1d93b68.
https://bugzilla.gnome.org/show_bug.cgi?id=645458
Use the background color instead.
I think the optimal solution would be delegating the shadow rendering to
the theme completely, and removing this in GtkThemingEngine, but for
now, this simple fix makes the dark variant more usable.
https://bugzilla.gnome.org/show_bug.cgi?id=645405
