Limit the AppSwitcher to the screen size by either downscaling or
scrolling.
We scale the icons down up from 96, 64, 48, 32 to 22 and start scrolling
if we still fail to fit on screen.
The thumbnail box is shifted to either left or right, when failing to
fit we scroll here to.
To prevent from being offscreen at the buttom we adjust the thumbnail
height to fit.
The old positioning logic is replaced with a ShellGenericContainer to
implement a custom allocation system.
https://bugzilla.gnome.org/show_bug.cgi?id=597983
As the repositioning after closing a window preview is delayed, it is
possible that the timeout is triggered while leaving the overview. In
that case the previews move to the new overview position and are changed
abruptly to the original window position when the overview zoom is done.
To prevent this, disconnect the handler when leaving the overview.
Rename WorkspacesViewSwitch to WorkspacesControls and let it manage
all workspace controls. Do not destroy and recreate the controls bar
actor on each view change, but add it to the overview once and let it
update itself.
https://bugzilla.gnome.org/show_bug.cgi?id=610189
Hide the original actor during a grab, and create a new
clone. This is easier than trying to ensure we maintain
the state of the original window clone.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
The way we were loading data into a CoglTexture, then pulling it out
and manipulating it on the CPU, then loading it back into a texture
was a bit lame.
Clean things up a bit here by loading directly into the CPU, doing
the fading, then creating a texture.
Also cache the faded data in StTextureCache.
https://bugzilla.gnome.org/show_bug.cgi?id=612759
Having StDrawingArea use ClutterCairoTexture causes circularity
problems with sizing - StDrawingArea wants to use its allocation for
the size of the texture, but ClutterTexture wants to use the size of
the texture to determine the requited size.
Avoid this by making StDrawingArea directly use Cairo and CoglTexture;
while doing this, the API is changed a bit for simplicity and to
match our use case:
- Instead of clutter_cairo_texture_create(), we have
st_drawing_area_get_context() to retrieve an already created
context. This can only be called in the ::repaint signal.
- The ::redraw signal is changed to ::repaint so we can have
st_drawing_area_queue_repaint() that doesn't collide with
clutter_actor_queue_redraw()
- ::repaint is now emitted lazily when painting the actor rather
than synchronously at various different points.
https://bugzilla.gnome.org/show_bug.cgi?id=611750
Currently clicking on an empty spot on the workspace actors switches to the workspace, this has a side effect that when for some reason (like using a touchpad),
the user misses the window he intends to open he will end up with the currently focused window instead.
Disable this behaviour if more than one window is open (in that case the user has to explicitly target a specific window).
https://bugzilla.gnome.org/show_bug.cgi?id=610868
Support completion on files and folders in the run dialog and launch
the default application when activated. Assume a path relative to the
home directory if execution as command fails and the input doesn't start
with a slash.
Removed workaround for relayout of error messages.
https://bugzilla.gnome.org/show_bug.cgi?id=611209
We used to set this._notificationRemoved to false in _hideNotification().
However, the user focusing on the associated application can result in the
source being removed while the notification is hiding, in which case
this._notificationRemoved was set to true and never unset. This resulted in
the next notification only showing up briefly and hiding. Moving setting
this._notificationRemoved to false to _hideNotificationComplete() fixes this
behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=611122
The top part of the application pane closes the pane, while outside
the menu only the workspace area accepts clicks for closing the pane.
Let the user close the pane by clicking anywhere outside the menu, but
not inside.
https://bugzilla.gnome.org/show_bug.cgi?id=611641
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
Previously, every time _updateState was called, it would make some
change, and so it was necessary to very carefully set up all the calls
to it, to ensure it was always called at exactly the right time. Now,
instead, we keep a bunch of state variables like "_notificationState"
and "_pointerInSummary", and potentially multiple timeouts, and
_updateState looks at all of them and figure out what, if anything,
needs to be changed.
By making the rules about what causes changes more explicit, it will
be easier to change those rules in the future as we add new
functionality.
Also, update the rules a bit, so that notifications can appear while
the summary is visible, and the summary only shows after a
notification if the summary has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=609765
Fallback icons (i.e icons < requested size) cause the box in the switcher
to be a smaller rectangular item instead of the normal sized square one.
Fix that by putting the icons in a St.Bin with the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=609777
Currently, activating a search result always opens a new window. Change
this behavior, so that if an application has open windows, the most
recently used one is activated instead.
Also change the implementation of dnd of search results to allow providers
to treat results activated via dnd differently.
https://bugzilla.gnome.org/show_bug.cgi?id=610027
Previously the banner was only promoted to the body if it got
truncated, but the banner was *always* hidden when expanding the
notification. This meant a message with a short banner, plus
notification buttons, would have no banner text visible when it was
expanded. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=606755
As desktop icons don't have any purpose in the overview (except for
distracting the user), fade them out when entering the overview.
Unfortunately, the fading effect affects performance, therefore hide
icons directly when there are maximized windows on the desktop.
https://bugzilla.gnome.org/show_bug.cgi?id=600999
This adds some meaningful functionality to the notification icons in the tray
and in the notification pop-up and allows to switch to the application that
sent the notification.
We get the application from the notification context and set it on the source
for the notification.
Replace the current workspace switcher popup (which is still the old metacity popup), with a clutter based one, which fits better into the overall shell design.
https://bugzilla.gnome.org/show_bug.cgi?id=609187
Currently the window-added and window-removed callbacks in
main.js:_onWorkspaceSwitched access the first parameter as metaWindow object,
but in fact the first one passed is the workspace (metaWorkspace).
Fix it by using the second parameter instead (which is a metaWindow object).
https://bugzilla.gnome.org/show_bug.cgi?id=609521
