The current gnome-shell.in script has a huge amount of
unnecessary complexity for the installed, normal case. Fix
this by adding a configure option (defaulting to false) that
installs a simple, obvious wrapper script around mutter.
We do change the gnome-shell build setup to pass this option
by default for jhbuild.
https://bugzilla.gnome.org/show_bug.cgi?id=642084
_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
As gnome-shell now switched to use the menu file from gnome-menus,
we no longer have direct control over category names. If such a name
contains unescaped markup, the shell will crash when trying to create
the filter label, so make sure to escape markup in category names.
gs-applications was introduced because we initially wanted a limited set
of categories, but this has now changed and we're back to categories
similar to the ones in the applications.menu from gnome-menus.
We can fix gnome-menus to have better categories, if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=641148
Fix a typo in panel.js, and ensure that all variables used in
functions are scoped to the block (using let), to avoid polluting
the global namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=643210
Commit 9a048af1f changed the panel border to be drawn below the
background - as a result, the app menu's icon now overlaps the
panel border. As it looks cleaner to leave the border in place,
clip the icon to the panel border.
Rather than connecting to stage::capture-event and then trying to
guess whether or not a given key-press should be handled by us or not,
handle the end-search-on-Escape case from entry::key-press-event
(since it only makes sense when the entry is focused anyway) and the
start-search-on-printable-key case from stage::key-press-event (which
will only get the events that no other actor wanted for itself).
Similarly, do exit-overview-on-Escape and switch-panes cases from
stage::key-press-event, rather than
viewSelector.actor::key-press-event, so that they will work correctly
even if the keyboard focus is somewhere else. (Also fix a longstanding
bug in the pane-switching code, which was supposed to be disabled when
a search was active, but was checking a non-existent variable.)
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The search entry was taking a sort of grab when it was in the
focused-but-empty state, and would eat up most events for other actors
(except, confusingly, for panel actors). The only bit of "modality" we
really need here is that the entry is supposed to go back to the
unfocused state if you click somewhere outside it when it was in the
focused-but-empty state. So do that.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The division of labor between the two was quite muddled. Rather than
try to invent a clean distinction of what belongs where, just merge
them together.
https://bugzilla.gnome.org/show_bug.cgi?id=642502
The vertical scrollbar is located on the left in RTL locales, so
pass an additional parameter to the shader which indicates the
locale's text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
In RTL locales, the vertical scrollbar should be located on the
left, so take the widget's text direction into account when
allocating the view's elements.
https://bugzilla.gnome.org/show_bug.cgi?id=643156
When the user cancels the drag while hovering over a window the timeout
handler will throw an exception because the drag actor will be destroyed
at this point.
Fix that by removing the timeout in _onDragEnd.
The xdnd timestamp gets updated on every xdnd-position event,
so while waiting for the window timeout to fire we need to make sure we
update the timestamp when getting on motion to activate the window
with the correct timestamp.
Commit 259c84ed9a refactored out HotCorner into its own class
and added this line and a variable, but it was left behind
when the variable disappeared in commit 7cf311dac0.
See https://bugs.freedesktop.org/show_bug.cgi?id=27788#c1 for details
about the problem this patch is solving
In particular, we should never bring up the dialog if there is no
password on the account. While this sounds like a weird corner case,
it's not.. the Live CD, for example, does not have a root password.
This also avoids the initial dialog resize.. before the patch the
authentication dialog appears and a split-second later an StEntry
widget is added.
Also print out more diagnostic information if showing the modal dialog
fails. Also add a comment about how to easily make this happen.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Currently the panel is positioned from main.js, move that code into
a method in panel.js instead and call it from main.js, which is
consistent with what we do for the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=643064
This is required since we can have chrome on multiple monitors (due to
per-monitor hot-corners).
Windows are primary associated with the monitor that their center is on.
https://bugzilla.gnome.org/show_bug.cgi?id=642881
