Before, if the texture cache received a request to load say
the themed icon for an application multiple times (as could happen
since we have multiple application displays), it would often create
a thread for each one and in fact, load the pixbuf multiple times.
Avoid this by keeping track of outstanding requests.
https://bugzilla.gnome.org/show_bug.cgi?id=596121
This fixes a regression where we weren't using the correct event
timestamps, because for both of these we were sending an XClientMessage
to ourself.
https://bugzilla.gnome.org/show_bug.cgi?id=596262
A previous patch fixed a leak when loading items which shouldn't
be cached, but we also had a leak if two requests for the same
item were outstanding. In that case we load the pixbuf twice,
but should discard subsequent loads when we notice we've already
cached it.
https://bugzilla.gnome.org/show_bug.cgi?id=595321
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
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
We have compatibility code which detects from the window title what
an application is. However, the code didn't handle the case where
we discovered by title, but didn't have the expected .desktop file
installed.
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.
If start_shell() threw an exception before, we'd overwrite it with
an exception in the finally() clause. Handle this and just print a message
and let the exception propagate.
Before Clutter gained accessors for event information, we had
shell_global_ functions. Now that Clutter has them, use them and
delete the ShellGlobal code.
http://bugzilla.gnome.org/show_bug.cgi?id=594561
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.
