Use the existing setting
org.gnome.desktop.default-applications.office.calendar.exec
as calendar application instead of the hard-coded evolution. Evolution
is still the fallback if that setting is cleared (it defaults to
evolution).
https://bugzilla.gnome.org/show_bug.cgi?id=651190
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
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
The specs call for a 2 pixel gap between the panel and its menus,
though we need to specify this as 4 pixels, since it's relative to the
bottom of the icon/title, not the bottom of the panel (up until now,
the point of the menu arrow was actually overlapping the menu's
highlight underline).
Also, move the gap specification into the CSS, since it makes more
sense there.
https://bugzilla.gnome.org/show_bug.cgi?id=655627
Since this link in the keyboard menu points to Region and Language
Settings in System Settings, we should be consistent and use that
term instead of "Localization Settings"
Also, this removes ellipsis from "Show Keyboard Layout" since it
doesn't require further input.
https://bugzilla.gnome.org/show_bug.cgi?id=652984
The current check for fullscreen windows ignores the window's
minimization state, so that chrome which is hidden in fullscreen
will always hide if the window on top of the window stack is
fullscreen, even if it is actually minimized.
Instead, skip minimized windows when looking for fullscreen windows.
https://bugzilla.gnome.org/show_bug.cgi?id=655446
_fixMarkup() was supposed to be ensuring that the markup we passed to
clutter was correct, but it was validating the syntax incorrectly, and
wasn't checking that the markup was valid (or even well-formed). This
is bad because if you pass bad pango markup to
clutter_text_set_markup(), it will g_warn and drop the string on the
floor.
Fix by fixing up the regexps, and then calling Pango.parse_markup() on
the result, and just xml-escaping everything if parse_markup() fails.
https://bugzilla.gnome.org/show_bug.cgi?id=650298
Keeping the volume menu open after setting the desired volume isn't that
useful and forces a second click (or an Esc press) to dismiss it. Allow for
the sliders to be used with a single click-hold-move-release.
https://bugzilla.gnome.org/show_bug.cgi?id=649586
Move the HotCorner class from panel to layout, and make the panel
manage its own HotCorner.
Stick the panel's HotCorner into the Activities button actor (rather
than separately floating above it), so that hover tracking on the
button works properly without needing hacks in HotCorner.
https://bugzilla.gnome.org/show_bug.cgi?id=645759
The fact that everything in the top bar except the activities button
was a menu made various things difficult. Simplify this by making the
activities button be a menu too, but just hack it up a bit so that the
menu associated with the button never actually appears.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=645759 (Clicking on
Activities with menu up leaves a funny state) and its semi-dup 641253
(panel keynav between Activities and menus is quirky).
