Now that the ::initiate signal may contain the PID of the initiating
process, we can try to resolve it to an application and use that to
indicate where a request originated. This should work for well-behaved
applications that only ask for permissions in response to a user action,
but unfortunately not when it would be most useful, that is when the
dialog is triggered "out of nowhere" by a background service ...
https://bugzilla.gnome.org/show_bug.cgi?id=688351
It is not always clear what triggered a particular polkit request, so
displaying more information to the user is desirable. Unfortunately
the information provided by polkitd is rather sparse, and is usually
limited to subject- and caller PID. Still that's better than nothing,
so include the PID of the initiating process in the signal parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=688351
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
If a clone gets destroyed before the corresponding MetaWindow is
removed from the workspace, we will still find it in the list of
clones and try to destroy it again. Avoid the resulting warnings
by updating the list of clones immediately when a clone is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=791233
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This may be the case where keyboardIndex is -1, which may be the
case where either the keyboard monitor hasn't been set yet, or
the keyboard is being unmanaged and meta_window_get_monitor
returns -1
https://bugzilla.gnome.org/show_bug.cgi?id=788882
The default keyed_surface is meant to handle CoglTextures thus we can't
add cairo surfaces to it, as the DestroyNotify function won't handle them.
Then the quicker way is to just add another Hash table for handling
such types of textures, with proper destroy function.
This might cause a crash when cleaning up the cache as the hash table has
cogl_object_unref as DestroyNotify function but that assumes that
the passed object is a valid CoglObject.
Fixes: #210
In places where numbers appear in columns (like the calendar widget) or
where changing numbers would result in labels jiggling around due to
small width changes (like the clock), use the newly added
font-feature-settings support to request tabular figures.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/34
When middle-clicking an app icon on the Dash, it will always try to open
a new window of that app, even if the app doesn't support multiple
windows. Meanwhile, Ctrl+click on an app will only open a new window if
the app allows it.
This change prevents middle-clicks on app icons from opening new windows
for apps without multi-window support.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/316
When the actor that has the key focus is destroyed, Clutter moves
the focus to the stage. In case the destroyed actor was inside a
ModalDialog, this breaks any keyboard interaction: keynav is broken
because the stage isn't in any focus chain, and access keys like
Escape because they are handled on the dialog's parent.
The only dialog that may destroy a child without recreating the dialog
buttons (and thus moving the key focus there) is the WirelessDialog,
fix it by keeping the key focus within the dialog when removing networks
from the list.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/76
Just like we did for the window list in app icons' context menu,
provide a fallback for window captions in the window picker rather
than showing blank items to the user.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The app icon's context menu contains a list of open windows,
identified by their title. As we currently don't handle the
case where the app didn't set a title, we end up with empty
menu items which looks clearly broken. Fall back to the app's
name in that case.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/26
The instance is owned by the actor (being its child), and thus when the
disposal happens for the parent the text is disposed too, thus it's just
safer to nullify its reference so that we won't try to access to invalid
objects later, and this might be the case since the JS objects could be kept
around until they aren't finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=788931
The close dialog for non-responding windows is closed automatically
when we detect that the window is responding again. However as we
currently only ping the window in response to certain user actions
(like focusing the window or opening the window menu), this can
easily go undetected.
Address this by periodically pinging the window while the close
dialog is shown.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
The dialog won't be visible when unredirection is in place (for example
while a fullscreen window is focused), so disable unredirection while
the dialog is up.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/298
After the move to Gitlab, the gnome-shell-sass repository is more
exposed than it used to; clarify that it is not the place where
style changes should happen, but rather the corresponding subtree
in the gnome-shell repository.
The canonical maintainership information is tracked in the project's
.doap file as for any other GNOME project, and the empty AUTHORS
file only existed to make autotools happy.
Similar to what it's done when the main connection changes, we need
to make sure that the icon in the panel gets updated before calling
_syncConnectivity(), so that the icon gets always updated if needed,
regardless of whether there's an active connection or not.
This is needed because there's at least one case when an icon should
be shown when the computer is not connected to any network: when a
hotspot has been enabled, which can be useful even if there's not
an internet connection to share (e.g. to easily allow connecting
other devices to the computer.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/214
