GApplication now makes the session bus and object path available as a
public API on the application instance. Use that instead of trying to
guess values for ourselves.
This causes this version of Gtk+ to depend on GLib 2.32.2, so bumping
version dependency accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
The way we use these style properties to set regular properties on
containers accessible from the public API is really just broken, and
could lead to undefined values for the spacing and border-width
container properties (since they could be set from public API and then
changed from under in a style_update handler from GTK).
Take this as an occasion to deprecate these style properties, which do
not make a lot of sense anyway, now that GtkInfoBar supports regular CSS
padding and border.
GtkPlug directly handles X KeyPress/Release events, instead of using
translation in GDK (which expects XI2 events for XI2). When this
was done, the handling of the group was stubbed out and never replaced.
Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier()
so we can fill out the fields correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=675167
InfoBar must take into account the border and padding when requesting
its allocation, since it is then drawing them. Besides, the border and
background should always be drawn, even when the message type is OTHER.
These need to be made independent of the xkb configuration somehow.
As things are now, they will either fail when run on a naked X
server in make check, or fail when run in my session.
Shift-click in the slider now starts a drag in 'fine adjustment'
mode, where we move the slider 10-times slower than the mouse.
This can be very helpful when scrolling through a very long document
or webpage, and moving the scrollbar even a single pixel already
jumps too far in the content.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
It seems to be general consensus that button 1 should do the jumping,
so we now jump to the clicked position on primary button clicks and
page on secondary button clicks. Touch behaves like primary.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
Symbolic icons use a "-symbolic" suffix to distinguish themselves from
highcolor variants. Note that the dash character here has a different
meaning than the specificity level defined in the icon-naming-spec [1],
as it identifies a property of the icon itself.
Since they might be provided by a parent theme (e.g. the HighContrast theme
relies on the gnome icon theme for them), when we are looking up one we
should first escape the generic icon inheritance mechanism defined in the
icon-naming-spec [1], and privilege a symbolic icon, if it exists in a
parent theme, before applying the inheritance evaluation.
This fixes symbolic icons not working properly when used in the
HighContrast theme with the GTK_ICON_LOOKUP_GENERIC_FALLBACK flag set.
[1]
http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=674806
Avoid doing useless translations/rotations, since themes will most
likely set different CSS gradients using left/right/top/bottom style
classes, or use a plain color.
https://bugzilla.gnome.org/show_bug.cgi?id=674809
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
Instead of overriding the font theme settings, just set the Pango
attributes we want on the label. This fixes message dialogs growing on
style_update after recent GTK+ changes.
Instead of using 1 global queue for both resizes and style validation,
use 2 queues. This makes the code a lot simpler and fixes a bug where we
could accidentally stop restylying for very delayed restyles.
We now animate the core style information (see comment in
gtk_style_context_save()). A lot of widgets save + set custom style
classes/states during drawing and so can't be animated. It does work for
labels, menus and buttons though.
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.
