Matthias Clasen [Mon, 4 Feb 2013 05:59:14 +0000 (00:59 -0500)]
Remove a no-op AtkAction from GtkRange
The "activate" action here did not do anything.
It is possible we actually want to have some actions here,
like "step-up", "step-down", "page-up", "page-down", etc.
For now, just remove the AtkAction implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=553334
It turns out that we just started using AX_PROG_CC_FOR_BUILD, which
for some reason requires AC_CANONICAL_TARGET. That seems wrong to
me, but for now, lets just keep using it.
This autoconf macro should only be used for building compilers
(or compiler tools) for a specific target. The current effect of
it in GTK3 is that it causes various executables like gtk3-demo
to be prefixed with $target- when the --target configure flag
is set or when cross-compiling. When cross-compiling GTK3 on
Linux for the Win32 target this causes the gtk3-demo binary
to be named i686-w64-mingw32-gtk3-demo.exe instead of just
gtk3-demo.exe (like it was before commit 53083ea7b423482b)
Cosimo Cecchi [Fri, 1 Feb 2013 16:03:44 +0000 (17:03 +0100)]
scrolledwindow: make gtk_scrolled_window_add() smart
There's really no reason why we shouldn't automatically create a
GtkViewport when the widget added to GtkScrolledWindow is not a
GtkScrollable, instead of just printing a g_warning.
Copy the viewport special case into the scrolled window implementation
of gtk_container_add().
Benjamin Otte [Sat, 2 Feb 2013 00:42:04 +0000 (01:42 +0100)]
cssimage: Only load image data when needed
Saves ~6MB of memory per application in the Adwaita I am using - at
least until the app starts using all the images in the theme, because
the code doesn't discard images yet once they were loaded.
Benjamin Otte [Fri, 1 Feb 2013 22:15:27 +0000 (23:15 +0100)]
css: Split out GtkCssImageSurface
This is essentially a GtkCssImage for a cairo_surface_t and is a pretty
much straight up copy of GtkCssImageUrl. But we want to implement lazy
loading and animations, so GtkCssImageUrl is going to gain new
features...
Benjamin Otte [Wed, 2 Jan 2013 14:27:00 +0000 (15:27 +0100)]
cssimage: Store the URI we're loaded from
I'd like to use it when printing the value, but I haven't found a way to
do that sanely yet, as I'd need to be able to print relative paths for
make check to work (otherwise the srcdir would blow things up). And we
use a GString to output to, so there's no way to attach a base dir to
that.
If anyone has an idea how to achieve that, poke me. Having the real
filename in debug prints sounds like a very good idea to me.
Cosimo Cecchi [Fri, 1 Feb 2013 10:10:23 +0000 (11:10 +0100)]
tree-view: add back gtk_style_context_set_background()
Commit ddceddaa84222f3f2b40fe5ce3b04dc7ddf6cace removed the call to
gtk_style_context_set_background() in favour of always rendering it with
gtk_render_background() during the draw vfunc.
This has the side effect of making the backing window always
transparent, which blocks GTK from applying some optimizations during
the paint cycle. The result is that, especially in clutter-gtk
applications, scrolling performance gets really bad.
This commit partially reverts ddceddaa84222f3f2b40fe5ce3b04dc7ddf6cace
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called
Cosimo Cecchi [Fri, 1 Feb 2013 09:30:57 +0000 (10:30 +0100)]
icon-view: add back gtk_style_context_set_background()
Commit da09447914c0919362533182261a2c862ac8de81 removed the call to
gtk_style_context_set_background() in favour of always rendering it with
gtk_render_background() during the draw vfunc.
This has the side effect of making the backing window always
transparent, which blocks GTK from applying some optimizations during
the paint cycle. The result is that, especially in clutter-gtk
applications, scrolling performance gets really bad.
This commit partially reverts da09447914c0919362533182261a2c862ac8de81
and changes the code so that both gtk_style_context_set_background() and
gtk_render_background() are called.
treednd: Remove (out) annotation for GtkSelectionData arg
gtk_tree_drag_source_drag_data_get's GtkSelectionData argument should not be
marked as (out) because:
a) GtkSelectionData is semi-private (it's declared in gtkselectionprivate.h),
and thus gobject-introspection has no knowledge of its fields or its size.
There is thus no way for language bindings to allocate GtkSelectionData.
b) Even if it was possible for language bindings to allocate GtkSelectionData,
a zeroed-out instance thus created would not be usable with
gtk_tree_drag_source_drag_data_get. As far as I can tell, you need to
initialize its "target" member to the GdkAtom of "GTK_TREE_MODEL_ROW".
Language bindings have no way of knowing this, of course.
Since XIQueryVersion, the bad API that it is, enforces the version from
the first client that requests it, for clients to be able to use the new
features in XI2.3, we need to ensure that we pass XIQueryVersion 2.3 as
the version that we support. We know that GTK+ won't be confused by the
new features.
The X server should fill in the minor version that it supports in the
case where it only supports the older version, so we can safely always
pass a higher version number than is potentially supported by the
server.
libXi was designed to be stable in the case where it doesn't recognize
requests or events/replies, so this should still work in a case where
we have new versions of the X server, and GTK+, but an old version of
libXi, at least for however well that setup should work.