When workspaces are disabled by the session mode, all workspace
related actions don't make sense. Worse, the "Move to Workspace ..."
actions allow sending windows into a nirvana with no means to
get them back.
https://bugzilla.gnome.org/show_bug.cgi?id=730653
Starting keynav into the active page is handled from a key-press
handler on the stage, however we should not "start" keynav when
we are already navigating elsewhere - the latter can happen when
keynav fails (for instance because the focus is trapped inside an
open app folder or at the end of the dash), and the event bubbles
up to the stage. So make sure to only handle the event to actually
start keynav, to not interfere with the normal navigation handling.
Thanks to Carlos Soriano <carlos.soriano89@gmail.com> for the
debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=726760
The fallback app-menu in GTK+'s client side decorations obviously
uses the GTK+ theme rather than the shell one; update the style
of our own fallback app-menu to resemble that style.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
We now allow "appmenu" in the button layout to make synchronizing it
with GTK+'s client-side decorations easier, but as some people tweak
their settings to get in-window app menus even when using the shell,
actually pop up the app menu when the button is activated.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
The optional label support introduced in commit af063dc2f2 broke
the centering of separators, as the label still adds additional
spacing even when empty.
Properly hide the label actor in that case to fix the alignment.
https://bugzilla.gnome.org/show_bug.cgi?id=730753
The extension-prefs tool is used by gnome-tweak-tool and the
extensions web site to display preferences. However as those
already implement their own extension lists, the main window
is not useful in that context (to not say it is rather silly).
Just skip the main window and only show the specified extension's
preference dialog in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
Bring the extension-prefs tool in line with the mockup by adding
switches to enable/disable extensions, similar to the extension
page in gnome-tweak-tool.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
The extension-prefs UI has never been great, but as the GNOME 3
design patterns are evolving, it is starting to look seriously
outdated. Modernize the UI a bit to have it fit in a bit better.
https://bugzilla.gnome.org/show_bug.cgi?id=730829
When a monitor is removed, the OsdWindow for that monitor may process
the monitors-changed signal before OsdWindowManager does (which will
remove the OSD). If that happens, we will currently try to access
an invalid monitor; check for this to avoid a couple of warning.
When switching between alternatives in AltSwitcher, the currently
visible child is replaced with the alternative. If the original
child has the key focus when it is removed from the stage, the
focus is lost. Detect this case and manually move the focus to
the new child.
https://bugzilla.gnome.org/show_bug.cgi?id=727259
When dragging a window preview from a non-primary monitor onto a
workspace thumbnail, the window is moved to the primery monitor
first before changing its workspace. However when dragging the window
between thumbnails to create a new workspace, it is kept on its current
monitor instead. This is not only inconsistent, but outright confusing
with the default 'workspaces-only-on-primary' setting, as the newly
created workspace is immediately removed again.
https://bugzilla.gnome.org/show_bug.cgi?id=683819
We only need GSystem when running under systemd. As libgsystem itself
has a hard dependency on systemd, only import it when actually needed
to keep working on systems where systemd is not available.
https://bugzilla.gnome.org/show_bug.cgi?id=728449
The workspace switcher should be expanded when workspaces are in use.
Our current implementation assumes that workspaces are used when there
are windows on at least two workspaces. However workspaces are already
used when moving from a non-empty workspace to an empty one (presumably
with the intention to launch something on that workspace), so tweak the
heuristic accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=662457
Having the ability to go to the current date if the user is already
on the current date can be confusing. So don't make the button reactive
until the selected date changes.
https://bugzilla.gnome.org/show_bug.cgi?id=726724
Currently, our logic for page panning isn't great. If the user starts a
pan upwards and hesitates over a new page, we'll go to the *next* page
on release, since the difference is greater, but the velocity wound down
to 0.
Instead of trying to treat it like page down or scrolls, simply do the
math to find the page where the user scrolled to.
This is unfortunately broken for fast swipes, since the user doesn't get
far enough into the new page to make a difference. I'm getting the
impression we'll need a gesture recognizer for this, though, however
crude. Simple hacks I tried, like a velocity multiplier, didn't work
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=729064
We often call goToPage like:
this.goToPage(this._currentPage - 1);
(or + 1). During panning, these are based on the velocity values
of the gesture action. If we're already on the first or last page
and the panning ends, it's possible to get goToPage that's either
-1 or greater than the last page.
During normal usage, this isn't a problem, since the Y values will
be correct, always. But when panning, the Y values stick to the
finger, and thus if we return early, we won't snap to the exact page,
making it seem like things get "stuck".
Fix this the simple way by clamping to the correctly-ranged values
of pageNumber
https://bugzilla.gnome.org/show_bug.cgi?id=729064
The order in which month and year are displayed is controlled by
a "special" translated string in GTK+. We pick up the translation
from there, so make sure that it doesn't get translated again
in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=715042
When workspaces have been removed, we need to remove the corresponding
thumbnails as well; the number of thumbnails that need removing is
the difference between the old number of workspaces and the new one.
Currently we assume that the old number of workspaces corresponds to
the number of existing thumbnails, but that may actually be wrong:
A thumbnail will still be animated out after its workspace has been
removed. As a result, we end up removing too many thumbnails when a
workspace is removed while a thumbnail of a previously removed workspace
is still animating out. Fix this by basing the old number of workspaces
only on thumbnails that have not been removed previously.
https://bugzilla.gnome.org/show_bug.cgi?id=728820
Taking an area screenshot doesn't work currently when in "grab mode",
for instance when the message tray or top bar menus are open. Fix
this by using GrabHelper for selecting the area, so grabs are properly
stacked for us.
https://bugzilla.gnome.org/show_bug.cgi?id=709126
The code path is completely unmaintained and untested (and probably
unused as well, considering that nobody has complained about accessing
the session object's Active property which does not exist in the
ConsoleKit case).
Most of our ConsoleKit code is already a dummy anyway, just do the
same for the remaining functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=686626
Commit 7101cc3170 caused a small
regression insomuch that it checks for a valid "level" but simply using
"if (level)" which will be false if level is undefined and if
level == 0.
Check for not undefined instead.
https://bugzilla.gnome.org/show_bug.cgi?id=727384
Sometimes it is more appropriate to set layout properties that are
hooked up to CSS properties in code. However this is currently not
possible, as we end up setting properties to 0 when not found in CSS;
be a bit more careful when hooking up CSS properties to support this.
https://bugzilla.gnome.org/show_bug.cgi?id=728897
When we unregistered providers, like when we refreshed the list of
active remote providers, we would forget to destroy the old provider
display after the fact. This left an empty "skeleton" provider display
still in the search results that would never be filled in. Make sure
to destroy it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=728597
We had one osdWindow that we displayed either on the primary monitor or on
whatever monitor index got passed over dbus.
Change that to show the osd on all monitors when no explicit monitor is
requested. A monitor should be requested in cases like display brightness where it makes sense to only show the osd on the affected monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=722684
NetWM struts are defined in terms of screen edges (rather than monitor
edges), which works poorly with vertical monitor layouts (as it renders
entire monitors unusable). Don't extend struts in those cases.
https://bugzilla.gnome.org/show_bug.cgi?id=663690
Calling Mainloop.source_remove() on the timeout ID will not reset it,
and we're already removing the timeout by returning GLib.SOURCE_REMOVE
in the callback.
If geoclue reports that we can't aquire location, we hide the menu. This
will typically happen when user is offline (and doesn't have a 3G
modem). This is likely not what we want since this like a temporary
situation and user would want the ability to toggle geolocation still
even if its currently not possible any applications to query the
location.
https://bugzilla.gnome.org/show_bug.cgi?id=727398
