This patch combines several high level changes which are conceptually
independent but in practice rather intertwined.
* Add a "state" property to ShellApp which reflects whether it's
stopped, starting, or started. This will allow us to later clean
up all the callers that are using ".get_windows().length > 0" as
a proxy for this property
* Replace shell_app_launch with shell_app_activate and shell_app_open_new_window
A lot of code was calling .launch, but it's signficantly clearer
if we call this ".open_new_window()", and later if we gain the ability
to call into an application's menu, we can implement this correctly rather
than trying to update all .launch callers.
* Because ShellApp now has a "starting" state, rebase panel.js on top of
this so that when we get a startup-notification sequence for an app
and transition it to starting, it becomes the focus app, and panel.js
cleanly just tracks the focus app, rather than bouncing between SN
sequences. This removes display of non-app startup sequences, which
I consider an acceptable action in light of the committed changes
to startup-notification and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=614755
We can't use gdk_display_get_pointer/gdk_window_get_pointer from gjs
when XKB is active. We already had a wrapper that did the
get-modifier-state part of that, but some places also need the
get-pointer-location part of it. So update our wrapper to return both,
and update js code to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=613428
The original window dnd code needed to track whether or not the
pointer was in the clone. Some later rewrite made this unnecessary,
but we were still keeping track anyway.
When the notificaionBin has an odd width this could result into
loosing pixel aligment (and ugly looking font).
As the notification is already reactive make it non reactive and
remove the use of garvity.
https://bugzilla.gnome.org/show_bug.cgi?id=614702
Also reorganizes the notification layout to use an StScrollView; very
tall notifications are now scrolled instead of just taking up more and
more of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=608999
Also, remove a lot of cruft from genericDisplay.js leftover from
previous St-ifications, and remove the pre-gtk-2.16 hacks from the
status tray in panel.js (which are much less needed with the
nearly-all-black panel anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=614516
The actual changes to shell-menu.[ch] are pretty minimal; most of the
changes there are just style/spacing/indentation.
Also, removed shell_menu_append_separator() since it wasn't needed;
the separators would already have been behaving as intended just
because they were non-reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
The check in _windowsRestacked checks for
windows[i].x >= primary.x
and
windows[i].x <= primary.x + primary.width
(likewise for y).
This is wrong because a fullscreen window on the secondary screen is likely
to have windows[i].x == primary.x + primary.width which means that the checks
for _both_ screens would be valid, but the first one would win due to
the "break;" statement.
But here the window isn't really on the primary but on the secondary one.
Fix that by using < instead of <= for those checks.
https://bugzilla.gnome.org/show_bug.cgi?id=614509
Moving to St.Table introduced a regression that resulted in the height
of Places section to only depend on the height of the left column.
This could result into some bookmarks not being displayed at all because
there are not enough items in the left column to allocate the needed height.
Fix this by removing the St.BoxLayout actors and add the items directly to
the table.
https://bugzilla.gnome.org/show_bug.cgi?id=614144
Notify() was calling setApp() unconditionally after attempting to
determine an application. However, determining the application can
fail (for example, when notify-send is used) and resulted in an exception
being printed.
Rather than having the notificationBin, summaryBin, and
summaryNotificationBin span the whole width of the screen and just
align their children to the right spot, set their anchor_gravity
appropriately, set their anchor point correctly, and let their width
vary with the width of their child.
Fixes the fact that the area to the left and right of an expanded
notification was reactive, because the notificationBin was invisibly
covering it.
https://bugzilla.gnome.org/show_bug.cgi?id=612072
Currently manual dnd mode is used with St.Clickable to avoid messing
up its internal state with a pointer grab. To avoid code duplication,
move this special handling into dnd.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
While most of the code already is CSS stylable, the two-colum setup
is still done using Big.Box with hard coded spacings. Port those
remaining parts to St.Widget, so that all spacings can be adjusted
by the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
The POPUP_LIST_SPACING constant was used for the AltTabPopup.actor's padding,
AltTabPopup.actor's spacing and SwitcherList._list's spacing.
Switch to CSS and remove the constant.
https://bugzilla.gnome.org/show_bug.cgi?id=613195
Left-clicking an app icon and holding the button used to pop up the
app menu, but regressed when rewriting appDisplay.
Restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=609013
Clicking the eject button in the places display always triggers an
unmount action. In some cases like USB drives or DVDs, eject makes
more sense - it is also consistent with nautilus' behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=613405
After closing a window, the remaining previews are repositioned
after a timeout; when it is called while the user zooms a preview,
the window positions get all messed up, so postpone the positioning
in this case until the zoom ends.
https://bugzilla.gnome.org/show_bug.cgi?id=613536
The hover rewrite added a freeze/thaw_notify to
st_clickable_leave_event() (to match the one already in
st_clickable_enter_event()), which broke code in two places that
assumed "pressed" would still be TRUE when "hover" changed to FALSE.
Fix that by exposing the "held" property as well.
St.Widget's new "hover" property takes reactive children into account
when deciding whether or not the pointer has actually left the actor,
so it works better than the code that used to be here.
https://bugzilla.gnome.org/show_bug.cgi?id=610726
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
When the user runs the same command as the last one saved there
is no need to save it again, otherwise we the history might end
up having lots of dupes which makes searching for an old command
harder.
https://bugzilla.gnome.org/show_bug.cgi?id=613731
Using a clone for the drag actor causes the animation into
the final position not to work as expected; instead use
the newly added DND parameters to change the original
drag actors size and opacity. (This reverts the change in
011db9f).
Since we are using the original actor, we have to be careful
not to change it during the drag, so don't actually position
dragged window actors in Workspace.positionWindows().
https://bugzilla.gnome.org/show_bug.cgi?id=613367
Gjs now removes user_data arguments for callbacks - the existing
code still works because all user_data arguments are unused and
at the end of the argument list, but it's a lot prettier to remove
them.
Currently, the workspace objects are destroyed and recreated on
view switches. Instead, keep the objects around and reparent the
workspace actors on view switches.
https://bugzilla.gnome.org/show_bug.cgi?id=610191
Depending on screen size and pointer position, the scroll bar used
to switch the active workspace in linear view may not be a convenient
target, so allow dragging the desktop as an alternative.
https://bugzilla.gnome.org/show_bug.cgi?id=610892
DND from the places section broke with 1c4c3afb when St.Label was
replaced with St.Button.
To fix, replace St.Button with St.Clickable and use a fake_release
when starting a drag.
https://bugzilla.gnome.org/show_bug.cgi?id=609218
Currently we use two buttons to toggle between the different views,
one of them always being redundant.
Fix that by only use one button that changes it's style depending on
the current view.
https://bugzilla.gnome.org/show_bug.cgi?id=610801
When an unmount operation fails, the only feedback given currently
is an exception on stderr. Use the infoBar to display an error
message and allow the user to retry the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=612200
Currently the infoBar's button will always read "Undo" - sometimes
a different label makes more sense, so allow to optionally set the
label to something else.
https://bugzilla.gnome.org/show_bug.cgi?id=612200
Instead of setting a fixed size in the CSS which only works well
with a limited range of screen resolutions, assign a relative
size in the code.
While this takes away some flexibility from theme authors, it is in
line with most elements in the overview (workspaces area, dash).
Also expose the menu panes vertical alignment, so that more-apps aligns
to the workspaces area's top and more-docs to the bottom.
https://bugzilla.gnome.org/show_bug.cgi?id=610872
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
