1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
on the children to be removed. In the rare cases where it might be needed
the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781
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
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
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
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
When aiming for the thumbnails with the mouse one might cross an
icon by accident which causes the thumbnail list to be closed, which is
frustrating.
Fix this by delaying the icon activation when the thumbnail list is
open.
https://bugzilla.gnome.org/show_bug.cgi?id=636650
With general support for swipe-scrolling in the overview, there is
no reason to limit the behavior to workspaces. It is equally useful
for scrolling through the grid of available applications, so enable
swipe-scrolling for the app view.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
The workspaces view allows to drag the active workspace to swipe-scroll
to the next or previous workspace. While this behavior can come in handy
in general, there are good reasons to move the functionality to the
overview:
- Finding a spot on a workspace to start a drag can be hard,
especially when the workspace contains a single window
- With the new layout, workspaces have no visible border, making
it hard to predict where a drag can be initiated
- The same behavior is equally useful for other elements
So add setScrollAdjustment() to the overview, which allows setting
an adjustment controlled with swipe-scrolling (either horizontally
or vertically); only a single adjustment can be controlled at a
time. A swipe-scroll can be initiated on any part of the background that
is not occupied by a reactive actor. For cases where further control
is needed, 'swipe-scroll-start' and 'swipe-scroll-end' signals are
emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=635034
Introduce a generic framework for on/off indicators that are shown
in the panel, next to the system status area, and use it for
showing the status of modifier keys.
https://bugzilla.gnome.org/show_bug.cgi?id=600771
Drag monitor functions are supposed to return a value, but
_onDragMotion() does not always do so. Add the missing return
value and remove unnecessary else.
As Gdk.Device.get_state() does not work properly from Javascript,
we used to block it in the environment. The method now has been
annotated with (skip), causing shell to crash on startup as only
existing methods may be blocked.
Just remove the block in question, as the annotation prevents the
use of that method anyway.
Currently we reset the timeout on every mouse movement which means
the user has to keep the mouse at the exact same position for 1.25
seconds.
Be more tolerant and allow the user to move the mouse over the
window without reseting the timeout, which should make activating
windows easier.
https://bugzilla.gnome.org/show_bug.cgi?id=638896
This fixes the problem of chat notifications collapsing and then expanding
again when receiving multiple messages in the expanded new notification.
https://bugzilla.gnome.org/show_bug.cgi?id=629557
g_settings_schema_new() aborts if the requested schema is not found,
so the previous approach of handling the case of unstable nautilus
not being installed did not work.
Instead, remove the use of the setting altogether - the original intent
was to not have separate items for Desktop and Home in the places
section if the nautilus key was set. As the section has been removed
anyway, the impact of always adding the desktop folder is minimal
(e.g. searching for "desktop" will match the desktop folder even
if it's set to the home folder).
