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
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
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
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
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
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
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
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
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
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
To deal with different CSS in RTL locales, we used to manually add
an :rtl pseudo class to some actors. With automatically assigned
:ltr/:rtl selectors this is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
As the dash uses different widths and radii for left and right
borders, we need to use different CSS when it is positioned at
the right of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=642721
As Main.overview is now usable from the dash's constructor, move
the setup of signal connections there and remove the show/hide
methods which were used as workaround.
https://bugzilla.gnome.org/show_bug.cgi?id=642196
As elements in the dash are scaled to accommodate a growing number
of items, the icon size used may end up rather small. In that case,
dragging items to the dash which are significantly larger than items
in the dash is getting clumsy, so it makes sense for some components
to synchronize the size of drag actors with the currently used icon
size in the dash. To enable other components to do this, make the icon
size a public property.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
We already skip animations for item additions/removals while the
overview is hidden or when initially filling the dash (to avoid
an odd zoom effect when showing), apply the same logic to animations
of icon size changes.
If a window is closed, the list of running applications may change
while the overview is hidden. Animating dash changes is pointless
in this case, so update the dash without animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The dash is created empty and the initial set of items is added
before it's shown for the first time. As the additions of items
is now animated, this results in a slightly odd effect when all
items zoom in at once. So special-case the first time _redisplay()
is called and skip animations in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
In general, all changes in the shell interface should be backed
by animations to give the interface a more natural feel and provide
feedback of what's happening. Currently the dash violates that
principle, as items simply appear/disappear or change size abruptly,
so add animations for application list and icon size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Clutter containers only take their children's size into account, but
not their scale. As we want the dash to change its size smoothly
when zooming items in/out, we wrap each item in a custom container
which does consider the child's scale.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
When the list of applications in the dash changes, all items are
removed and new ones added. While this approach is nice and simple,
it does not work if we want to animate changes. So rather than
replacing the old list of applications with the new one, figure
out the changes and only apply those.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
Previously the icon size was only adjusted due to changes in the list
of application icons displayed, not when showing or hiding the remove
target. As a result, the remove target could end up cut off, so take
this case into account and adjust the icon size when showing or hiding
the remove target.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
The current approach to adjust the icon size of dash items is rather
expensive: the size of each item is changed from largest to smallest,
until the height of the dash fits the maximum available height, so
quite some ClutterTextures are created and disposed.
A better approach is to calculate the required size beforehand and
only change the icon size when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
With the current dash layout of a single column, nearly every icon
label ends up ellipsized, even at the largest allowed icon size.
Not showing any labels appears to be the cleanest approach in this
case, so disable them in the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=636156
When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.
https://bugzilla.gnome.org/show_bug.cgi?id=640996
1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
on the children to be removed. In the rare cases where it might be needed
the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781
AppWellIcon is used both in the dash and view selector. As the dash
requires manual sizing, it is not possible to set the icon size used
in the view selector in the CSS, but icons will use the default size
(unless set manually as in the dash).
Expose the params parameter of BaseIcon and enable manual resizing
only for AppWellIcons in the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
Show a positional indicator where a new favorite will be added and
make the favorites re-orderable. Also allow the removal of favorites
using drag-and-drop according to the mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The view selector is a tabbed interface with a search entry. Starting
a search switches focus to the results' tab, ending a search moves the
focus back to the previously selected tab. Activating a normal tab
while a search is active cancels the search.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
With the new layout, search results will be displayed in an independent
view like window previews, applications and possible future additions;
it does not make much sense keeping it with the switching logic, so move
the code to its own file.
Also remove the dash-prefix from the relevant style classes.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
The new dash implementation is a single-column vertical sidebar,
whose items are scaled dynamically to fit the available height.
If the height is still exceeded after scaling down to a minimum
item size, excess items are cut off.
The now unused old dash implementation is renamed to OldDash, as
its code will be used as a base for the new view selector element.
https://bugzilla.gnome.org/show_bug.cgi?id=634948
We should not be showing the cursor in the search entry in the overview
if the user's input will be appearing elsewhere, such as in the run dialog,
in the Looking Glass console, or in the notification's response field.
Add _st_actor_contains() in st-private for use within St, and
monkey-patch in a Clutter.Actor.contains() for use by javascript, and
then replace all the duplicate implementations with one or the other
of those.
https://bugzilla.gnome.org/show_bug.cgi?id=621197
As the design calls for smooth transitions whenever possible, use
a similar fade effect for the all-apps and more-docs menus as for
the panel menus.
https://bugzilla.gnome.org/show_bug.cgi?id=620775
As the search entry captures the pointer when activated, the hover
state is not updated properly when the activation is cancelled
(either by clicking outside the entry or by hitting Escape).
Update the state manually in these cases.
https://bugzilla.gnome.org/show_bug.cgi?id=611095
When dragging windows in linear view, the workspace zooms out to
allow moving the window to other workspaces. Enable the same
behaviour for items dragged from the dash.
https://bugzilla.gnome.org/show_bug.cgi?id=618055
