The official GNOME moduleset builds evolution and e-d-s against
GTK+-3, so libedataserverui-1.2 is no longer part of the release.
As GNOME Shell can actually be build with either version, prefer
libedataserverui-3.0 if it is available and allow falling back
to 1.2. if it isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=641085
In non-US locales, Monday is generally considered the first day
of the week. Take this into account when building the event
lists displayed under "This week"/"Next week".
https://bugzilla.gnome.org/show_bug.cgi?id=641049
Signed-off-by: David Zeuthen <davidz@redhat.com>
When the current day does not exist in the next/prev month (like 31 Feb),
the next/prev buttons end up skipping the month.
Fix that by going to the last day of the month instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641067
The default engine is now Adwaita in gnome-themes-standard, so
remove it from the moduleset. It has already been removed from the
gnome-suites-core-3.0 set.
There are multiple code passes that can result in Notification::destroy()
being called, such as a notification being closed by the application
when it exits and the associated source being removed at the same time.
However, we should only emit 'destroy' for the notification and
do the associated work once.
Notification::destroy() now takes 'reason' as an optional argument.
Calling Notification::destroy() directly when connecting to 'destroy'
on Source, as we did before, was inadvertently passing 'source' as an
argument to the function.
https://bugzilla.gnome.org/show_bug.cgi?id=640976
Due to recent GTK+ changes X11 specific code was moved into different
headers. As Socket/Plug is X11 only this broke our calls to GtkSocket
in the tray code. Fix this by including the new gtkx.h header.
This fixes emitting NotificationClosed for resident notifications
that are clicked, but are not actually destroyed.
This also ensures that we emit NotificationClosed in all cases when
a notification is destroyed, which can happen when:
- a non-resident notification is clicked
- an action is invoked on a non-resident notification
- an application the notification was associated with is focused
- a transient notification is done showing
- a notification was requested to be closed by the application
- a tray icon the notification was associated with is removed
https://bugzilla.gnome.org/show_bug.cgi?id=638071
Windows may change their size while the overview is open, e.g. when
switching panels in the control center. Make sure that the preview's
position and overlay are updated in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=640560
With the current rule set, we exclude applications in the "Core"
category - this includes Nautilus, which we want to show up at
least until "Finding and Reminding" is implemented, so remove
the exclude rule for now.
On button-release, a threshold is used to determine if the gesture
should be considered a click and thus ignored. While the drag is
active though, the controlled actor is dragged immediately. As a
result, dragging by a tiny amount does not trigger a snap back when
the action is interpreted as a click. As a fix, do not update the
dragged actor's position until the same threshold is passed.
https://bugzilla.gnome.org/show_bug.cgi?id=640494
The main overview group starts capturing events on button-press
events to implement swipe-scrolling. While reactive children of
the group which handle both button-press and button-release events
don't trigger swipe-scrolling, children that only rely on
button-release have stopped working - at least the primary/secondary
icons of the search entry are affected. While the capture handler
already checks the pointer movement between press and release to
determine whether the action should be considered a click rather
than a drag, it still blocks the release event from propagating.
Instead, only block release events for drag actions, but not for
clicks.
https://bugzilla.gnome.org/show_bug.cgi?id=640493
