For Firefox/OpenOffice, right now we have a workaround in the
code where we look at their "title" property. However, we
weren't monitoring that property for changes, and I'm fairly
certain Firefox at least was mapping a window and then very
quickly changing its title after. So we need to handle
dynamic changes.
Split out the wm_class mapping from the title hack. It was
messy and weird to have the two mixed because they're not
at all related, and we're not trying to handle WM_CLASS changes
right now.
Explicitly connect to notify::title in the case where we had
a title fallback. When a title changes, just treat it as
an add+remove.
In the Application Menu area in the panel, hook up to app-added
and app-removed so we get notification of the active app changing.
Clean up the vendor prefix handling a bit, and add "mozilla" so that
we pick up "mozilla-firefox.desktop" from Firefox's (recent?) change
to have a WM_CLASS of "Firefox".
Separate the application monitor logic for "tracking" and "usage tracking".
The first means we associate an application with a window. The second
means we count focus time inside that window, and consider the window
interesting from a user point of view.
(Really, should probably split ShellAppMonitor into two classes along
this line, with the second consuming the first).
For the purposes of counting running applications and returning
the list of open windows for an application, skip not-usage-tracked
windows.
Together this allows us to associate the Nautilus desktop window
with the nautilus.desktop, but not show "File Manager" open all
of the time.
Display only first page of search results by default for each section and
allow clicking on the section header to view all the results for a given
section. This design will allow us to easily move from paging to scrolling
without having to stack multiple scrollbars in a single pane.
Display a total results count next to the section name. This serves as an
indicator that there are more results. The section header pre-lights to
indicate that it can be clicked on.
Make sure we go back to the first page of results when we exit a single
section mode. Make sure we re-instate all result sections if the search
mode is left.
Close the only section search mode on Esc, and only close the search
when Esc is hit again.
We now have functionality in Mutter to grab the keyboard on behalf
of a plugin. This avoids interactions with the key handling code
in Mutter that could leave the user with an inconsistent state
and no way to get out of it.
src/shell-global.[ch]: Change shell_global_grab_keyboard() and
shell_global_grab_keyboard() to shell_global_begin_modal()
shell_global_end_modal() and call mutter_plugin_begin_modal()
mutter_plugin_end_modal() rather than directly grabbing the
keyboard.
main.js: Call global.begin_modal/end_modal from Main.startModal()
and Main.endModal()
altTab.js; Remove call to Main.startModal() - we're letting Mutter
handle modality for Alt-Tab.
main.js lookingGlass.js overview.js runDialog.js: Rename
Main.startModal() to Main.beginModal() for consistency with
naming in mutter and ShellGlobal.
http://bugzilla.gnome.org/show_bug.cgi?id=590686
If Mutter exits with an exit status of 0, then that most likely
means that it was replaced by another window manager and we shoudln't
try to start the previous window manager and the panel.
(We don't actually know about the panel, but assume that if someone
is replacing us they know what they are doing.)
When Mutter exits with a signal, we know we want to restart.
When Mutter exits with a non-signal non-zero exit status, it's
ambiguous - we could be exiting because we lost the connection to
the X server, or because of a assertion failure in gnome-shell.
We assume the latter; if the X server is gone, all that will happen
is a bit of noise.
To know why Mutter exited accurately, we always wait() and
kill() the Mutter process, and then, if running in Xephyr, clean up
Xephyr afterwards. This has the nice side effect of exiting when
gnome-shell does and not forcing the user to close Xephyr manually.
http://bugzilla.gnome.org/show_bug.cgi?id=591171
Display search results in the dash instead of showing them in a separate pane.
We get dynamic allocation for the section height based on the number of
results, but a lot of the problems with the previous search results display,
such as displaying empty sections and paging overflow are still present.
Also, we don't yet close the browse pane for applications or documents when
we display the search results and only replace it if we are showing the
details pane, so all that looks weird. We'll need to work out the interaction
for these cases.
This fixes a bug where we were already using this._hotCorner
in _onHotCornerEnvironsLeft() and were incorrectly setting
this._hotCornerEntered to false when the hot corner was
re-entered from the environs.
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.
Add drag and drop. We need to be able to recreate the icon texture,
so instead of passing it directly into PlaceDisplay, pass
a factory function which knows how to create a new texture.
The design has smaller icons in two columns. Add a new
custom display to docDisplay for it.
Clean up some of the texture cache handling for recent URIs so
it's not size-dependent, since the dash size is now different
from the default GenericDisplay size.
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.
Using a larger area around the hot corner to decide if the user has left the
hot corner prevents triggering the hot corner multiple times due to an
accidental jitter.
We need to use the -lib variant which in turn uses the
GETTEXT_PACKAGE define, because the default translation
domain is actually mutter, not gnome-shell.
$(builddir) is not a standard automake variable. With autoconf < 2.64
it ends up getting set in every Makefile.in to '.' (because autoconf
defines it), but that is no longer the case for 2.64.
Since $(builddir) was always '.', just use that instead.
