Make GMountOperation look for an owner of org.Gtk.MountOperationHandler
if possible, and use it instead of the GTK-based dialogs.
This allows applications to use the implementation offered by the
desktop shell, if available, through a DBus private interface:
org.Gtk.MountOperationHandler.
https://bugzilla.gnome.org/show_bug.cgi?id=674963
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
Makes name consistent with other quartz-only modules and makes it clear that this works with the GMenuModel system rather than the older GtkMenu system.
This is a GtkCssComputedValues subclass. So it's essentially a store for
computed CSS values. But it can be animated by advancing it to a certain
timestamp.
A StyleAnimation is an immutable object used to track the state of CSS
values. I'd have liked to make it fully immutable - ie not have the
timestamp in there - but couldn't find a place to sanely store the
timestamp.
This is an abstract base class. Implementations for this will be added
later (for both CSS3 transitions and animations, potentially for
animated images).
Actually aplying the information in this object will be done by a
different object commtted later.
... and Make this new value be a real GValue, as we don't need to save
performance for these anymore (it's just used for custom properties).
And I'd rather have code work for all values then be optimized for no
reason.
Deprecate public API where appropriate and make it no-ops.
Remove all calls to it.
Get rid of the 'transition' css property.
For now, this means spinners don't animate anymore.
Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
This way, we don't have to do magic inside GtkStyleContext, but have a
real API.
As a cute bonus, this object implements GtkStyleProvider itself. So we
can just pretend there's only one provider.
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
This does nothing but turn all GtkBitmask functions into static inline
functions that call the gtk_allocated_bitmask_*() equivalent.
The implementation of the static functions has also been put into a
private header, to not scare people who want to see how things are
implemented.
It was problematic to maintain Raleigh going forward, as any
changes in it affected all themes. Also, its more robust if
each theme is a full standalone css rather than relying on
an inherited css base.
So, this changes Raleigh to a standalone theme that we can tweak
without accidentally breaking other themes, and makes the
default theme empty. In fact, we don't even add the default
provider anymore as its always empty.
