Commit Graph

195 Commits

Author SHA1 Message Date
Georges Basile Stavracas Neto
38c1ebba62
dash: expand and center align DashItemContainer
This is necessary to keep the small actor that shows up
during drag motion center aligned.
2018-10-08 22:43:13 -03:00
Georges Basile Stavracas Neto
efb3025d8c
dash: Set scale and opacity on parent actor
DashItemContainer currently animates the scale and opacity
of its child when zooming in. This is visible when adding
a new favorite item to the dash; the items will zoom in from
the center.

After the previous commit, however, the zoom animation got
slightly broken, and looked like the icon was coming from
the bottom instead of the center.

Fix that by setting the scale and opacity of DashItemContainer
itself, instead of its child. Remove the unused code after that
too.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
2018-10-08 22:42:24 -03:00
Georges Basile Stavracas Neto
81ec8215a0
baseIcon: Stop using Shell.GenericContainer
Pretty much like the previous patches, this extends St.Bin. The
most interesting aspect of this patch is that most of the sizing
routines of the icons is now delegated to the actors and layout
managers, removing quite a bunch of code.

The 'spacing' theme property is now redirected to StBoxLayout's
spacing property. Also adjust the Dash code to stop forcing a
potentially invalid width in the first icon too.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/153
2018-10-08 22:42:24 -03:00
Daniel van Vugt
f77b3da74f js/ui: Choose some actors to cache on the GPU
Flag some actors that are good candidates for caching in texture memory
(what Clutter calls "offscreen redirect"), thereby mostly eliminating
their repaint overhead.

This isn't exactly groundbreaking, it's how you're meant to use
OpenGL in the first place. But the difficulty is in the design of
Clutter which has some peculiarities making universal caching
inefficient at the moment:

 * Repainting an offscreen actor is measurably slower than repainting
   the same actor if it was uncached. But only by less than 100%,
   so if an actor can avoid changing every frame then caching is usually
   more efficient over that timeframe.

 * The cached painting from a container typically includes its children,
   so you can't cache containers whose children are usually animating at
   full frame rate. That results in a performance loss.
     This could be remedied in future by Clutter explicitly separating a
   container's background painting from its child painting and always
   caching the background (as StWidget tries to in some cases already).

So this commit selects just a few areas where caching has been verified
to be beneficial, and many use cases now see their CPU usage halved:

One small window active...... 10% -> 7% (-30%)
...under a panel menu........ 23% -> 9% (-61%)
One maximized window active.. 12% -> 9% (-25%)
...under a panel menu........ 23% -> 11% (-52%)
...under a shell dialog...... 22% -> 12% (-45%)
...in activities overview.... 32% -> 17% (-47%)
(on an i7-7700)

Also a couple of bugs are fixed by this:

https://bugzilla.gnome.org/show_bug.cgi?id=792634
https://bugzilla.gnome.org/show_bug.cgi?id=792633
2018-08-27 14:16:59 +00:00
Florian Müllner
3b1330880f cleanup: Use Function.prototype.bind()
When not using arrow notation with anonymous functions, we use Lang.bind()
to bind `this` to named callbacks. However since ES5, this functionality
is already provided by Function.prototype.bind() - in fact, Lang.bind()
itself uses it when no extra arguments are specified. Just use the built-in
function directly where possible, and use arrow notation in the few places
where we pass additional arguments.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:55:02 +00:00
Florian Müllner
213e38c2ef cleanup: Use arrow notation for anonymous functions
Arrow notation is great, use it consistently through-out the code base
to bind `this` to anonymous functions, replacing the more overbose
Lang.bind(this, function() {}).

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:55:00 +00:00
Florian Müllner
76f09b1e49 cleanup: Use method syntax
Modern javascript has a short-hand for function properties, embrace
it for better readability and to prepare for an eventual port to
ES6 classes.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/23
2018-02-21 13:54:58 +00:00
Marco Trevisan (Treviño)
74683b7ef7 dash: Do not shadow ClutterActor's destroy()
Since commit ef1e27966d turned DashItemContainer into an StWidget,
the destroy() method overrides the ClutterActor method, which is at
the very least bad style. Instead, follow the usual pattern of using
a ::destroy handler.

https://bugzilla.gnome.org/show_bug.cgi?id=791233
2017-12-05 18:07:00 -05:00
Marco Trevisan (Treviño)
6c655a6c71 dash: Make sure item labels are only destroyed once
Labels are currently destroyed from both animateOutAndDestroy()
and destroy(), which now (rightfully) triggers a gjs warning. As
the label is created unconditionally since commit 36e5ae4a25,
mirror that and always release it in destroy() and hide it
elsewhere.

