Allow defining a "porthole" that is the visible area of a workspace
thumbnail, and use this to clip the portion under the panel off the
workspace thumbnails. (This is wrong for fullscreen windows, but not
very wrong, and hopefullly the few missing pixels will be
unnoticeable.)
https://bugzilla.gnome.org/show_bug.cgi?id=641880
Because the overall parent allocation width immediately when the workspace
count changes, we were sometimes drawing the indicator in the wrong place
in the indicator animation that proceeded the remove-workspace animation.
Fix this by tweening only the Y position of the indicator and computing
the X position and size in our allocate() method. This also is considerably
simpler than switching the indicator between fixed position and geometry
managed.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
Rather than killing the workspace indicator indicator when we remove
workspaces because the source and target locations might have changed,
do it as a separate first step. This provides a better explanation
than doing it simultaneously with the addition/removal or not at all
and also keeps our computations simple.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
When we animating the scale for the thumbnails, the border and
background should wrap around the current size of the thumbails.
The technique that we are using to animate the scale breaks that
since we don't animate the overall size of the thumbnails box -
we just animate our child actors within the allocation.
To fix this, switch from drawing the background by packing in another
container to drawing the background with a separate actor that
is under the other actors and allocated by our custom logic.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
To explain to the user what is happening, instead of abruptly changing
updating the workspace thumbnail list, slide thubmnails in and out
as they are added and removed.
To implement this, we track a state for each thumbnail and when things
change go through a process of first sliding removed thumbnails out,
then ollapsing the left-over spaces and rescaling the thumbnails, then
finally sliding newly added thumbnails in.
https://bugzilla.gnome.org/show_bug.cgi?id=641881
For historical reasons, StEntry always did hover tracking when you had
visible hint_text, even if track_hover was FALSE. Remove that special
case, and make entries track hover just like all other widgets do.
If we actually needed to distinguish hovered-with-hint-text from
hovered-without-hint-text (which, at the moment, we don't), we could
do that by setting separate CSS for :hover and :hover:indeterminate.
https://bugzilla.gnome.org/show_bug.cgi?id=642483
The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
The setting in org.gnome.desktop.default-applications.at
has been removed, use the corresponding setting in
org.gnome.desktop.a11y.applications instead.
If you left the overview immediately after entering it (either
intentionally or due to a bug), the app menu would mistakenly end up
hidden due to flaky interaction between its show() and hide() methods.
Based on a patch by Dan Winship <danw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=641117
When we have more thumbnails than can fit in the vertical space, scale
them down. This is implemented by using a generic container so we can
compute positions and sizes on the fly and do the appropriate
width-for-height behavior.
The usage of clutter constraints to position the indicator is droppped
since it less complicated to just position the indicator in the right
place ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The scale we zoom to in the "zoomed out" mode depends on the width of the
controls area. Once we rescale the workspaces dynamically, we'll need to
update the zoom scale as we add and remove workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
We will change the workspace thumbnail size as we get more thumbnails; it doesn't
really make sense to always show 1/5 of the thumbnails how big or small they are,
so instead show a CSS-configurable length.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Fix a bug in the computation of the zoomed-out scale and use a StBin
instead of an unnecessary StBoxLayout. Using the StBin will allow
correct width-for-height behavior for the controls.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
Add WorkspaceThumbnail.ThumbnailsBox to handle managing the array
of workspace thumbnails; the logic will get more complex as we add
scaling and animation.
https://bugzilla.gnome.org/show_bug.cgi?id=641879
The settings in org.gnome.desktop.default-applications.at
have been removed, use the corresponding settings in
org.gnome.desktop.a11y.applications instead.
gsettings-desktop-schemas had two conflicting settings for showing
the magnifier: 'show-magnifier' in org.gnome.desktop.a11y.magnifier
and 'screen-magnifier-enabled' in org.gnome.desktop.a11y.applications.
The former has been removed in favor of the latter, so adjust to this
change.
Add the machinery to cancel the notification when a new playing a
new one (wrapping ca_context_cancel), then use it when scrolling
the status icon.
Not doing it for the slider because it causes noise, either with the
keyboard, with mouse drag or with mouse wheel.
https://bugzilla.gnome.org/show_bug.cgi?id=633667
The original icon doesn't exist, which results in empathy summary
items in the tray showing no icons (invisible) at all. With this fix
users can now at least see where the icons are (they are no longer
invisible).
https://bugzilla.gnome.org/show_bug.cgi?id=639468
As Main.overview is now usable from the view selector's constructor,
move the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
To enable find-as-you-type when entering the overview and disabling
it when leaving, we used a chain of functions calls from ViewSelector
over SearchTab to SearchEntry. As find-as-you-type should be enabled
while the overview is shown, the activation/deactivation can be
handled entirely by the SearchEntry itself by tying it to the entry's
visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
As Main.overview is now usable from the dash's constructor, move
the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
The Overview does not only hold the different elements visible in
the overview, but is also a central point to manage drag signals.
As objects which are constructed in the overview constructor cannot
access Main.overview (as its constructor has not finished yet), we
use misnamed show/hide methods to work around this limitation, which
are called when entering/leaving the overview.
A better way to handle this problem is to remove the limitation
altogether by splitting the overview constructor between internals,
which remain in the constructor, and more complex objects which
need to access Main.overview, and whose initialization is moved
to a public init() function which is called by main.js after the
overview has been constructed.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
This patch fixes the summary notification reappearing if you click on the
summary item to hide it and hover away. It also ensures that when you click
on any summary item which doesn't correspond to the summary notification
being shown, a new summary notification will replace it right away.
What used to happen is that we'd unset the clicked item in _unlock() that
was called when the focus was ungrabbed because the user clicked outside
of the summary notification, but then would have this._clickedSummaryItem
be null in _onSummaryItemClicked() , and set it to the clicked item all
over again. This patch ensures that we unset the clicked item only when
it is necessary.
We also needed to add the code to call _updateState() again to show a new
summary notification when a previous one was hidden, but
this._clickedSummaryItem was set.
https://bugzilla.gnome.org/show_bug.cgi?id=642005
Follow-up to commit 09717aae58 so
title changes also support markup instead of the ugly "<i></i>"
status.
Additionally, make sure to escape the contact's title as that
may accidentally contain unsafe markup or characters.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
We were adding pango markup to the message in ContactManager.setPresence,
but weren't correctly marking the message as containing pango markup,
allowing for uglyness such as "User is <i>away</i>." being shown to the
user.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
As the dash is one of the primary drop targets for dragging application
launchers, it's reasonable to use the dash icon size for app icons'
drag actors, especially with the larger size now used in the application
view.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
As elements in the dash are scaled to accommodate a growing number
of items, the icon size used may end up rather small. In that case,
dragging items to the dash which are significantly larger than items
in the dash is getting clumsy, so it makes sense for some components
to synchronize the size of drag actors with the currently used icon
size in the dash. To enable other components to do this, make the icon
size a public property.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
- Center the icon texture in the area allocated for it, and always give
the nominal size - avoid off-by-one scaling if the parent allocated
a little less or more size than we wanted.
- Use Math.floor() when centering horizontally to avoid allocation
at a half pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=642124
Make calling workspace.setReservedSlot(null) do nothing if the slot was
already null; this improves efficiency and more importantly chills out some
weird reentrancy at the end of drag and drop that removes a window from
a workspace.
We were properly accounting for the fact that an ancestor of the
parent could be scaled rather than the parent itself when computing
the snap-back scale, but directly using parent.scale_x for the
snap-back location.
https://bugzilla.gnome.org/show_bug.cgi?id=642117
A right click was propagating through to the parent actor meaning
that a right click would activate the workspace twice and leave the
overview instead of just switching to it.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
If you want to select a workspace and go there, having to go back to
the main part of the window selector and click on a window is annoying,
so make a second click on the active workspace go to the main view.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
Some recent painting-efficiency fix broke the inspector, which
accidentally depended on things getting repainted too often, and so
was failing to highlight things properly now. A simple queue_redraw()
fixes this, but while I was there, I decided to port the drawing hook
to JS as well, since all the necessary parts of cogl work fine from
JS.
https://bugzilla.gnome.org/show_bug.cgi?id=642058
That way it can be used when other components of the message tray need to
grab focus, such as the summary bubble with multiple notifications or the
summary item's right click menu.
https://bugzilla.gnome.org/show_bug.cgi?id=641810
The view might get mapped before the filters have been added, so
trying to reset to the "All" filter will throw an exception. Fix
by only do the reset if the filters have been initialized.
When switching to the app view, it is unlikely that a user is
going to select an application from the same filter list as the
last time the view was used, so reset the view to the "All" filter
on switch.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
When switching to the application view, the view is still scrolled
to the position it had when left previously. Given that it is rather
unlikely that the application the user wants to select is located close
to that position, it appears beneficial to start at a predictable
position, so make sure that the scroll position is always reset to
the top.
https://bugzilla.gnome.org/show_bug.cgi?id=641987
The default state of the switcher is constructed but not visible,
so create it that way.
This fixes a bug where if we created the switcher but didn't show it
or use it we'd end up with an empty, odd looking switcher.
We already skip animations for item additions/removals while the
overview is hidden or when initially filling the dash (to avoid
an odd zoom effect when showing), apply the same logic to animations
of icon size changes.
If a window is closed, the list of running applications may change
while the overview is hidden. Animating dash changes is pointless
in this case, so update the dash without animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The dash is created empty and the initial set of items is added
before it's shown for the first time. As the additions of items
is now animated, this results in a slightly odd effect when all
items zoom in at once. So special-case the first time _redisplay()
is called and skip animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
In general, all changes in the shell interface should be backed
by animations to give the interface a more natural feel and provide
feedback of what's happening. Currently the dash violates that
principle, as items simply appear/disappear or change size abruptly,
so add animations for application list and icon size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Clutter containers only take their children's size into account, but
not their scale. As we want the dash to change its size smoothly
when zooming items in/out, we wrap each item in a custom container
which does consider the child's scale.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
When the list of applications in the dash changes, all items are
removed and new ones added. While this approach is nice and simple,
it does not work if we want to animate changes. So rather than
replacing the old list of applications with the new one, figure
out the changes and only apply those.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Previously the icon size was only adjusted due to changes in the list
of application icons displayed, not when showing or hiding the remove
target. As a result, the remove target could end up cut off, so take
this case into account and adjust the icon size when showing or hiding
the remove target.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The current approach to adjust the icon size of dash items is rather
expensive: the size of each item is changed from largest to smallest,
until the height of the dash fits the maximum available height, so
quite some ClutterTextures are created and disposed.
A better approach is to calculate the required size beforehand and
only change the icon size when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
With the current dash layout of a single column, nearly every icon
label ends up ellipsized, even at the largest allowed icon size.
Not showing any labels appears to be the cleanest approach in this
case, so disable them in the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Currently there is a serious problem with ellipsization in various
parts of the overview. While wrapping the label or giving it more
space may be appropriate approaches for the application view, neither
works very well for the dash - possibly the best option there is to
not show the label at all.
So add a constructor parameter to BaseIcon to allow hiding the
label.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
With workspaces now being stacked vertically, the horizontal
indicators in the workspace switcher are rather odd. There are
some designs for an improved workspace switch animation, but
it may take a while to implement them, so for now just change
the orientation of the existing switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=641931
Point the arrow to the center of the sourceActor's content box, rather
than its allocation, in case it has asymmetric padding (as the
rightmost message tray summary item does).
https://bugzilla.gnome.org/show_bug.cgi?id=641728
Commit c86a977564 removed :pressed from the list of styles which
highlight panel buttons, so the button highlight is now lost when
mousing over menu items. This is not the behavior we want, the
buttons should keep their highlight while being "active". Rather
than adding back the pseudo class to the CSS, let buttons use the
:active pseudo class when the menu is open, which makes more sense
than :pressed anyway.
The status icon should always be visible if more than two layouts
are configured. The settings key which was used to enforce hiding
the icon in this case as well has already been removed from the
g-s-d schema, causing an error on startup.
Intead of using a St.Group and tweening the position of the controls
actor, use a St.GenericLayout and tween a Javascript property. This
allows us to more reliably track the height of the overall workspace
display and propagate it to the controls actor.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With workspace thumbnails, we don't switch workspaces when dragging windows
between workspaces or adding new workspaces, so we also shouldn't switch
on launch.
* Add workspace parameters to shell_doc_system_open(),
shell_app_activate, shell_app_open_new_window()
* Pass a 'params' object when activating items in the overview with
two currently defined parameters: workspace and timestamp. (timestamp
is only implemented where it is easy and doesn't require interface
changes - using the global current timestamp for the shell is almost
always right or at least good enough.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
At the end of a drag operation, we would invoke the code to slide the
controls in (because we were no longer DND'ing and not hovering) and
then immediately afterwards invoke the code to slide it back out when
we got the ENTER event from the end of DND. While the immediately
overridden tween probably won't have any visible effect it's better
to avoid this, so wait to update the zoom state until BEFORE_REDRAW.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With automatic workspace management, explicit controls to add and
remove workspaces are no longer necessary. We also can remove the
use of addWorkspace for middle-button-click on a launcher since
launching on the last empty workspace will do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
With workspace thumbnails, we want to make workspace switching
something that happens largely under the users control, so don't
switch to newly added workspaces in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Add workspace thumbnails to the workspace controls area. The user can
click on the thumbnail to switch workspaces and can also drag windows
out of the thumbnail to other workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Moving the base tracking of restacking to WorkspacesDisplay will allow
us to use it to update stacking in the workspace thumbnails as well as
in the main workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
Instead of having a separation between popping the controls out on hover
and zooming out for DND, always do both at once. This is necessary because
when we added workspace thumbnails the controls will get bigger, so we need
to make sure we zoom out far enough so that the windows don't overlap the
controls.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
The new plans for a row of workspace thumbnails on the right side of the
overview means that the mental model we present to the user will be
vertical, so switch the Metacity workspace layout to be vertical and
adjust the keybinding handling, animations, and workspace layout in
the overview to match.
(This commit does not change the workspace switching indicator pending
finalization of what we want to do with that - it still shows workspaces
arranged vertically.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
St.Button 'clicked' signal now has two arguments, and because we are also
passing an action id as an argument to the _onActionInvoked() callback,
we need to have the number of the signal arguments reflected accurately in
the function arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=641809
This makes the animation feel more stable and keeps the left-most item expanded
when you move the mouse to the left in the tray.
The following behavior details are implemented by this patch:
- we wait to collapse an expanded item till after the tray is hidden if
we are hiding the tray
- we don't collapse an expanded item if the summary notification associated
with it is being shown, unless a different summary item is hovered over
- we don't consider the mouse hovering over a summary notification as
hovering over the tray, which allows us to collapse an expanded summary
item if it is not associated with the summary notification being shown
https://bugzilla.gnome.org/show_bug.cgi?id=636930
For historical reasons, we had both StClickable and StButton, which
were nearly identical. StButton was more widely-used, so keep that and
port all StClickable users to that.
https://bugzilla.gnome.org/show_bug.cgi?id=640583
It doesn't currently work, so hide it for now.
It's not clear it's going to stay around long term,
anyway. If it doesn't we can delete the code, then.
Otherwise, we can add the code back when we have
something that works.
https://bugzilla.gnome.org/show_bug.cgi?id=636680
Commit 91d8a32f25 let WindowClone forward the size-changed signal
of the "real" window, disconnecting the signal handler when the
clone is destroyed. In case the clone was destroyed due to the
MetaWindowActor being closed, this results in a warning
(gsignal.c:2392: instance `0x2a3fac0' has no handler with id `2955').
Handle the case where the original window is destroyed before its
clone.
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
