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.
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.
Pass the error variable to g_key_file_load_from_data_dirs in
Shell.AppSystem.get_default().load_from_desktop_file again, and
use a try/catch in places.js.
This fixes Shell.TextureCache.get_default().load_thumbnail so
that it can be used to get thumbnails (with an icon matching
the mimetype or, in the worst case, gtk-file, as fallback) for
items which don't have a GtkRecentlyUsed object. This is needed
for the Zeitgeist integration.
- Avoid error '"iconname" may be used uninitialized in this function'
by initializing said variable to NULL.
- Define shell_util_get_file_description as static (like the other
similar functions) to avoid another compiler error.
- Don't save errors from g_key_file_load_from_data_dirs into the
variable "error" (ie. pass NULL to it instead). Without this,
gnome-shell crashes if the key file can't be found (with message
"Error invoking Shell.load_from_desktop_file: Valid key file could
not be found in search dirs").
- Check the result of the load_from_desktop_file() call in places.js,
as it may be null.
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.
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.
For both of these, because of optimizations a few patches ago, we
ended up relying on hash table ordering which caused instability
in the application well among other things. Define an ordering
for both.
The favorites is just the order of the GConf keys, and new items
get appended. In the future we should allow insertion at any
point which the grid could use.
For running applications order, define a new "initially_seen_sequence"
transient variable which is just an monotonically incrementing
integer assigned to an application for the first time we saw it
running in this session. When an application is closed, it's reset.
When exiting from --replace mode, we want to start the new
gnome-panel with a reasonable working directory so that if, you say,
open a terminal from it it doesn't start off in the gnome-shell
directory.
(gnome-shell itself is running in $HOME because mutter changes
directory itself at startup.)
Reported by Mathieu Bridon
http://bugzilla.gnome.org/show_bug.cgi?id=591145
Some C library versions have __attribute__((warn_unused_result)) on
fgets(). We really don't care since we are just throwing the data
away, but check the result anyways.
When AM_SILENT_RULES is available, use it to strip down the output
of make so we can see what's important rather than gigantic long
compile lines.
Use 'make V=1' to see everything again.
Fix a couple of places where we had 'cmp' rather than 'cmp' and were
getting standard-error spew about missing files when generating
enum-types.h files.
http://bugzilla.gnome.org/show_bug.cgi?id=591002
src/shell-global.c src/shell-process.c: Remove dead code
src/shell-texture-cache.c src/shell-status-menu.c: Remove
<foo>_new() functions that weren't in the header file and
not used anyways:
src/shell-texture-cache.[ch]: Fix a prototype that used ()
when (void) was intended.
http://bugzilla.gnome.org/show_bug.cgi?id=590998
Move the GStreamer initialization from the Javascript code into
shell_recorder_init(). This avoids a dependency on the GStreamer
introspection information and will make it easier to drop the
gir-repository module dependency.
Said function in genericDisplay.js was returning the index of the
actor based upon its position in the entire list, while everywhere
else indexes relative to the currently displayed page were used.
This made actions in the details pane break (bug #590949), so I
replace it with a new function in shell-overflow-list.c,
shell_overflow_list_get_actor_index, which is page based.
Subclass ClutterGroup (to avoid having to implement all of dispose,
raise, lower, add, etc.), and have it proxy the allocation requests
out into signals. We have to group up the two out parameters
into a struct unfortunately.
Included example code in the C file source for now.
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.
When we fail to load a texture, make sure we keep it 0 opacity to avoid
a white square. Also this is useful to avoid the square while loading
a texture asynchronously.
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.
Make sure that we calculate the next update time correctly.
Store timeout time instead of the timeout delta, so that it doesn't get outdated.
Create a new callback when the time update happens for the original callback.
Make sure last visited time is updated in the details pane by keeping track
of the description actors created for the detail actors.
Add comments to the new functions.
Avoid depending on gdb for replacing an existing panel, since it
requires debuginfo and gdb installed.
Instead we grab the org.gnome.Panel DBus name, using DBus name
replacement semantics.
Extend ShellTextureCache by adding the concept of a policy, which
we expose to the public API for loading URIs.
This lets us have the shell tell the cache to keep the information
icon texture around forever.
Secondly, fix the caching of recent info; we shouldn't always be
loading the backup pixbuf. Move recent info loading entirely
into ShellTextureCache.
GenericDisplay wasn't quite completely converted to the ShellOverflowList
model. Since the list now holds all actors, the indexing/wrapping
was incorrect.
Add a property which lets us keep track of how many items are displayed,
use this in genericDisplay.
Avoid setting selectedIndex to -2 when going up with no items.
If we're not displaying any results at all, don't attempt keynav (for now).
Make the ClutterText and ClutterTexture from the status menu
button available to JavaScript, and from there improve the
font definition of the user name.
shell-status-menu.[ch]: Add public get_name() and get_icon()
functions that return the user name label and icon
texture, remove the markup from update_name_text().
panel.js: Set the font for the button consistently with that
of the other panel labels.
Move thumbnail creation into ShellTextureCache. It's now asynchronous,
and we cache the result.
Create a DocManager class which keeps around the DocInfo objects between
invocations. This is also where we ensure we remove thumbnails for
recent items not known anymore.
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.
ShellDrawingArea is a size-independent wrapper for a ClutterCairoTexture.
Useful when drawing non-fixed size areas.
ShellStack is a simple container class which holds items
in a completely overlapping Z stack. The main difference
from ClutterGroup is that items will be constrained to
(and allocated) the size of the stack, not getting their
preferred size always.
