This test can put text, images or data content on the clipboard
and receive such data as well. Button sensitivity is updated
based on the availability of suitable clipboard content.
This commit makes GDK send clipboard-related events to the
GdkClipboard implementation first, before converting them
to GDK events and sending them up. This will let the old
clipboard implementation continue to work until it is no
longer needed.
This is a local-only GdkClipboard implementation. It is useful for
test purposes, and as a fallback for 'primary' on platforms that
don't have a primary clipboard.
This commit adds a GdkClipboard object which is intended to
replace GtkClipboard, eventually. Currently, it supports setting
text, pixbufs and general data with mime types.
Previously GtkMenuTracker tried to access "gtk_menu_tracker_item_get_is_visible",
but the correct getter is "_gtk_menu_tracker_item_is_visible". This commit
corrects this reference
https://bugzilla.gnome.org/show_bug.cgi?id=731430
Since large images are in the icon cache, and apps don't tend to use that
many icons anymore, simply don't include image data and instead make apps
load files from disk. Additionally, since they're stored in GdkPixbuf data,
that means that we have to first convert them either to a cairo_surface_t,
which requires converting pixel data to be premulitplied, or an OpenGL
texture, which requires a whole GPU upload anyway.
So, even with the icon cache, the goal of icons through zero-copy, mmap()'d
data from disk just isn't doable with the icon cache format we have. The
icon cache on my disk is nearing 100MB, since we include a bunch of
high-resolution application icons, that I doubt would be used by apps at all.
Removing this inefficient pixel data makes memory usage for all applications
go down, with no speed loss.
The icon cache also, however, has an index of what icons are in each folder,
which prevents a readdir() and allows GTK+ to know what icon is where without
having to do a bunch of stat(); calls. Keeping this data is good for GTK+,
so we should still keep the index.
It doesn't make sense to remove any code for mapping pixel data from the icon
cache. There's a plan in the works to have a symbolic icon cache that does
pixel math on 16x16 icons to prevent slow SVG rendering. 16x16 pixels are
fairly small, and such images are flat colors, which should compress easily,
so the icon cache would be worthwhile here. So let's keep the code around
in preparation for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=721895
This changes makes svg icons go through the same scale calculation
code as png icons. As a consequence, an svg that is put into the
32x32 directory will actually be loaded at size 32, even if it
gets requested at a bigger size. This will let us avoid giant
spinners.
https://bugzilla.gnome.org/show_bug.cgi?id=731658
Having the same, usable, default appearance acroll platforms
trumps having a more-or-less working native theme. The default
will be Adwaita on all platforms. The native ms-windows theme
is of course still available.
Making gtk.gresource.xml generated was causing a problem for
srcdir!=builddir builds from git. Builds from tarballs are
not affected, because the tarball contains the generated file.