https://bugzilla.gnome.org/show_bug.cgi?id=791233
2017-12-05 18:06:58 -05:00
Florian Müllner
033277b68f Define externally accessible contants with 'var' instead of 'const'
Just as we did with classes, define other constants that are (or
may be) used from other modules with 'var' to cut down on warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=785084
2017-07-18 21:52:06 +02:00
Florian Müllner
2582d16ca7 Define classes with 'var' instead of 'const'
Any symbols (including class properties) that should be visible
outside the module it's defined in need to be defined as global.
For now gjs still allows the access for 'const', but get rid of
the warnings spill now by changing it.

https://bugzilla.gnome.org/show_bug.cgi?id=785084
2017-07-18 21:52:06 +02:00
Florian Müllner
2a01606c59 dash: Fix some JS warnings
We currently use "array[index]" to test whether an array has an
element at index before using it. However nowadays gjs warns about
accessing non-existent array elements, so the test itself already
produces a warning. Avoid this by checking the array length before
using an index to access an element.

https://bugzilla.gnome.org/show_bug.cgi?id=781471
2017-07-13 17:23:54 +02:00
Jakub Steiner
acd5d70209 theme: use update icon for app grid
https://bugzilla.gnome.org/show_bug.cgi?id=761772
2016-02-12 12:12:02 +01:00
Florian Müllner
14c52bb00a dash: Ensure style for icon size computation
StIcon will skip loading the texture when its theme node is unset (which
may happen on style changes while the widget is hidden). While our size
request to compute the dash icon size will create the icon's theme node
if necessary (and of all its parents), a missing texture can still throw
off our computation.
Make sure this doesn't happen by ensuring the icon's style first, so the
texture is updated in response to StWidget::style-changed if necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=745649
2015-10-13 20:21:44 +02:00
Florian Müllner
9720b32987 dash: Revert mislead cleanup
When adjusting dash icon sizes, we compute the icon padding by subtracting
the configured icon size from the first icon actor's preferred size. To
make sure that the preferred size correctly corresponds to the current
dash icon size even while the icon is animating, we enforce the size
before the size request. For that we used to temporarily manipulate
the icon texture size directly, but commit e92d204d42 cleaned this
up to use the setIconSize() method instead.
This does not work however, as the icon actor's iconSize property will
always match the dash iconSize property, making the method a noop. So
go back to the original approach of enforcing the texture size to make
sure we always base our computations on correct values.

https://bugzilla.gnome.org/show_bug.cgi?id=745649
2015-10-13 20:21:44 +02:00
Giovanni Campagna
018025dada dash: use global settings instead of own settings object
Makes it easier to reason about change notifications

https://bugzilla.gnome.org/show_bug.cgi?id=746509
2015-03-27 13:11:22 -07:00
Florian Müllner
4affa5528a dash: Fix show-apps button drop target
Fallout from commit e69cc20fc7 ...

https://bugzilla.gnome.org/show_bug.cgi?id=745666
2015-03-05 12:34:17 +01:00
Florian Müllner
714bc5f103 dash: Fix leaking signal connections
The overview has a longer life-time than dash items, so we are
leaking a signal connection each time an item is destroyed.
Spotted by Michele (<micxgx@gmail.com>)

https://bugzilla.gnome.org/show_bug.cgi?id=744575
2015-02-27 14:16:30 +01:00
Murray Cumming
1da9546c40 App Picker: Prevent drag if favorite-apps is locked.
Because there's nothing (in single-monitor setups) that could
take the drop in this case.

* js/ui/appDisplay.js:
  AllView._loadApps(), FrequentView._loadApps(): Pass
  an isDraggable parameter when creating the AppIcons,
  depending on whether the favorite-apps key is locked.
  AppIcon._init(): Check for isDraggable in the params and
  do not create _draggable if it was specified, to prevent a
  drag from starting.
  AppIcon.popupMenu(): Check _draggable before trying to call
  fakeRelease on it.
* js/ui/dash.js: Dash._createAppItem(): Check AppIcon._draggable
  before trying to connect to its signals.

https://bugzilla.gnome.org/show_bug.cgi?id=741325
2015-01-28 14:15:51 +01:00
David King
e69cc20fc7 dash: Improve feedback when favorite-apps key is locked
In a lockdown scenario, where the favorite-apps GSettings key is not
writable, hide the menu items for adding and removing favorites from the
dash menu. Additionally, reject drops to the dash for DND.

https://bugzilla.gnome.org/show_bug.cgi?id=741325
2015-01-28 14:15:51 +01:00
Bastien Nocera
cd2bd7685a js: Name all the timeouts and idles
With very uninventive names. Names now, good names later.

