Commit Graph

157 Commits

Author SHA1 Message Date
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