The DESKTOP window might not be located at (0,0), in particular
on multi-monitor setups. While we already consider this by setting
the clone's position, we then stuff the clone into a container which
ignores it - meh ...
https://bugzilla.gnome.org/show_bug.cgi?id=723306
If the user mostly uses the All Apps view and uses it as his default view,
we shouldn't reload frequent data after a timeout. Simply do it when the
view is mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=723179
Need to manually dispose of cairo contexts used in gjs with $dispose(),
or the context object will leak. These classes used cairo for drawing but
were missing the dispose call.
https://bugzilla.gnome.org/show_bug.cgi?id=722812
get_categories() returns an unparsed string, not a list of categories.
We need to parse the list by splitting on ';' to deterine whether the
actual 'TerminalEmulator' category is in the list, rather than something
like 'X-GNOME-TerminalEmulator'. It's an edge case, but I need to split
the list properly for the new folders, so I might as well fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=723179
It's a lot simpler and doesn't require us routing the NMRemoteSettings
all the way through. It's still a bit complicated to do this for the
usual connections, so let's drop it for now.
Because we were setting this.background before calling .destroy(),
the call that was meant to destroy the old background was actually
destroying the new one!
https://bugzilla.gnome.org/show_bug.cgi?id=722787
When restricting the switcher popup to the current workspace, we
filter out running apps with an empty window list (namely: no open
windows on the current workspace). However we may end up with an
empty window list even when not restricting items to the current
workspace when all windows of a running app are associated with a
different application via the transient_for hint.
To fix this, just filter out items with an empty window list
unconditionally.
https://bugzilla.gnome.org/show_bug.cgi?id=722434
Without special-casing, our current spacing calculation results in
negative size requests for empty lists, which will trigger a Clutter
assert later.
While the list is never supposed to be empty, bugs happen; crashing
users' systems is the least graceful way of handling this, so don't
do it.
https://bugzilla.gnome.org/show_bug.cgi?id=722434
Using the new list_actions() API in Gio, add entries for static
actions specified in .desktop files in the right-click app menus,
in the dash, app well and search.
https://bugzilla.gnome.org/show_bug.cgi?id=669603
The window clones in the central part of the overview are showing modal
dialogs now, and this creates an inconsistency if the thumbnail doesn't too.
Code is intentionally similar in the two places.
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Windows in the overview should be like they appear in the workspace,
including modal dialogs that are attached above them.
In addition, hiding the dialogs in the overview causes a flash as
dialog appears at the end of the transition.
Based on a patch by Maxim Ermilov <zaspire@rambler.ru>
https://bugzilla.gnome.org/show_bug.cgi?id=650843
Use a new ShellGLSLQuad actor class to build a RadialEffect that can be
enabled on Lightboxes to achieve a radial effect similar to the overview
one. Then enable it for modal dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
If the notification is destroyed between an allocate and the redraw,
the meta_later is invoked on a destroyed object, and fails because
the clutter calls are invalid at that point.
https://bugzilla.gnome.org/show_bug.cgi?id=722547
By default, gesture actions no longer wait for the dnd threshold to
be reached before triggering, which breaks our mixing of click- and
pan actions. Fix this by only panning after reaching the threshold
and letting the click action go through if the pan is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=722417
This is done for properly drawing popup menu when arrow rise is 0 (in
case of background menu).
Normally, the menu with arrow rise set to 0 is drawn properly having
all four corners rounded. But when the source(click/arrowOrigin) is
near screen's edges, one of the corners (depending on source's position
and arrow alignment) is drawn right angled.
This happens because the rounded corners are skipped and right angled
arrow is drawn when arrow origin is close to the edges.(That's why when
arrow-rise is 0, it forms right angled corner).
So, a few condition checks are made to ensure that right angled corner
is not drawn.
https://bugzilla.gnome.org/show_bug.cgi?id=699608
Right now we have three "dummy cursor" widgets between the background
menu, the message tray menu, and the IBus candidate popup. Consolidate
these into one "dummy cursor" widget which is tracked in the layout
manager.
Rather than GMenu / app-folder-categories. This removes our last use of
gnome-menus in the stock gnome-shell, which is exciting, but also means
that app folders in Software start working.
Ideally, we'd have a button to launch our Software app as well from the
overview.
https://bugzilla.gnome.org/show_bug.cgi?id=722117
Instead of having _compareItems, _getItemId, etc. on the view to
pull out info about items, use the AppIcon / FolderIcon items we
create as a place to track this additional info. We now require
that these items have a '.id' property for deduplication, and a
'.name' property to sort by.
https://bugzilla.gnome.org/show_bug.cgi?id=722117
Currently we only show/hide the left and right arrows when
we reach the initial/end position. This patch changes this
behaviour by showing the arrows whenever is a scroll is possible.
https://bugzilla.gnome.org/show_bug.cgi?id=711467
One of the most frequent complaints about our launching behaviour is
how we handle terminals. Among all MDI applications, the terminal is
the one that is most likely to have lots of semi-independent windows
opened at the same time, and spawning new windows is much more common.
More so, if it does not support tabs.
Therefore, we special case terminal launchers to always create a new
window. It is an application that most non-technical users will not
use, so chances of them being confused by any special behaviour is
expected to be low.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Workspaces can removed from any index, and in particular they
will be removed by the WorkspaceTracker if they stop containing
windows at some point. Make sure WorkspacesView is not confused
and destroyes the right Workspace objects.
https://bugzilla.gnome.org/show_bug.cgi?id=721417
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712579
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712596
When set to fill, the label will always end up left-aligned, which
is only correct in LTR locales. Set the alignment explicitly to
work in both RTL and LTR locales.
https://bugzilla.gnome.org/show_bug.cgi?id=712638
Filtering out "non-interesting" windows beforehand as we currently do
means that we may get properties that should be based on all windows,
like the last time the application was used, wrong.
Just track all windows and filter out non-interesting windows manually
in the one place we actually care about the difference.
https://bugzilla.gnome.org/show_bug.cgi?id=719824
As far as I can tell, the only behavior change of a transient source
is that they auto-destroy after viewing their summary box pointer.
Since all transient sources are only associated with transient
notifications, it seems that we can never get to their summary box
pointer in the first place! Remove support for this.
https://bugzilla.gnome.org/show_bug.cgi?id=710115
Rather than implement special focus policies like only allowing keynav
when pressing down, simply give the active page key focus when entering
the overview.
This may break stuff, as it's somewhat of a tricky patch to get right.
Testing this one would be super appreciated.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
Simply use St's existing key navigation system by making all the window
clones StWidgets, and making the WorkspacesView a focus group.
Since the workspace view is effectively "fake", we need to add a focus
delegator so that when key focus is assigned to the fake workspaces page,
we can keynav inside it properly.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
For mysterious reasons I'm not sure of myself, navigate_focus will only focus
mapped actors. So, make sure the widget is showing before navigating to it.
https://bugzilla.gnome.org/show_bug.cgi?id=709853
If the background is already removed, or we're trying to remove bad content,
this is probably a bug in content accounting, so let us crash so we can fix
the bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
Stomping on local variables and trying to keep loop state isn't
too fun. Just use a new variable here so we aren't too confused
with what we're doing.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
We don't have any better way of determining whether something is a slideshow
animation, so discriminate on the .xml filename instead of waiting for
gdk-pixbuf to determine whether it can load a file or not.
https://bugzilla.gnome.org/show_bug.cgi?id=719803
The destroy vfunc might be called during object finalization, and
we can't call any JS from a GC finalizer, so we use a signal
connection instead, as that is removed by GObject the first time
the object is disposed.
https://bugzilla.gnome.org/show_bug.cgi?id=719730
AppDisplay queues a deferred work to load frequently used apps when the
apps page is loaded. Unfortunately, when the overview is first opened,
all the pages start out visible and then immediately get hidden, so the
deferred work runs immediately after the first overview opening, whether
the user was going to view their frequent apps or not.
Start all pages off as hidden, and rearrange the code so that pages are
only shown when they really need to be.
https://bugzilla.gnome.org/show_bug.cgi?id=712753
This is also exposed in the ShowOSD DBus method, the "monitor"
parameter may contain an integer to indicate the monitor number.
If the value is not provided or <0 is used, the monitor is shown
on the primary monitor as usually.
This way, the OSD can be used to notify upon events that solely
apply to one monitor, like tablet mapping as discussed in
https://bugzilla.gnome.org/show_bug.cgi?id=710373.
https://bugzilla.gnome.org/show_bug.cgi?id=712664
You would think we would already do something like this, but apparently
lots of code was calling hide() without checking if the box pointer was
already visible, causing it to queue a full tween. The biggest win was
with ibusCandidatePopup.js, which called hide() on every DBus message.
This increases the performance for me to enter the overview by a tiny
bit. The remaining time is spent updating the frequent apps / all apps
display.
https://bugzilla.gnome.org/show_bug.cgi?id=712727
The methods we call in _updateState may not be reentrant, so make
sure that we never get into a situation where _updateState, through
some crazy chain of events, calls itself.
https://bugzilla.gnome.org/show_bug.cgi?id=711694
