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.
The application menu code wants to do a popup after a given timeout
while holding. We can implement that by adding a function to
manually break the grab held by the button box.
Freeze+thaw around the hover and pressed property notification on leave
since handlers may want to depend on the pressed state on a hover
transition.
The windows we considered for both the app monitor and the overview
workspaces were the same, but the code was duplicated once in C, once
in Javascript.
On OpenSolaris /usr/bin/python is 2.4; use AM_PATH_PYTHON to find
a newer Python. (The PYTHON environment variable can also be set
before running configure to override the search.)
http://bugzilla.gnome.org/show_bug.cgi?id=578196
Add .AUTOPARALELL which is my GNU-make fix for projects to specify
that the build is parallel-safe, and to automatically parallelize.
Add a missing dependency on built sources, and specify --libtool
to be safe.
Only mouse button 1 is supposed to activate button controls; other
mouse buttons should do nothing unless there is a context menu.
Checking the click count is important, since double-clicks will
otherwise look like unpaired button presses.
http://bugzilla.gnome.org/show_bug.cgi?id=593504
There's seldom a good justification for connecting to signals on
yourself rather than using the default handler slots in the class.
But in particular using the default handler slots means that
an application can connect to ::button-press-event and get in
before the default handling, to implement a button that does
something on press.
http://bugzilla.gnome.org/show_bug.cgi?id=593503
Add an 'active' property to ShellButtonBox. This allows ShellButtonBox
to be used as a "toggle button". It's up the application to connect
it to the ::activate signal; there's no default handling of this.
(It's seldom that the only time you want to toggle a toggle button
through the user interface, so you need some connection to the backend
data store in any case. Removing the default handling all-together
prevents weird interactions.)
When we have built-in styling for ShellButtonBox the 'active' state
would be one of the elements that would be affect the styling.
http://bugzilla.gnome.org/show_bug.cgi?id=593502
shell-global.[ch]: Add shell_global_display_is_grabbed() that
uses the newly added meta_display_get_grab_op() to check
for existing grabs.
shell-status-menu.[ch]: Add shell_status_menu_is_active() to
check if the menu is popped up. Check for active grabs before
popping the menu up. Use gtk_menu_popdown() rather than
gtk_widget_hide(). Remove an excess gtk_widget_show() and
some excess casts.
panel.js: Check whether the status menu is popped up after button
release, and if it's not popped up, unhighlight the button.
Reported by Nuno Donato
http://bugzilla.gnome.org/show_bug.cgi?id=593362
gnome-shell.in: Remove the code to replace gnome-panel by attaching
to it with GDB; this was always problematical (required gdb, debug
symbols, finding the pid of gnome-panel, etc.)
gnome-shell-build-setup.sh: Require 2.26 to be in place before building
the shell; remove gdb from the list of required packages.
http://bugzilla.gnome.org/show_bug.cgi?id=593325
This is a Box subclass which adds several signals useful for implementing
"button like" behavior, such as hover and pressed states, as well as
click activation on release.
Instead of starting Xephyr automatically, require --xephyr to be
passed explicitly.
This makes the operation easier to understand and has the benefit
of allowing running in Xephyr mode when some other window manager
(like gnome-shell!) is running. We also want to emphasize that
Xephyr is a development tool, and not a good preview of the
user-interface.
http://bugzilla.gnome.org/show_bug.cgi?id=592881
In both, using our allocation directly for the child is wrong; we
should create a new allocation that's our width and height.
In ShellDrawingArea, also need to chain up to parent.
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.
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
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.
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 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.
Infrastructure for localization; hook up intltool, create po/
and po/POTFILES.in. We need to call bindtextdomain/bind_textdomain_codeset.
Switch to gnome-autogen.sh to call intltool.
If we pass in -1 for both width and height, we'd attempt
to scale the image to 0x0. Don't do that; just avoid
scaling the pixbuf and let ClutterTexture do it for us.
Because of a history of cut and paste, the different enumeration
and marshal generation generation shell snippets were using the
same temporary file names. This caused problems for parallel
builds.
http://bugzilla.gnome.org/show_bug.cgi?id=591474
This is a start at the "Active Appliction Item" component of the
shell design. Currently we just show the currently focused
application. When launching a new application, we show that as well.
The implementation here is not complete; basically when launching
we de-focus the active one, and the application well shows the
most recent startup sequence.
This kind of fails in the case of multiple sequences, and we
also don't correctly de-focus the current window in other
launch paths.
