Commit Graph

248 Commits

Author SHA1 Message Date
Florian Müllner
e68dfed1f7 cleanup: Port GObject classes to JS6 classes
GJS added API for defining GObject classes with ES6 class syntax
last cycle, use it to port the remaining Lang.Class classes to
the new syntax.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
2019-01-25 14:02:44 +00:00
Florian Müllner
bacfdbbb03 cleanup: Port non-GObject classes to JS6 classes
ES6 finally adds standard class syntax to the language, so we can
replace our custom Lang.Class framework with the new syntax. Any
classes that inherit from GObject will need special treatment,
so limit the port to regular javascript classes for now.

https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/361
2019-01-25 14:02:44 +00:00
Andrea Azzarone
ff2fbf5ae4 dash: destroy items's child before tooltip
Destroy the DashItemContainer's child from the same handler as the tooltip. This
will prevent invalid reads when the item is destroyed while its quicklist is
still open.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/781
2018-11-19 15:51:32 +00:00
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
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
Joost Verdoorn
816a29d582 viewSelector: Hook up the dash's showApps button
We pass the dash’s showApps button to the viewSelector, and we connect it
to the showing and hiding of the appsView. This is necessary because there
are different mechanisms for switching the views, and it has to stay in
sync with the button’s state.

https://bugzilla.gnome.org/show_bug.cgi?id=682109
2012-08-20 14:23:18 +02:00
Joost Verdoorn
27fbe4cd83 dash: Refactor favRemoveTarget to showAppsIcon
In the new designs, we no longer need favRemoveTarget. As it shares a lot
of its functionality with the new showAppsIcon, we refactor and restyle it
accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=682109
2012-08-20 14:23:18 +02:00
Joost Verdoorn
2ee6f49a93 dash: Make the favRemoveTarget always visible
We’ll be repurposing the favRemoveTarget, which calls for it the be
permanently visibe.  The favRemoveTarget used to be added to the dash when
needed and removed again when it wasn’t. This made that it always appeared
at the bottom of the dash. Now that we always show it, we also need to
explicitly define it to be at the bottom of the dash.

https://bugzilla.gnome.org/show_bug.cgi?id=682109
2012-08-20 14:23:18 +02:00
Stefano Facchini
9812771dcd dash: hide tooltips when overview begins hiding
Otherwise the tooltip remains visible until the overview animation is
completed, which is odd.

https://bugzilla.gnome.org/show_bug.cgi?id=674241
2012-07-12 23:50:30 -04:00
Ron Yorston
8c33adfd29 dash: Destroy tooltip label when item is removed 2012-04-27 15:50:48 -04:00
Alejandro Piñeiro
8db193a172 a11y: Setting proper label_actor of dash elements
https://bugzilla.gnome.org/show_bug.cgi?id=644255
2012-03-15 20:23:47 +01:00
Alejandro Piñeiro
c064973c9d a11y: Make DashItemContainer._label public
https://bugzilla.gnome.org/show_bug.cgi?id=644255
2012-03-15 20:22:18 +01:00
Jean-Philippe Braun
47f7fcd4fe dash: Fix placeholder jumps while dragging a dash item
We are currently taking "old" placeholders that are still animating
out into account to calculate the new placeholder position - this
causes an annoying bug, where dragging a dash item downwards triggers
quick continous position changes of the placeholder.
Just ignoring old placeholders fixes the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=651842
2012-03-13 23:47:06 +01:00
Florian Müllner
4ac352637c dash: Don't allow to remove running apps from favorites
Running apps are always kept in the dash, so removing them from
favorites just moves them to the end of the favorites list. This
behavior is not immediately obvious, so only show the remove target
when dragging a favorites application that is not currently running.

https://bugzilla.gnome.org/show_bug.cgi?id=644853
2012-03-06 15:14:22 +01:00
Jean-Philippe Braun
b047a37a80 dash: Don't favorite items dropped at their original position
Remove the drag placeholder when the dragged item is outside
the favorites. Dash items can be favorite only if the drag
placeholder exists.

https://bugzilla.gnome.org/show_bug.cgi?id=656333
2012-03-03 17:42:01 +01:00
Jasper St. Pierre
15f881f967 st: Remove custom text direction stuff
Clutter has its own built-in system for managing text directions, like GTK+.
Convert over to use this.

