Pop up a dialog when trying to install an extension so that users are aware
they are installing one. This is a security precaution in the case that an XSS
exploit has been found on the website, which could cause someone to inject a
<script> tag and silently install an extension.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
libsoup won't check for a valid cert by default, so copy some logic from
glib-networking to check against the system cert list. Additionally, allow a
fallback for developers, ~/.local/share/extensions.gnome.org.crt, for easy
local development of the website.
https://bugzilla.gnome.org/show_bug.cgi?id=658870
For those who like their system pure, this provides the ability to purge a
pesky extension and its precious place on your disk space, and in your
"Local Extension" list.
https://bugzilla.gnome.org/show_bug.cgi?id=658612
Conflicts:
js/ui/extensionSystem.js
This ensures that we don't show an animation of an empty blob being hidden when
clicking an action button causes the notification to be destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=658525
The session list is supposed to hide itself if
1) the user is already logged in
2) there is only one xsession file installed
There was a bug causing 2) not to work.
This commit fixes that bug.
https://bugzilla.gnome.org/show_bug.cgi?id=658423
findUrl() was seeing strings like "You have 1 new message in
foo@example.com/Inbox" and finding the URL
"[http://]example.com/Inbox". Require that URLs either start at the
start of the string, or are preceded by whitespace or an open
paren/quote/etc.
(Since JS doesn't have look-behind assertions like perl does, we have
to actually match the URL-preceding character in the regex, and then
adjust the result findUrl returns accordingly.)
https://bugzilla.gnome.org/show_bug.cgi?id=636252
Although "x:5" could theoretically be a URL with scheme "x" and path
"5", it probably isn't. Only URLify strings that use the "authority"
syntax ("foo://"). (No one ever types out "mailto:" URLs in ordinary
text, so we don't want to match those either.)
https://bugzilla.gnome.org/show_bug.cgi?id=636252
Explode the regex onto multiple lines, and add comments explaining the
pieces. Also, change ()s to (?:)s (non-capturing groups) where
appropriate, and replace the UTF-8 characters with \u escapes so that
they actually work.
https://bugzilla.gnome.org/show_bug.cgi?id=636252
When the keyboard is configured, make lg shorter (if necessary) to
avoid overlapping it.
Also, make a few simplifications to lg's layout code. In particular,
move it into panelBox, to simplify its interactions with the panel.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The keyboard and tray need to animate together, but they sometimes
need to be in different stacking layers (eg, from the screensaver you
want access to the keyboard, but not the tray). So remove _bottomBox
and just keep trayBox and keyboardBox lined up manually.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Rather than having a single chrome layer and putting all of the chrome
into that, put the chrome actors directly into uiGroup, so that they
can be stacked independently of one another relative to other actors.
(This requires making uiGroup a ShellGenericContainer, so we can use
skip_paint to avoid painting non-visibleInFullscreen chrome when we're
in fullscreen.)
https://bugzilla.gnome.org/show_bug.cgi?id=657986
The struts were being set while the panel was offscreen (starting its
slide-in animation), and then belatedly getting fixed the next time
something else caused a chrome update. Fix this by setting them before
the animation, and freezing them during the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=657986
Force an allocation at thumbnails creation so we can figure out whether we
need to scroll when selecting.
We also need to show() the whole AltTabPopup before calling _select() so that,
when computing the scrolling offset, the widgets already have their styles
loaded. Otherwise we will miss the switcher list item container's spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=655069
At least for the foreseeable future, the gnome-session desktop
presence won't be used for anything but suppressing (non-urgent)
notifications. To clarify this behavior, rename the "Do Not Disturb"
switch to "Notifications" (and adjust the switch logic accordingly).
https://bugzilla.gnome.org/show_bug.cgi?id=652718
This patch fixes the "apps vanish from alt-TAB bug".
If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...). In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.
In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.
What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance. This ensures we preserve any state such as the
set of open windows.
This requires moving the running state into ShellAppSystem. Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.
This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation. As long as
we're on top of random broken tar+wget wrappers, it will be gross.
A slight future improvement to this patch would add an explicit
"merge" between the old and new data. I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=657990
As extensions are now expected to provide a "disable" function,
they need to remove search providers they added. Implement the
removal functionality and add a public removeSearchProvider()
method.
https://bugzilla.gnome.org/show_bug.cgi?id=657548
We keep track of presence changes by connecting to the
Tp.AccountManager:most-available-presence-changed signal.
However, if multiple accounts are in use, telepathy may
lie to us and emit the signal even when the most available
presence is unchanged.
Work around this by keeping track of the current presence
ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=657703
Some search providers may want to change their results, or may not
want to block on an external service to get their results (DBus, etc.)
Set up an infrastructure to allow search providers to add their search
results at a later time.
Based on a patch by Jasper St. Pierre and Seif Lotfy.
https://bugzilla.gnome.org/show_bug.cgi?id=655220
This adds contacts search to shell, powered by libfolks.
Changes:
- Add Folks and Gee to the build system
- ShellContactSystem, a backend in C
- ContactDisplay, search frontend in JS
https://bugzilla.gnome.org/show_bug.cgi?id=643018
The current user status menu allow to set the session status,
which also influences the IM status when signed in with
mission-control. However, the way it is presented to the user
makes it hard to figure out how the statuses interact or that
there are two distinct status in the first place.
Therefore, use a separate control for each status, and update the
overall look to match gnome-contacts.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
Given that our menus contain at most two columns, all switch widgets
in menus end up in the last columns, and thus aligned with the right
menu edge.
However, the updated user status menu will contain a section which
ignores the menu's column layout, so the switch might end up in
the middle of the menu if the overall width is determined by said
section.
At least for now, we always want the switch to align with the end,
so just expand switch menu items rather than adding an option.
https://bugzilla.gnome.org/show_bug.cgi?id=652837
