When closing windows in the window picker, the remaining windows
move to their new positions, which prevents the user from performing
additional actions in the picker until the animation stops and the
user adjusts to the new layout.
Instead we try to be smart and delay the repositioning, either until
the pointer stops moving or until it leaves the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=611167
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
These variables were computed strangely; through cancellation
they'd end up being negative 1/2 the width/height of the actor,
so just use that directly.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
The current check looks at whether there was some am/pm suffix in the
localized time; however in some cases (locales) that does not seem to
work. this version instead checks whether the localized versions of 05:00 and
17:00 start with the same two digits; if not, it's probably a 24h clock.
https://bugzilla.gnome.org/show_bug.cgi?id=603488
The previous commit broke activation when selecting an actor
from a custom renderer. Fix this by explicitly defining a method
activateSelected on the search renderer.
Switch to using an application icon as per design.
We need to drop the 4 pixels padding to ensure we fit 3 icons.
There was a typo where getVisibleCount should have been getVisibleResultsCount.
https://bugzilla.gnome.org/show_bug.cgi?id=610740
When workspaces slide in/out in mosaic view, they may cross with the
workspace controls, which looks pretty weird.
Also adjust the vertical spacing in the grid view so that the grid height
matches the workspace height in the linear view.
https://bugzilla.gnome.org/show_bug.cgi?id=610350
When figuring out where to position window previews, use the clone's
position instead of the the original meta window. There shouldn't be
a difference when entering the overview, but it makes the motion when
opening/closing new windows in the overview tinier and more predictable.
https://bugzilla.gnome.org/show_bug.cgi?id=611167
Fading the application icon required the texture to have already been
loaded, which was normally the case since we create icons for apps
in the well and browser; but when finding an app not from there,
the cogl-texture for the icon might not be available.
Fix this by watching for the texture and fading when it appears.
https://bugzilla.gnome.org/show_bug.cgi?id=611288
Because we were setting the "fixed-position-set" property
on the internal label, its width/height requests weren't
being accounted for in the size request of the overall box.
The way we were hooking up to notify::allocation was hacky; do
this correctly by simply implementing a container.
https://bugzilla.gnome.org/show_bug.cgi?id=611288
Currently the picker displays information on the hovered actor's
position and the object itself. Adding style id and class of
StWidgets to the displayed information can be very helpful for
identifying a particular actor or code segment.
https://bugzilla.gnome.org/show_bug.cgi?id=611211
When the currently focused app sends a notification while in the overview,
the corresponding source icon is not removed when the overview is left.
It does make some sense to treat the overview transition the same as a
normal focus change, so we should update the summary view accordingly.
When a notification is updated by the application, the corresponding
app in its source is lost, so it is no longer possible to switch to
the application by clicking either the notification or the summary icon.
As the associated application of a source never changes, it appears safe
to leave it alone on notification updates.
https://bugzilla.gnome.org/show_bug.cgi?id=610820
Source icons are no longer needed to inform the user about events
having occured in a particular application when (s)he activates the
window - treat that case just as if the user had clicked the source
icon.
https://bugzilla.gnome.org/show_bug.cgi?id=610494
Right now notifications are expandable if the length of bannerText
exceeds the notification's width - however, if bannerText contains
newlines, it should be expandable regardless of the length.
https://bugzilla.gnome.org/show_bug.cgi?id=610549
When leaving the overview by hitting escape or super, all windows animate
to their original positions. Zoomed windows are kept above others until
the animation ends, then the focused window is brought to the front; as
this looks odd if the zoomed window does not have focus, cancel the zoom
in that case before leaving the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=609243
While zooming, a window clone is reparented to the stage and thus cannot
be destroyed automatically by the "parent" container. To prevent the clone
and the corresponding overlay from leaking, we enforce destroying the clone
with the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=609243
We are planning to add Empathy-specific features in the message tray, but in the
meantime we handle Empathy notifications received through the notification daemon
so that their behavior is closer to the eventual design, which is how it was before
we started associating applications with a single source and enabled notification
replacement.
Use the "appName" parameter in notifications to identify the source
rather than the id - use the latter to enable update and removal of
individual notifications as laid out in the desktop notification spec.
This is a rebase of the patch by Florian Müllner.
Add a 'vshadow' property to StScrollView, which, when turned on,
overlays gradient shadows on the top and bottom of the StScrollView.
Turn this on for the StScrollView used for the app browser.
https://bugzilla.gnome.org/show_bug.cgi?id=609604
Changes notifications like:
XChat: Private message from: danw (GimpNet) blah...
to
danw: blah blah blah blah
(the "XChat" being unnecessary since there's already an xchat icon
there anyway.)
https://bugzilla.gnome.org/show_bug.cgi?id=608915
Make the width of the workspace switcher dynamic in order to make it have the same proportions as the actual screen.
Call redraw after adding indicator to stage to avoid warning.
https://bugzilla.gnome.org/show_bug.cgi?id=610049
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Inform the user about demands attention events using the messagetray.
Clicking on the notification icon moves the user to the window.
It differentiates between newly started apps and windows of already running apps, by showing different banners for this cases.
It is based on Jon Nettleton's "window attention" extension.
https://bugzilla.gnome.org/show_bug.cgi?id=610594
WindowOverlay has two actors, both with custom style properties, which
share a common _onStyleChanged() handler. This is not a problem when
entering the overview, because the actors' parent (the workspaces group)
is hidden while the actors are added. However, when windows are added to
the workspace while in the overview (e.g. when opening a new window or
dragging a window from one workspace to another), adding the first actor
to the workspaces group triggers a style-changed signal - the handler
then calls st_widget_get_theme_node() on both actors, which triggers a
warning as the second actor has not been parented yet.
https://bugzilla.gnome.org/show_bug.cgi?id=610279
If the notification body contains '&' it ends up empty and a warning
about an invalid entity is printed on stderr, so our escape code must
handle ampersands as well.
https://bugzilla.gnome.org/show_bug.cgi?id=607375
Right now, the summary starts popping up when the overview has been
shown and starts to disappear when the overview is hidden. Instead,
animate the summary during the overview transition.
https://bugzilla.gnome.org/show_bug.cgi?id=610520
Unify the style of <delegate>.destroy() methods to only contain a
call to <delegate>.actor.destroy() and handle additional cleanup
in a _onDestroy() signal handler.
https://bugzilla.gnome.org/show_bug.cgi?id=609454
Instead of deleting workspaces immediately, animate the removal - it may
be useless eye-candy, but it's pretty sexy nonetheless ...
More seriously, the animation improves consistency with both workspace
additions and the mosaic view.
https://bugzilla.gnome.org/show_bug.cgi?id=609673
Currently the width of the gaps between workspaces in both linear
and mosaic view are defined as constants. Move these to the theme's
CSS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=609673
Reorganize the code to break up positioning into:
1) updating workspace object's scale and position
2) applying the updated parameters to the workspace actor
3) scrolling the view to a particular workspace
4) handling dragging of the scroll bar
With these cleanups, it becomes much easier to fix
the following issues:
- use animations consistantly instead of doing hard breaks
for some actions and smooth transitions for others
- snap to the closest workspace when scrolling stops
(https://bugzilla.gnome.org/show_bug.cgi?id=607823)
- fix the regression of the zoomFromOverlay animation when
the selected app is on another workspace
(https://bugzilla.gnome.org/show_bug.cgi?id=609081)
https://bugzilla.gnome.org/show_bug.cgi?id=609673
This way, clicking a message tray icon while the overview is open will
close the overview when activating its window.
Remove some other overview-related activation code which is now
redundant.
Also, remove calls to "global.get_current_time()" when calling
Main.activateWindow, since it's unnecessary (activateWindow will call
it itself if you don't pass in that arg).
https://bugzilla.gnome.org/show_bug.cgi?id=609765