https://bugzilla.gnome.org/show_bug.cgi?id=670034
2012-02-28 08:14:06 -05:00
Jasper St. Pierre
a8b081661c st-box-layout: Remove insert_actor/insert_before
Now that 'insert_child_at_index' and 'insert_child_below' exist
on ClutterActor, these aren't necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=670034
2012-02-22 17:00:44 -05:00
Jasper St. Pierre
c892610f27 st-container: Remove st_container_destroy_children
It was a simple wrapper around clutter_actor_destroy_all_children.

https://bugzilla.gnome.org/show_bug.cgi?id=670034
2012-02-22 17:00:44 -05:00
Florian Müllner
c6e9f9742b dash: Use the correct theme node for spacing/padding
We consider spacing and padding in _adjustIconSize, but as we use
the theme node from an actor which is not exposed to the CSS, we
miss the "real" values - correct this.

https://bugzilla.gnome.org/show_bug.cgi?id=662213
2012-01-24 22:53:22 +01:00
Seif Lotfy
6829590c8f dash: improve timing of labels
DashItem labels have initial delay before showing up, but once the
first label in the dash is visible (meaning the user is very likely
exploring things) and the pointer is moved along the dash, the label
will follow immediately.

https://bugzilla.gnome.org/show_bug.cgi?id=666170

Signed-off-by: Seif Lotfy <seif.lotfy@collabora.co.uk>
2012-01-20 20:19:18 +01:00
Seif Lotfy
2b9561fcbb dash: Move labels beside the app icon upon hovering
Instead of using an St.Tooltip to show the app's name under the icon,
manually position a new St.Label ourselves. Make sure to keep the label
hidden when right-clicking so it doesn't get in the way of the popup menu.
Only one tooltip/label will be displayed at a time.

https://bugzilla.gnome.org/show_bug.cgi?id=666166
2011-12-22 09:07:48 +00:00
Giovanni Campagna
17c46c2452 Port everything to class framework
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().

https://bugzilla.gnome.org/show_bug.cgi?id=664436
2011-11-24 09:50:04 +01:00
Giovanni Campagna
d6b6f814d3 Port all classes with inheritance to class framework
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.

https://bugzilla.gnome.org/show_bug.cgi?id=664436
2011-11-24 09:50:04 +01:00
Jasper St. Pierre
703d2ead33 workspaceThumbnail: Allow users to create workspaces at any position
Allow a user to create a new workspace by dragging a window or a launcher in
the middle of two existing ones.

https://bugzilla.gnome.org/show_bug.cgi?id=646409
2011-11-07 14:36:06 -05:00
Florian Müllner
6d0be86a4e dash: Add minor optimization to _adjustIconSize()
In case _adjustIconSize() is called while the the dash icons are
animating, some extra work is required to yield the expected result.
Skip those extra steps when the icons are not actually animating.

https://bugzilla.gnome.org/show_bug.cgi?id=649248
2011-10-17 16:07:52 +02:00
Florian Müllner
a4b69db8af dash: Rework _adjustIconSize()
The current code uses the dash's height and current icon size to
calculate the new icon size. However, the height does not correctly
relate to the icon size while the icons are animating, in which
case the resulting icon size may be wrong.
Rework the function to be independent from the actual icon sizes,
so that a correct size is calculated even when called during an
animation.

https://bugzilla.gnome.org/show_bug.cgi?id=649248
2011-10-17 16:07:52 +02:00
Florian Müllner
790b9d3371 dash: Ignore hiding items in _adjustIconSize()
Rather than relying on the caller to hide the remove target and
removed items before calling _adjustIconSize(), move that logic
into _adjustIconSize() itself.

https://bugzilla.gnome.org/show_bug.cgi?id=649248
2011-10-17 16:07:52 +02:00
Florian Müllner
adef2009a5 Revert "dash: Ignore hiding items in _adjustIconSize()"
Ooops, a patch got lost in rebase.

This reverts commit b07f9932db.
2011-10-17 16:01:19 +02:00
Florian Müllner
1721db6d8d Revert "dash: Add minor optimization to _adjustIconSize()"
Ooops, a patch got lost in rebase ...

