Currently, activating a search result always opens a new window. Change
this behavior, so that if an application has open windows, the most
recently used one is activated instead.
Also change the implementation of dnd of search results to allow providers
to treat results activated via dnd differently.
https://bugzilla.gnome.org/show_bug.cgi?id=610027
We need to return the "thing that is being dragged" from
getDragActorSource() so that dnd.js can figure out the right
relationship between the dragged object and cursor.
https://bugzilla.gnome.org/show_bug.cgi?id=607351
Matching the 20091114 mockup, the default workspace view
is now a scrollable horizontal list, with a control to
switch between this and the previous grid view.
https://bugzilla.gnome.org/show_bug.cgi?id=593844
Make the event blocking done by Lightbox optional - leave it activated
when displaying the run dialog, but deactivate it when highlighting
windows in the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=602774
The high level goal is to separate the concern of searching for
things with display of those things; for example in newer mockups,
applications are displayed exactly the same as they look in the
AppWell.
Another goal was optimizing for speed; for example,
application search was pushed mostly down into C, and we avoid
lowercasing and normalizing every item over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
The distinction between the inactive and running was silly; just
have one class which can handle both running states. However for
a future search patch, we do want a separation between an icon which
just has icon + name + glow, and a well icon which does the menu
integration.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
Previously we had various things watching for notify::mapped so
we could be more lazy about updating non-visible actors, but it
was fairly ad-hoc.
The deferred work system unifies these callbacks, and also adds
a timeout so that we don't delay changes arbitrarily; this way we
avoid a storm of work if you stay out of the overview for a while,
then go in.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
The altTab.js and app well code weren't sharing really
any functionality anymore; un-merge the appIcon code back
into appWell, and have a simple icon + text display for
altTab.
Port AppWell to St and CSS.
https://bugzilla.gnome.org/show_bug.cgi?id=602131
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
Previously, we had ShellAppInfo, which contains fundamental
information about an application, and methods on ShellAppMonitor
to retrieve "live" information like the window list.
AppIcon ended up being used as the "App" class which was painful
for various reasons; among them that we need to handle window
list changes, and some consumers weren't ready for that.
Clean things up a bit by introducing a new ShellApp class in C,
which currently wraps a ShellAppInfo.
AppIcon then is more like the display actor for a ShellApp. Notably,
the ".windows" property moves out of it. The altTab code which
won't handle dynamic changes instead is changed to maintain a
cached version.
ShellAppMonitor gains some more methods related to ShellApp now.
In the future, we might consider changing ShellApp to be a GInterface,
which could be implemented by ShellDesktopFileApp, ShellWindowApp.
Then we could axe ShellAppInfo from the "public" API and it would
return to being an internal loss mitigation layer for GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=598227
When we get a ClutterModifierType from Clutter, it might contain
bits not in the enumeration. See bug 59771 for a similar problem
with GdkModifierType.
Add a wrapper Shell.get_event_state() around clutter_event_get_state()
to mask these bits out and only return approved bits.
https://bugzilla.gnome.org/show_bug.cgi?id=597735
Being able to display all applications in a category based on the search
string with a category name is generaly useful.
Prepare all the applications that match a search term based on their
category name up-front.
Remove unused this._appCategories and a call to non-existing
itemInfo.get_categories()
Add a "size" parameter to allow changing the AppIcon size, and then
simplify the constructor by taking an object with parameters like
gobject-introspection constructors do, rather than taking a large
number of miscellaneous arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=597498
For some unknown reason we were connecting to app-added and
app-removed on ShellAppMonitor in the AppDisplay class, which
never made any use of the data. Simply don't connect to those
signals for now. In the future we should have AppDisplay
be using the AppIcon class which will more correctly handle
dynamic changes.
In the AppWell, avoid doing the full relayout until we're
actually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=597169
Also have inactive applications pop up a menu.
Add/Remove from favorites is now in the menu.
Concatenate the favorites/not-favorites instead of having a gap only
if you happened to have a not-divisible-by-4 number of favorites.
https://bugzilla.gnome.org/show_bug.cgi?id=596371
Fix displaying documents in the document browse and refreshing the selection
when the results have changed.
Make sure we are passing the appropriate flag to _redisplay() in GenericDisplay.
Make sure we set this._appsStale to true if there was a change in the
applications set.
Don't call _refreshCache() from the AppDisplay constructor.
Don't short-circuit the call to _refreshCache() from _redisplay() on initial load.
Rename _redisplayFull() to recreateDisplayItems() and remove adding an
actor to the actual result list in _addDisplayItem() because we redo adding the
actors to the list in _redisplayReordering() anyway to ensure that we add
them in the right order.
Based on a patch from Colin Walters.
Unlike icons in the application well, do not show the glow used to
indicate running apps. It is somewhat redundant here. These are all
running apps and it is fairly clear from the window list if there are
multiple instances available, according to mccann.
https://bugzilla.gnome.org/show_bug.cgi?id=590563
- Add spacing after Frequent, reduce it for the other app categories.
Put a small gap (one line) between Frequent and the other
categories to make it clear that it is something a little
different.
- Remove category icons from the applications menu.
Remove category icons; they aren't particularly helpful
(they are gone from the GNOME-2.28 menus too) and having them
in Applications Browse draws the eye to the wrong thing - the
category - rather than the right thing - the application icons.
https://bugzilla.gnome.org/show_bug.cgi?id=596435
There are now 3 code paths in decreasing speed:
First, optimize subsearching more by just hiding the actors
that didn't match, since we know the ordering has to be right.
For initiating a search (or backspacing an existing one), again
instead of destroying and recreating actors, just temporarily
remove them and re-add them in the desired order.
Finally for when data has changed, use the old code path of
destroying all actors. (This itself could obviously be optimized
if we had a way to know that just one application changed, but
at the moment we don't).
https://bugzilla.gnome.org/show_bug.cgi?id=596119
First eliminate the variable WELL_ITEM_HSPACING since it was 0
and thus effectively was not used.
Add a new variable WELL_ITEM_MIN_HSPACING which is the minimum
space between grid items we allow. When computing layout, allow
for a number of columns less than 4 by using the minimum item
size.
https://bugzilla.gnome.org/show_bug.cgi?id=595023
Based on a patch from Colin Walters.
The menu is needed by the app switcher as well as the overview, so
make it slightly more generic and move the code to appIcon. Also add
support for drawing the menu either to the right of or below the icon.
https://bugzilla.gnome.org/show_bug.cgi?id=590563
Refactor the current menu code to support both window selection
and "normal" menu items. Add a "New Window" item which does what
you'd expect.
Clean up the way we handle highlighting the window items to be
more direct; rather than looping over all items in most cases,
just directly manipulate one item
https://bugzilla.gnome.org/show_bug.cgi?id=594557
When we had a filtered set of windows, and want to exit the overview
into a particular window, what we do is re-show all the old windows
first, but don't reset the scaling on them. This will involve
some overlapping, but that's not a big deal because we'll immediately
get overlap anyways in the normal case zooming the windows back.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
Callers will generally expect _popup and _popdown to be a no-op if
the menu is already in that state; make it so.
Also change the 'popdown' signal to be 'cancelled'; this is
clearer and allows us to avoid having activate also call popdown.
https://bugzilla.gnome.org/show_bug.cgi?id=594699
When the user click+hold+release over the icon, the effect we want
is for the menu to stick around.
Also, allow the user to mouse over the actual windows and select
them directly. If the user mouses over a window, reflect that in
the menu.
Rather than starting lightboxing only when the mouse enters the
menu, start it when an application filter is set.
Also delete a stale function in WindowClone from previous work.
http://bugzilla.gnome.org/show_bug.cgi?id=594555
When we have multiple windows for an application, implement the following
behavior:
* On click + immediate release, go to the most recently used
* On click, hold for 0.6s, pop up a menu with windows, filtering
the window list to just those windows.
Mouse over on the window list highlights the moused-over window.
Implement this by splitting well item into InactiveWellItem
and RunningWellItem, sharing a base class BaseWellItem.
Rather than just launching if we weren't already running, always
relaunch, which happens to make Firefox, etc. work. See
the comment in the commit for more explanation.
We had multiple copies of the code to position a drag actor given a particular
source. Instead, just put it inside dnd.js.
Second, rather than test for GenericDisplay/WellDisplayItem etc.,
in various places, add a new method on each source "shellWorkspaceLaunch"
which both marks the item as being droppable on a workspace, and is
called by the workspaces code to launch the item.
Use MetaGroup for a window when looking up applications. If
we know the application for a TYPE_NORMAL window in the group,
use that.
However, we aren't always going to know the application for a window. In
that case, create a fake one.
ShellAppInfo has a "transient" flag so we know not to write these
fake apps to the usage file.
Clean up the idle focus handler to better handle the case where
no window is focused, and where we don't want to track the
particular window.
Update track_window to create the fake window.
When a window goes away, we want to delete the usage.
Rewrite shell_app_monitor_get_running_apps to be based
on the window_to_app hash, because that's what has the pointer
to ShellAppInfo*. Before we were looking up all ids through
ShellAppSystem, but that shouldn't be holding a ref to transients.
Change the well display icon to be centered, since our icons for
window apps aren't 48 pixels.
We don't have a lot of strings, and what ones we do have we've
been avoiding duplication. This patch adds calls to _() i.e. gettext
for those strings we do have.
Remove the last use of passing width into Dash by having the
Pane with the previews scaling dynamically and relying on
Clutter scaling.
If we only have one workspace, don't display a selection frame
for it.
Rework Dash into a searchArea and sectionArea, which get
explicitly sized by overlay.js. We use the workspaces size
to choose the size of those dash areas.
Switch dash colors/boxes etc. to ones from shell-black02.
Add a gradient to the panel.
Add a magnifier.svg for use in search.
Replace 'overlay' with the more descriptive name 'overview'
where the Activities Overview is meant. Call it Overview
(capitalized) in code comments.
The overlay-group and overlay-key provided by Mutter are not
affected, since they may be used for other components than
the Activities Overview.
Previously, ShellAppSystem only loaded (and cached) the set of
.desktop files from applications.menu and settings.menu, using
the gnome-menus library. The ShellAppInfo structure was
a "hidden typedef" for GMenuTreeEntry.
But we need to support loading an arbitrary .desktop file. Thus,
refactor the ShellAppInfo into a real struct, with a refcount,
and allow it to point to either a GMenuTreeEntry or a GKeyFile.
Also, in the case where we fail to lookup an icon for an
application, ensure we return a 0 opacity texture.
When WellGrid had no child it was doing a division by zero,
which screwed up the calculation for the height request and
having it ask for a negative number. This commit fixes this
by always requesting 0 in this case.
Use ShellGenericContainer to implement a fully dynamic layout
for the application well. It's still fixed to 4 columns by default,
but no longer requires a fixed width to be passed in on start.
With another chunk of work, it could likely try to adjust to
the case where we can only fit fewer than 4 items in the well.
Remove the border highlighting on mouseover, since that caused
reallocations, and the grid layout isn't trivial.
Delete the unused shell_global_get_word_with function.
It's easier to explicitly call Main.overlay.hide() instead
of chaining activation signals, this got lost in a mix between
the big dash rewrite and ongoing changes to the Application well.
This patch is a near-total rewrite of the Dash. First, the dash
code moves into a separate file, dash.js.
Inside dash.js, the components are more broken up into separate
classes; in particular there's now a Pane class and a MoreLink
class. Instead of each section of the dash, when activated,
attempting to close all N-1 other sections, instead there
is the concept of a single "active pane", and when e.g. activating
the More link for documents, if we know there's an active pane
which happens to be the apps, close it.
Many redundant containers were removed from the dash, and all
manual width, height and x/y offsets are entirely gone. We move
the visual apperance closer to the design by using the view-more.svg,
etc.
To complete the removal of height/width calculations from the dash,
we also had to do the same for GenericDisplay. Also clean up
the positioning inside overlay.js so calculation of children's
positioning is inside a single function that flows from screen.width
and screen.height, so in the future we can stop passing the width
into the Dash constructor and call this once and work on screen
resizing.
The previous application monitoring code was originally designed
to be based on WM_CLASS, which was then resolved on a server.
We have that resolution code locally now, so instead
of saving WM_CLASS data, save application IDs.
Also, inside the WM we have a much better
infrastructure for tracking windows. In particular, rather
than polling, we can just watch for focus notification on
the display, and window add/remove.
Instead of polling XScreensaver, use DBus to watch org.gnome.Session
which already has an idle time watch.
Now there is no polling at all inside the monitor.
We had duplicate code in appDisplay and workspaces for handling activating
a window; unify that inside workspaces, add an API to Main.overlay to
access it from both contexts.
Also, explicitly raise the clone we're activating to the top
before starting the animation to leave the overlay.
Don't use a clone of an actor that's not part of the scene graph for the
item previews. This patch fixes previews in the details pane for documents
for which we don't have full previews and for applications.
Use create_icon_texture() from AppInfo instead of looking up the file
for gicon when creating an application icon for the details pane.
The experiment with avoiding ellipsization was a definite failure;
several translations have very long names, and we'd end up
with a single column.
Also fix extra padding; we only want some space at the top, not
left/right.
Corresponding with the design, if an application is in a running
state (has > 0 windows open), draw a glow behind the name.
To make the display look a bit nicer, set the width of each item
to be equal to the longest word among all the items.
Before, we looked up application data in several ways; the ShellAppSystem
exported just application ids (though it parsed the .desktop files internally),
and we'd create a Gio.DesktopAppInfo object (reparsing the desktop file again),
wrapping that inside a JavaScript AppInfo class, and finally the AppDisplay
would again parse the .desktop file to get the categories.
Also, to look up applications by id previously, we traversed the entire
menu structure each time.
Some qualities such as the NoDisplay flag were not easily exposed in the old
system. And if we wanted to expose them we'd have to change several different
application information wrapper classes.
All in all, it was quite suboptimal.
The theme of this new code is basically "just use libgnome-menus". We do
not call into Gio for app lookups anymore. The new Shell.AppInfo class
is a disguised pointer for the GMenuTreeEntry item.
To fix the caching, we keep a simple hash table of desktop id -> ShellAppInfo.
Rework the previously extant Application category code to display
in the expanded list. Add a "Frequent" category which corresponds
to the most_used_apps, and selected by default.
Instead of adding the background and shadow as expanded items to
the results/details panes as fixed, we slave the background/shadow
sizes to the results using notify::allocation.
Also clean up the code for sizing the details pane, using a common
function which adjusts its x position in one place.
This converts GenericDisplay to totally dynamic layout, where
we display as many items as we can, and the rest cleanly overflow
into pages.
For now, remove multi-column; to readd this, we can pack multiple
display items into a single ShellOverflowList item.
It looks funny to have the "more running apps area" there as a gap
when empty and dragging to it is an unintuitive way to remove stuff
from the favorites list, in any case, so just hide the area when
empty.
http://bugzilla.gnome.org/show_bug.cgi?id=587720
Clutter no longer allows using a clone of an actor that is not a part of
the scene graph. This is what used to happen when we created a clone for
the icon of the item that was being dragged, and then closed the More panes
with the original item, removing the icon from the scene graph. This was
also when happened when the user hit Esc while dragging, which prompted the
overlay to close, removing the original icon from the scene graph.
Rename getIcon() methods to createIcon() to better reflect on the fact that
a new icon is created each time the method is called (we do use cache in
some cases).
Remove a stray log message in overlay.js
Fixes http://bugzilla.gnome.org/show_bug.cgi?id=585490
and http://bugzilla.gnome.org/show_bug.cgi?id=585489
The new class AppWell implements the application favorite well
in the Dash component. The previous AppDisplay remains for use
in the More... mode now.
Delete DEFAULT_APPLICATIONS; this is now in GConf.
Rename getMostUsedApps to getTopApps since we now have the
idea of explicit favorites.
Delete some GenericDisplay-related calls from overlay related
to the seletion - we'll reimplement keyboard nav in a more
coherent way later.
The list of all applications was based on the items that show up in
the menus, and might not have contained all applications returned
by the AppMonitor for the most used applications request. One example of
such an application was Evince. This resulted in a crash when an
application we did not prepare the info for was returned as one of the
matches by the AppMonitor, so we now include all applications returned
by the AppMonitor in the list, in addition to the ones from the menus.
Also mark apps as stale when we catch a "changed" signal from the AppMonitor
to ensure that the cache is refreshed.
With commit a3d35af444 variable
itemInfo in js/ui/appDisplay.js was changed to a new object
(AppInfo from js/misc/appInfo.js) but some of the code in
js/ui/appDisplay.js wasn't updated accordingly. This commit
fixes that and makes the search box in the overlay usable
again.
This lets us share the recent-app-tracking, recent-file-tracking, and
icon-drawing code between the overlay and the sidebar, without the
sidebar having to poke into AppDisplayItem and DocDisplayItem's guts.
The code here is significantly cleaner if we use the data Metacity
already has cached and validated, rather than talking to X directly.
Also some preparatory work for extending the monitor API by
clarifying the name of the (current) main entry point.
