As danw points out,
"It's unique during the lifetime of the window, but reasonably likely to be
reused by another window after this one is destroyed. Using
meta_window_get_stable_sequence() might be better."
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
Add a helper function (mostly copied from gtkcalendar.c) for getting
the first week day for the current locale, using nl_langinfo if
available and falling back to the GTK+ gettext fallback otherwise.
Use that function in the calendar, so that the LC_TIME setting is
used if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=649078
Instead, create three ripples and keep tweening them. This gives a dramatic
speedup when entering the overview, but means that we can't have the same animation
running twice. In this case, we "reset" the currently running ripple animation, but
it is hard to notice unless looking for it.
https://bugzilla.gnome.org/show_bug.cgi?id=656125
Extension developers may be confused about why their extensions aren't working:
the LookingGlass isn't a very obvious place, or even which errors are theirs.
To remedy this, save all errors per-UUID which allows them to be retrieved
later.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
Add ShellVersion, designed for detecting OUT_OF_DATE extensions so they can't
be installed, as well as ApiVersion, designed for backwards-compatibility with
the SweetTooth web-app, which must support all shell versions.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
GetExtensionInfo() takes a UUID and returns a JSON object with information
about that extension including their metadata, path and current state.
ListExtensions() takes no arguments and returns a JSON object mapping UUIDs
to the same information objects described above.
https://bugzilla.gnome.org/show_bug.cgi?id=654770
As an effort to prevent a string freeze to land timestamps on 3.0, we reused
translations for the calendar. Now that the string freeze is long gone, make
some proper strings.
https://bugzilla.gnome.org/show_bug.cgi?id=640271
The notification spec supports the concept of a 'default' action:
"The default action (usually invoked my clicking the notification)
should have a key named "default". The name can be anything, though
implementations are free not to display it."
Support this by invoking the 'default' action rather than a emitting
the 'clicked' signal when clicking notifications which specifie a
default action.
Also don't add an action button for the default action.
https://bugzilla.gnome.org/show_bug.cgi?id=655818
LayoutManager and Chrome are already somewhat intertwined and will be
becoming more so. As a first step in merging them, move the Chrome
object into layout.js (with no other code changes).
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Looking Glass is supposed to slide out from underneath the panel.
Rather than fiddling with Main.chrome.actor directly, just add the lg
actor to the chrome, and fix its stacking there.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
With the old pre-boxpointer summary notifications, it sort of made
sense that the summary notification actor was a child of the message
tray. But there's no reason for that now, and in fact, it ends up
requiring special cases in some places since hovering over the summary
notification counts as hovering over the tray. So, fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
Rather than having the panel corners as independent bits of chrome and
manually syncing their positions, put them inside the panel actor, and
update the panel's allocation code to position them correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=655813
If a container is not clip-to-allocation, then its get_paint_volume()
needs to include the paint volumes of all of its children, since they
(or their children) may paint outside the container's allocation.
Also, if the superclass get_paint_volume() returns FALSE, then the
subclass should return FALSE too.
https://bugzilla.gnome.org/show_bug.cgi?id=655812
MetaPlugin wraps a bunch of compositor (and plain metacity) methods
that we can just call ourselves, so just do that. (Presumably this
dates back to some ancient time when it was imagined that plugins
wouldn't need access to the full metacity API.)
https://bugzilla.gnome.org/show_bug.cgi?id=654639
Rather than constantly asking mutter for the MetaScreen, and then
figuring out the MetaDisplay/Display/etc from there, just keep track
of everything we care about inside ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=654639
The buttons should have a glassy transparent look. Also, they should not
be as tall, should light up on hover, and their labels should be white
in order to stand out. Making the labels solid white requires removing the
transparency set in modalDialog.js. Also, add a separate color setting
for the dialog as a whole - this avoids having a white icon.
https://bugzilla.gnome.org/show_bug.cgi?id=655428
When porting to the new gnome-menus API in commit 8f3bdd4f1, the
initial loading of settings apps was left out, so settings panels
are neither found nor can be launched from the top panel menus.
