Commit Graph

184 Commits

Author SHA1 Message Date
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
Jasper St. Pierre
245e43ea8c dash: Make the tooltip and hover effect sync up to the real insensitivity
We shouldn't display "Remove from Favorites" when dropping on the button
will do nothing.

https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:54 -03:00
Jasper St. Pierre
52871c781a dash: Make the show apps button insensitive when we're dragging a non-favorite
This doesn't handle the tooltip case, unfortunately. That will come in a bit.

https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:54 -03:00
Jasper St. Pierre
f994ada576 dash: Clean up unused code
https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:53 -03:00
Jasper St. Pierre
147a6e49dc dash: Refactor some common code
Take the code that gets an app from a "source" that's duplicated
in lots of spots and refactor it out.

https://bugzilla.gnome.org/show_bug.cgi?id=685313
2012-10-06 16:07:53 -03:00
Jasper St. Pierre
7206b61838 dash: Make padding even on the top/bottom of the dash
When Florian landed the new dash container to show the all apps button
always, he got the math wrong -- he forgot to add padding around the
container, and used the height of the box to calculate a y2 position,
rather than the y2 position of the box.

https://bugzilla.gnome.org/show_bug.cgi?id=684619
2012-10-01 06:49:13 -03:00
Florian Müllner
2db029bcdb dash: Don't underallocate show-apps button
When the dash contains more icons than fit at the minimum icon size,
icons are cut off at the end. This means that the show-apps button
will be the first to disappear, which is problematic given it's the
sole access point for other applications (for those that refuse to
use search at least).
Fix by using a dedicated widget for the dash actor, so that in case
of underallocation only icons above the show-apps button end up being
cut off.

https://bugzilla.gnome.org/show_bug.cgi?id=683340
2012-09-12 16:32:52 +02:00
Jasper St. Pierre
c21b1e5fe0 st: Remove StIconType
GTK+ works by explicitly specifying a -symbolic suffix for all icons.
Do the same here.

https://bugzilla.gnome.org/show_bug.cgi?id=682540
2012-08-29 16:41:09 -03:00
Alejandro Piñeiro
b50604d070 a11y: set a proper label for the "Show Applications" dash button
https://bugzilla.gnome.org/show_bug.cgi?id=682366
2012-08-27 10:43:35 +02:00
Jasper St. Pierre
3fafe0da07 dash: Add tooltip label to show applications icon
Make the tooltip dependent on whether we are currently dragging
on hover or not.

https://bugzilla.gnome.org/show_bug.cgi?id=682445
2012-08-22 15:55:24 -03:00
Jasper St. Pierre
983535224e dash: Fix some issues with the label API
Be able to call setLabelText more than once.

https://bugzilla.gnome.org/show_bug.cgi?id=682445
2012-08-22 15:55:24 -03:00
Joost Verdoorn
0959adcfe3 overview: Center the dash vertically
https://bugzilla.gnome.org/show_bug.cgi?id=682109
2012-08-20 14:23:19 +02:00