Work around this by introspecting gtkclipboard.c and gtkdnd.c instead
of the quartz alternatives.
Note that this is temporary: The implementation of GdkSelection
will make the quartz alternatives unnecessary. See bug 571582.
Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.
GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).
GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings. Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.
GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel. It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.
Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal. The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget. Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems. Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.
This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
GtkPixelCache is a helper utility that lets you implement
faster scrolling of a viewport of a canvas by using an
offscreen pixmap cache.
You call _gtk_pixel_cache_draw with a callback function that
does the drawing, and additionally you specify the size and the
position of the viewport in the widget, and the position and size
of the canvas wrt the viewport. The callback will be called to
draw on an offscreen surface, and the surface will be drawn
on the window. The next time you do the same, any already drawn
pieces of the surface are re-used from the offscreen and need
not be rendered again.
If things inside the canvas change you need to call
_gtk_pixel_cache_invalidate to tell the cache about this.
Some other details:
* The offscreen surface is generally a bit larger than
the viewport, so scrolling a small amount can often
be done without redrawing children.
* If the canvas is not larger than the viewport no
offscreen surface is used.
GtkPixelCache: Make sure we always copy using SOURCE
We were using OVER for the first copy (from source to group surface.
GtkPixelCache: Fix x/y typos
GtkPixelCache: Allow NULL for invalidate region
gtkpixelcache: Use CONTENT_COLOR for solid bg windows
The gtk-launch tool can be build without gio-unix (although it
will not really do much without an alternative implementation for
g_desktop_app_info).
So there is no need to not build gtk-launch anymore.
This reverts commit 9a1235bf0d.
https://bugzilla.gnome.org/show_bug.cgi?id=682824
Add separate GtkStack and GtkStackSwitcher widgets that are an
alternative to GtkNotebook. Additionally, GtkStack supports
animated transitions when changing pages.
These widgets were initially developed in libgd.
This is Tristan's *excellent* work, minus the old code for the shortcuts bar - that is all done
in GtkPlacesSidebar now.
The UI gets loaded from a Glade resource; most of the old code to create the UI by hand is gone.
There is still code for save_widgets_create(); this needs to be moved into the UI file, but it
is not a big deal.
gtk_file_chooser_default_init() calls a new post_process_ui() that takes care of all the things
that cannot be done directly in Glade.
Having the changes for composite widget templates makes it impossible
to merge the places-sidebar branch. So, we will merge that branch,
and *then* apply the changes for composite templates.
This reverts commit bf909f5615.
As the first composite widget in GTK+, this patch also
adds some Makefile mechanics to list the ui files as
dependencies of the global GTK+ resources, and adds the
initial test case where composite classes should be tested.
This catalog can be used to work with GTK+'s private widget types,
this patch exposes a private function gtk_glade_catalog_init() which
Glade will use for the sole purpose of initializing some private widget
types in GTK+ that are referenced from various GTK+ composite widget
xml files.
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