https://bugzilla.gnome.org/show_bug.cgi?id=727983
2014-04-10 21:08:16 +02:00
Cosimo Cecchi
e92d204d42 dash: account for scale factor to determine icon size
https://bugzilla.gnome.org/show_bug.cgi?id=705410
2014-02-16 07:49:25 -08:00
Florian Müllner
751a3f0e94 js: Use SOURCE_CONTINUE/SOURCE_REMOVE constants in source functions
With support for boolean constants in g-i, we can finally use the
more readable constants instead of true/false.

https://bugzilla.gnome.org/show_bug.cgi?id=719567
2013-12-16 18:27:19 +01:00
Jasper St. Pierre
3991d2729d dash: Make sure we clear the timeout IDs for the label tooltip
https://bugzilla.gnome.org/show_bug.cgi?id=711732
2013-11-09 11:44:44 -05:00
Florian Müllner
5753eb6682 dash: Fix typo
Whoops, how did this make it through review?
2013-08-31 19:53:37 +02:00
Giovanni Campagna
e26a6ea71b dash: reload favorites when the installed app change
Force a reload of the favorite system, to pick apps that were
uninstalled.

https://bugzilla.gnome.org/show_bug.cgi?id=706878
2013-08-31 18:55:24 +02:00
Giovanni Campagna
1b206fe94c Dash: don't show a tooltip over an application with a popup menu
If the popup menu associated with the application icon is open,
make sure that the tooltip is hidden.

https://bugzilla.gnome.org/show_bug.cgi?id=705611
2013-08-26 13:52:49 +02:00
Florian Müllner
90c7876341 dash: Grow the empty dash during drag operations
When the dash does not contain any applications (either favorites
or running), it is currently impossable to add a favorite via DND.
Grow the dash slightly in that case to provide a drop target.

https://bugzilla.gnome.org/show_bug.cgi?id=684618
2013-06-05 15:32:43 +02:00
Florian Müllner
10b77a8305 dash: Minor cleanup
https://bugzilla.gnome.org/show_bug.cgi?id=684618
2013-06-05 15:32:43 +02:00
Florian Müllner
1902f4773b dash: Use a single code path for clearing the drag placeholder
We currently only keep track of old placeholders when moving past
the dragged app's current favorite position, as this is the only
case where we need to worry about jitter. Still, moving it into
_clearDragPlaceholder() allows us to consolidate code paths, which
is a good thing ...

