When closing a workspace due to the last window on that workspace
closing, switch to the overview and show the always empty workspace
rather then just going to the adjacent workspace.
Based on a patch from Adel Gadllah <adel.gadllah@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
When navigating from a non-immediate descendant of a container, we
were attempting to use clutter_actor_get_transformed_position() to get
the exact position of that actor relative to the container, but this
did not really make sense, since we would be using the position of
the intermediate container when navigating back.
https://bugzilla.gnome.org/show_bug.cgi?id=644134
g_themed_icon_new_with_default_fallbacks() does not do what we want
with symbolic icons; if the user's icon theme is not "gnome", then it
will end up preferring a non-symbolic icon from the higher-level theme
over a symbolic icon from gnome-icon-theme-symbolic.
If the shell requests a symbolic icon, and there is only a
non-symbolic icon available, that should be considered a programmer
error, just like requesting a non-existent icon name. So change the
code to only look up "-symbolic" names when drawing an
ST_ICON_SYMBOLIC icon.
https://bugzilla.gnome.org/show_bug.cgi?id=644142
* calendar-server subdirectory of build directory needs to
be created.
* Generate shell-enum-types.c/.h in build directory rather than
in the possibly-read-only source directory.
Build gnome-shell as a binary linked against libmutter-wm, instead of
a module to be loaded by libmutter-wm. Move the majority of
initialization-type stuff from gnome_shell_plugin_start() into main().
We still build libgnome-shell as a shared library, so that the linker
doesn't discard all the methods that are never called from C.
https://bugzilla.gnome.org/show_bug.cgi?id=641724
During a drag-and-drop, our pointer grab keeps enter/leave events from
being delivered. That means that after the DND ends, whatever actor is
under the pointer won't have received the enter event it should have,
and any state or hover effect dependent on that won't work right.
By paying attention to the actors we leave and enter we can figure out
what widgets we need to call st_widget_sync_hover() on after the drag.
https://bugzilla.gnome.org/show_bug.cgi?id=640974
Showing the right click menu causes errors when ungrabbing focus in this case.
It will soon be impossible to get to the right click menu anyway when a new
notification is showing, because we are never going to show the summary
and the new notification at the same time.
Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.
The Windows pane can be switched to, but navigation within the pane is
not yet implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Fix the "panel" icon to be symbolic. Make the overview parts only show
up when in the overview, and the non-overview parts (eg, the Desktop
window, if there is one) only show up when not in the overview. Sort
the different items consistently with their locations on the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=618887
Unset this._expandedSummaryItem if it is the summary item that is being removed.
This avoids "this._sourceTitle.clutter_text is null" error.
Destroy the summary item actor only after calling _unsetClickedSummaryItem()
that disconnects from one of its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=644043
PopupMenuManager was pretending that it knew nothing about the menu's
sourceActors, while also trying to handle keynav between them. This
was a big mess, and resulted in bugs in navigation between panel menus
and the Activities button, and it totally gets in the way when trying
to add keynav to the dash (whose menu sources are arranged vertically
rather than horizontally).
Fix this up by moving the panel-specific parts to PanelMenuButton
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
It already doesn't work right, because the PanelMenuButton code
assumes that Left and Right won't be used as part of keynav within a
menu. And the gnome-panel calendar isn't keyboard accessible either,
so this isn't a regression. To be fixed later.
https://bugzilla.gnome.org/show_bug.cgi?id=641253
To deal with different CSS in RTL locales, we used to manually add
an :rtl pseudo class to some actors. With automatically assigned
:ltr/:rtl selectors this is no longer necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
At times, RTL locales require different CSS, so always create theme
nodes with :ltr/:rtl pseudo classes depending on the widget's text
direction, to provide an easy way to handle those cases without
requiring a separate stylesheet.
https://bugzilla.gnome.org/show_bug.cgi?id=643835
