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
CtrlAltTabPopup was using a St.BoxLayout and relied on anchor_gravity
center for positioning. This does not guarantee correct pixel alignment,
so use a St.GenericContainer instead and do the positioning similar to
that of the appSwitcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643820
Make GSettings support optional, refactor text entry handling,
fix some off-by-one bugs in the management itself, use Params
for parsing, fix other typos and bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=642793
Currently the icon texture is only updated on style changes when
the icon size is set from CSS and differs from the previously used
icon size.
As the style change may have been triggered by an icon theme change,
textures that are created for themed icons should always be recreated;
given that this is the case for most uses (with the exception of
file thumbnails), recreate the icon texture unconditionally to avoid
complexity.
https://bugzilla.gnome.org/show_bug.cgi?id=643738
Commit b1654af406 moved the panel positioning (and thus that of its
corners) before the panel startup animation. As the panel corners now
are mapped while the panel animation is active, the initial style-changed
signal which triggers another repositioning is received after the
initial layout and the corners end up at wrong positions.
To fix, animate the corner positions as well during the startup
animation - if anyone could actually see the animation, the corners
should animate with the panel anyway ...
https://bugzilla.gnome.org/show_bug.cgi?id=643804
Mutter really expects this, as this is how app-specified struts
happen. For instance, if the primary display is beside a taller
screen and is not positioned at the top, then we extend the struts
for the panel with the size of the unused area above the primary
monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
Right now we require a strut to be as wide as the full screen to
create a TOP strut. This means that in a multi-monitor scenario (at
least if the primary monitor is leftmost) we will make the panel strut
be Meta.Side.LEFT due to the random side picking for corner objects.
This changes the width/height comparison to the primary monitor rather
than the screen to get this right. Also adds some docs about how
struts work in a multi-monitor situation.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
We need to do the initial relayout before we start up the startup
animation, and the startup animation can't hardcode the position
of the panel to zero.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
1. disconnect destroy signals in popModal (actors can have great lifetime and then pushed again)
2. incorrect pushModal/popModal pair in overview
https://bugzilla.gnome.org/show_bug.cgi?id=64078
Increase the icon size of search results for consistency with the
application view. To account for the larger icons, only display
a single row of results per section.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Search results' meta info currently is expected to have an 'icon'
property holding a Clutter.Texture of a fixed icon size. This
property is used to implement the createIcon() function of BaseIcon,
which is used to actually display the result, ignoring the size
parameter due to the fixed icon size.
Given that all available search providers create this property for
the desired icon size using a function with the same signature, it
appears logical to replace the fixed-sized 'icon' property with
such a function, so that the icon size will be defined by the display
actor rather than the search system.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently section headers in the search view are reactive and run
the corresponding provider's expandSearch() function when clicked,
which should launch an external program displaying all search
results for the section. Unfortunately it is only implemented for
the "Settings" provider, and does not work properly (as it ignores
the search and just launches System Settings).
Also current mockups deemphasize the section header, making the
feature pretty much indiscoverable (except by accident when
interfering with swipe-scrolling).
In conclusion, the feature does not make much sense in its current
form, so remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
Currently the total number of matches for a particular section is
displayed on the left of the section's header. While it made sense
in the old layout where it was close to the section's title, it is
now rather disconnected, and has been removed in current mockups.
https://bugzilla.gnome.org/show_bug.cgi?id=643632
When UPower has not yet collected enough data to calculate a time
to discharge, it will report 0 minutes. Show "Estimating..." in
that case instead.
https://bugzilla.gnome.org/show_bug.cgi?id=642753
Currently we remove a workspace when last window on that workspace closes,
which turned out to be too agressive as some apps open either a splashscreen
or a "I have crashed last time" dialog at startup.
Try to detect such apps and give them a chance to open their "real window(s)"
on the workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=642188
_ungrabActor disconnects the event signal handler but does not
check whether it is connected before doing so which can result into
an exception like:
JS ERROR: !!! Exception was: Error: disconnect() takes one arg, the signal handler id
JS ERROR: !!! lineNumber = '0'
JS ERROR: !!! fileName = 'gjs_throw'
JS ERROR: !!! stack = 'Error("disconnect() takes one arg, the signal handler id")@:0
Unfortunately the evolution-data-server client-side libraries seem to
block the calling thread. This is a major problem as we must never
ever block the main thread (doing so causes animations to flicker
etc.). In the worst case, this problem causes login to hang (without
falling back to fall-back mode) and in the best case it slows down
login until a network connection is acquired.
Additionally, in order to sanely use these evolution-data-server
libraries, GConf has to be involved and GConf is not thread-safe. So
it's not really feasible just moving the code to a separate
thread. Therefore, move all calendar IO out of process and use a
simple (and private) D-Bus interface for the shell to communicate with
the out-of-process helper.
For simplification, remove existing in-process code since internal
interfaces have been slightly revised. This means that the shell is no
longer using any native code for drawing the calendar dropdown.
https://bugzilla.gnome.org/show_bug.cgi?id=641396
Signed-off-by: David Zeuthen <davidz@redhat.com>
See commit f2158218bef0c51 in mutter. Basically, we need
to grab org.freedesktop.Notifications before anything else
in the session gets started.
Note: I intentionally removed the Util.killall bits. I believe that
for notification-daemon at least, if we specify
DBUS_NAME_FLAG_REPLACE_EXISTING, we'll take over the name. Not sure
about notify-osd; if that's still a problem, then what we need to do
is add killing (and possibly respawning) of notify-osd to
"gnome-shell --replace", and not have it embedded randomly in a JS file.
https://bugzilla.gnome.org/show_bug.cgi?id=642666
The DBus JS binding will complain if the signature of a method
or of a signal is undefined, so we need to define it even if it
is an empty string, and we need to use the correct property name
for signals.
https://bugzilla.gnome.org/show_bug.cgi?id=643374
For applications with no proper desktop file, the window icon is
used as application icon in the tab switcher, but it won't have
the correct icon size. The current approach is to add additional
padding to these icons - the size turns out inconsistent with
other icons, but the icon appears sharp. For the dash it has been
decided that unsharp icons are less evil than differing icon sizes,
so icons are scaled up to the "right" size - for consistency, do the
same in the alt-tab switcher.
https://bugzilla.gnome.org/show_bug.cgi?id=643300
Mainly due to StTextureCache's way of handling fallback icons, an
implementation of BaseIcon.createIcon() may return an icon smaller
than the requested size. Given that BaseIcon is not used for isolated
elements, but rather for groups of related items (App view, Dash,
Search Results, ...), having some elements end up with the wrong
size is more annoying than having some elements end up ugly due to
scaling, so explicitly enforce the requested icon size.
https://bugzilla.gnome.org/show_bug.cgi?id=642043