This reverts commit 6d95e8b988.
2011-10-17 16:00:52 +02:00
Florian Müllner
6d95e8b988 dash: Add minor optimization to _adjustIconSize()
In case _adjustIconSize() is called while the the dash icons are
animating, some extra work is required to yield the expected result.
Skip those extra steps when the icons are not actually animating.

https://bugzilla.gnome.org/show_bug.cgi?id=649248
2011-10-17 15:58:25 +02:00
Florian Müllner
b07f9932db dash: Ignore hiding items in _adjustIconSize()
Rather than relying on the caller to hide the remove target and
removed items before calling _adjustIconSize(), move that logic
into _adjustIconSize() itself.

https://bugzilla.gnome.org/show_bug.cgi?id=649248
2011-10-17 15:58:16 +02:00
Dan Winship
75b824d032 *.js: Make emacs modelines consistent
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.

https://bugzilla.gnome.org/show_bug.cgi?id=660358
2011-10-11 08:05:12 -04:00
Rui Matos
3f61f39ae3 dash: Adjust placeholder size to icon size
The placeholder looks odd near small icons and causes the dash to get wider
when visible and narrower when hidden.

https://bugzilla.gnome.org/show_bug.cgi?id=659210
2011-09-20 21:01:25 +01:00
Colin Walters
0af108211c apps: Ensure running apps override new .desktop file data
This patch fixes the "apps vanish from alt-TAB bug".

If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...).  In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.

In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.

What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance.  This ensures we preserve any state such as the
set of open windows.

This requires moving the running state into ShellAppSystem.  Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.

This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation.  As long as
we're on top of random broken tar+wget wrappers, it will be gross.

A slight future improvement to this patch would add an explicit
"merge" between the old and new data.  I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.

https://bugzilla.gnome.org/show_bug.cgi?id=657990
2011-09-05 17:29:41 -04:00
Ray Strode
356e4c0967 overview: make dash private
The dash object is currently exposed as a public object.
It's only used outside of the overview for the dash object's
iconSize property though.

This commit makes the dash object private and proxies the dash
iconSize property to the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=657082
2011-08-28 12:25:04 -04:00
Colin Walters
10dcc100e9 Kill off ShellAppInfo, move into ShellApp
This dramatically thins down and sanitizes the application code.

The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
  they're shortcuts for an app), and we don't have many of them, so
  don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
  found.  The semantics where it tried to find the .desktop file
  if we didn't know about it were just broken; I am pretty sure no
  caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
  and by GMenuTreeEntry), but is no longer in the business of
  dealing with GMenuTree as far as hierarchy and categories go.  That
  is moved up into js/ui/appDisplay.js.  Actually, it flattens both
  apps and settings.

Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps.  We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.

The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:

_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox

Similarly for function names.  We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.

NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f.  It's fast enough
here without that.

https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-10 12:59:32 -04:00
Florian Müllner
737f395d6c dnd: Rename DND.removeMonitor() to DND.removeDragMonitor()
DND.addDragMonitor() and DND.removeMonitor() are inconsistently
named, so rename the latter.

https://bugzilla.gnome.org/show_bug.cgi?id=652730
2011-06-27 21:39:28 +02:00
Owen W. Taylor
019670b5ab dash: during drag, only offer trash can when dragging favorites
We should only show the trash can when the user starts dragging a
favorite from the dash, not when the user starts dragging an application
that happens to be a favorite via a window or an application icon
in the applications view.

https://bugzilla.gnome.org/show_bug.cgi?id=642895
2011-05-25 16:43:24 -04:00
Dan Winship
898b2b903d environment: put gettext stuff into global environment
Rather than defining _() as a local function in every module, put it
into the global environment (along with C_() and ngettext()).

https://bugzilla.gnome.org/show_bug.cgi?id=649203
2011-05-16 14:57:21 -04:00
Florian Müllner
4a93ce703e dash: Show tooltips on hover
As dash items no longer show application names, display names as
tooltips on hover.

https://bugzilla.gnome.org/show_bug.cgi?id=642871
2011-03-22 12:37:14 -04:00
Florian Müllner
2c48efa3fd dash: Handle cancelled drags
If a drag was cancelled, do animations like size changes or zooming
out the remove target in parallel with the snapback animation.

https://bugzilla.gnome.org/show_bug.cgi?id=644324
2011-03-19 11:16:10 +01:00