https://bugzilla.gnome.org/show_bug.cgi?id=684618
2013-06-05 15:32:43 +02:00
Florian Müllner
4b95be6a95 dash: Make sure _clearDragPlaceholder() resets _dragPlaceholderPos
The function currently only resets the placeholder position if
there is a placeholder; this is not necessarily true, as the
placeholder may be reset outside _clearDragPlaceholder().
If this happens, the placeholder will temporarily stop working
for the "old" position (and permanently if it's the only position).
Just reset the position unconditionally.

https://bugzilla.gnome.org/show_bug.cgi?id=684618
2013-06-05 15:32:43 +02:00
Florian Müllner
bd6e0ceb81 dash: Simplify some code
https://bugzilla.gnome.org/show_bug.cgi?id=701386
2013-06-01 00:35:24 +02:00
Giovanni Campagna
8bcb10391e dash: add a workaround for Clutter bug 692744
https://bugzilla.gnome.org/show_bug.cgi?id=690643
2013-02-20 20:51:11 +01:00
Giovanni Campagna
8e7d74bc3b dash: fix icon animation
animateIn and animateOut should not reset the scale, otherwise
extra animate calls (which are possible because the diff algorithm
in _redisplay is not optimal) cause unneeded movement.
Therefore, create new items hidden, and have the creator call
animateIn or set the scale/opacity properties manually.
adjustIconSize must be changed to always set the icon size temporarily,
otherwise the first time it computes the icon size with 0 scale.

https://bugzilla.gnome.org/show_bug.cgi?id=690643
2013-02-20 20:51:11 +01:00
Giovanni Campagna
629b6faa22 dash: fix allocation loop when increasing icon size
The DashActor will known to allocate the show apps button only if the
icon size is (temporarily) too big for the containing box, therefore
it should request just that as the minimum size.
This solves a glitch that happened when removing a favorite and at the
same time causing the dash to expand.

https://bugzilla.gnome.org/show_bug.cgi?id=690643
2013-02-20 20:51:11 +01:00
Giovanni Campagna
ef1e27966d dash: turn DashItemContainer into a proper St.Widget
This removes a number of unneeded ._delegate accesses and cleans up
the code.

https://bugzilla.gnome.org/show_bug.cgi?id=690643
2013-02-20 20:51:11 +01:00
Florian Müllner
2658754295 appDisplay: Merge AppIcon and AppWellIcon
AppIcon is just a tiny wrapper around BaseIcon, which does not add
anything over using BaseIcon directly, so merge its code with
AppWellIcon. As the concept of the "app well" has not been used
since well before 3.0, use AppIcon as name for the merged class.

https://bugzilla.gnome.org/show_bug.cgi?id=694192
2013-02-20 00:08:11 +01:00
Cosimo Cecchi
cb7778d433 dash: don't react to window drags
Instead, make the actor half-opaque in that case.

https://bugzilla.gnome.org/show_bug.cgi?id=686984
2013-02-18 22:50:11 -05:00
Cosimo Cecchi
1379c6b404 overview: move ctrlAltTab handling to Dash
This is also what the panel does.

https://bugzilla.gnome.org/show_bug.cgi?id=693924
2013-02-15 23:47:12 -05:00
Florian Müllner
f602993aa9 dash: Disable animations during overview transitions
When updating the dash, we already avoid all animations while the
overview is hidden. However, as we are using Main.queueDeferredWork(),
updates may be deferred up to ~20 seconds while the overview is hidden.
If the overview is entered before a queued update has taken place, it
will be run immediately on map - as the overview is visible by then,
this means animating any outstanding changes.
Work around this by skipping animations during overview transitions as
well.

https://bugzilla.gnome.org/show_bug.cgi?id=686530
2012-11-12 16:59:12 +01:00
Stéphane Démurget
86596749fa Revert "overview: highlight windows on launcher hover"
This reverts commit 76229a3601.

Pushed by accident.
2012-11-07 00:33:32 +01:00
Stéphane Démurget
76229a3601 overview: highlight windows on launcher hover
When in the overview, if you move the mouse cursor over one of the
application launchers in the dash, all the unrelated windows are dimmed
both both in the window view and in the workspace view.

It helps to easily understand whether or not there are already opened
windows for this application, and where they are. It can also help in
differentiating the windows in the overview (sometimes the thumbnails
aren't precise enough to easily know which thumbnail belongs to which
application).

https://bugzilla.gnome.org/show_bug.cgi?id=657315
2012-11-07 00:27:31 +01:00
Stéphane Démurget
95abdeb919 dash: simplify app retrieval from AppWellIcon
This has also the benefit of getting the application even if it can not
be retrieved through AppSystem, which can happen if the runtime WMClass
does not match the one of the desktop file.

This especially looked wrong with the following commits related to the
bug.

https://bugzilla.gnome.org/show_bug.cgi?id=657315
2012-11-07 00:27:31 +01:00
Stéphane Démurget
df0151d338 dash: rename a local variable for clarity
createAppIcon creates an appIcon, not a 'display', which made things
unnecessarily more difficult to understand.

https://bugzilla.gnome.org/show_bug.cgi?id=657315
2012-11-07 00:26:50 +01:00
Stéphane Démurget
ee2f12fe81 dash: properly restore item label on popup close
We simply hide the label when the popup is opened instead of relying
on the popup state when the hover state change.

To do this we replace the flag isMenuUp by a 'menu-state-changed' signal
on the AppWellIcon. This simplifies the dash label visibility handling
code that need additional changes for the bug.

https://bugzilla.gnome.org/show_bug.cgi?id=657315
2012-11-07 00:26:11 +01:00
Alejandro Piñeiro
4ebf396cf5 a11y: fixing a regression with the accessible name at dash items
After some changes, the tooltip label at the dash is not available
until it is visually shown. As this is not anymore a reliable
source of accessible name, we just set the accessible name
with the string used on that label.

https://bugzilla.gnome.org/show_bug.cgi?id=686583
2012-11-06 10:05:18 +01:00
Florian Müllner
cf58a7eafd dash: Reset show-apps label on drag-end
Currently the label for the show-apps button is only updated during
drag operations, so after an item is successfully dropped on the
button, the label will still read "Remove from Favorites".
Fix this by resetting the label on drag-end.

https://bugzilla.gnome.org/show_bug.cgi?id=684627
2012-10-15 23:22:34 +02:00
Jasper St. Pierre
6487cd8c6f dash: Only set the label's text when initially showing the label
Having the tooltip change when it's visible looks strange and glitchy.
This also makes sure that "Remove from Favorites" doesn't change, even
when the user removes their mouse cursor from it.

https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:55 -03:00
Jasper St. Pierre
06e5c25383 dash: Make the dash items accessible
https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:54 -03:00
Jasper St. Pierre
36e5ae4a25 dash: Construct the label at init
Nothing doesn't use a label, so it doesn't make sense to
lazily initialize it.

https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:54 -03:00