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).
visibleInOverview chrome was visible even when the screensaver was
active. Although we may eventually need visibleInScreenSaver, that
should be a separate flag.
Fix this by tracking the screensaver active state, and hiding the chrome
when the screensaver is active.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
Fix the signal handling; you can't use this.connect('ActiveChanged')
to connect to a D-Bus signal after replacing the signal methods with
the lang.signals versions. Just leave it using the D-Bus signal names,
just like it uses the D-Bus method names.
Also, remove the "_" from "_screenSaverActive", to match what
AutomountManager checks for, and remove getActive(), since it's not
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=654550
As _updateCount has been designed to be overwritable by subclasses,
move the check for _actorDestroyed into _setCount(), to fix the
problem described in commit 5f6ac33d5 in derived types as well.
If the resident source is destroyed, it should be recreated
immediately, so that it is available when another volume is
mounted. However, we only connect to the 'destroy' signal
on the original source, not on newly created ones. As a result,
the resident source only works twice, after that it shows up
without icon and an empty notification.
Fix by always connecting to the source's 'destroy' signal.
When trying to update the message count after a summary icon has
been destroyed, the label to display the count is no longer valid
and trying to set its text results in some Clutter warnings.
Basically do what NautilusPlacesSidebar does with the drive/volume/mount
eject/unmount/stop priorities.
We follow this pattern:
- always prefer Safely Remove if available (i.e. drive.stop())
- fallback to ejecting the mount/volume/drive if that's not possible
- finally, fallback to unmounting the mount if even eject is not
available
This also means we don't care about the distinction between
Stop/Eject/Unmount at this level. Disk Utility (or Nautilus) are
available for those who want that degree of control, but the common case
here should do the most useful action without presenting the choice.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Ideally, this would be an entirely-JS implementation, but we have a
couple of issues with gjs and gobject-introspection to work around, so
we need a ShellMountOperation class for the time being.
This first commit implements the show-processes dialog, with a system
modal style very similar to the EndSession dialog.
Implementations of ask-question and ask-password will follow shortly.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
If possible, use the results from the sniffer process in order to have
less-generic alternatives to the file manager in the proposed autorun
choices.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
Autorun preferences can be fine-tweaked at the content-type level from
the System Settings 'Removable Media' panel.
Use those settings to figure out the default action for newly-mounted
mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
The AutomountManager class is the low-level counterpart of the
previously introduced AutorunManager, and takes care of extracting the
list of valid mounts from a GVolume or a GDrive and mounting them,
provided a number of conditions and requirements are met.
AutomountManager also keeps track of the current session availability
(using the ConsoleKit and gnome-screensaver DBus interfaces) and
inhibits mounting if the current session is locked, or another session
is in use instead.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
AutorunManager is a class that takes care of displaying and managing
notifications and UI for storage devices.
When a mount appears and a number of conditions are satisified, a
transient notification will be displayed to immediately interact with
the device. AutorunTransientDispatcher is the object that takes care of
showing/hiding the notification sources as devices appear/disappear.
Likewise, current mounts are kept in a list and presented within a
list in a resident notification, handled by AutorunResidentSource.
https://bugzilla.gnome.org/show_bug.cgi?id=653520
On error, we tried to kill and respawn gnome-power-manager, but
as of commit c5676900 the DBus interface provided by g-s-d's power
plugin is used, so the respawning does not have any effect.
https://bugzilla.gnome.org/show_bug.cgi?id=654300
When one of the networks in the main menu is removed and we have
a More... submenu, we can take the first out from the submenu and
show it in the main menu.
https://bugzilla.gnome.org/show_bug.cgi?id=647175
This is needed if we are handling an incoming text channel and then user tries
to open a chat with the same contact using Empathy. In this case, the Shell
should delegate the channel back to Empathy and just continue observing it as
it does for usual outgoing channels.
Depends on telepathy-glib 0.15.3 as
tp_base_client_set_delegated_channels_callback() has been added in this
version.
https://bugzilla.gnome.org/show_bug.cgi?id=654237
Due to an accidental addition line in commit c8670819, all switches in popup
menus accidentally gave the appearance that they were turned off.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
https://bugzilla.gnome.org/show_bug.cgi?id=654267
We don't want sources that are no longer associated with a running application
to stick around in the message tray.
Message tray sources were removed when the associated application’s state
changed to Shell.AppState.STOPPED . This caused sources for applications
that were still running, but did not have any open windows to be removed.
Instead, we should use the notification’s sender removal from DBus as an
indicator for when to remove the associated source from the message tray.
https://bugzilla.gnome.org/show_bug.cgi?id=645764
If we're typing we want to send composing. If we empty the entry we
want to send active. If we're typing but don't type any more for
COMPOSING_STOP_TIMEOUT seconds, we want to send paused. Simple.
This behaviour was stolen from Empathy where it has won many awards.
https://bugzilla.gnome.org/show_bug.cgi?id=650196
Based on patch from Jonny Lamb <jonnylamb@gnome.org>
Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
Commit 64b2b4a7d4 changed the monitor layout handling, resulting
in some layout errors due to a subtle change in memory handling:
when zooming a window in the overview, the available zoom area is
calculated by subtracting the panel height from the primary monitor
area. This area used to be a copy of the monitor rect, but as now
the rect itself is returned, zooming a window on the primary monitor
repeatedly modifies the monitor rect, leading to layout errors in
various parts of the shell.
Fix by using a copy when calculating the available zoom area.
https://bugzilla.gnome.org/show_bug.cgi?id=654105
