GJS implements a basic signal system that allows monkey-patching
JS objects with signal methods resembling the GObject ones. However
it's clearly not a good idea to replace the actual GObject methods,
so use the proper GObject facilities when inheriting from GObject.
https://bugzilla.gnome.org/show_bug.cgi?id=778660
If an onComplete handler is passed to animate(), it is set to run at
the end of the animation via the icon grid's ::animation-done signal.
Currently the signal is connected after starting the animation, with
the result that the handler doesn't run when the animation completes
immediately (because there are no icons to animate). Fix this by only
starting the animation after connecting the signal.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
We currently assume that the current view matches the 'app-picker-view'
setting. While that is usually the case, there is one notable exception:
While there isn't sufficient usage data (yet), we show all applications
instead of an empty frequent view regardless of the setting. We should
animate the actually visible icons in that case, not the (non-existent)
ones from the hidden frequent view.
https://bugzilla.gnome.org/show_bug.cgi?id=774381
It will only show up when a discrete GPU is available (detected through
the switcheroo-control D-Bus service), and the application hasn't
alreayd been launched.
Note that this will not currently work for D-Bus activated applications,
eg. the menu item will be available, but the environment variable will
not be passed through to D-Bus to use when launching the application.
https://bugzilla.gnome.org/show_bug.cgi?id=773117
If the source actor is destroyed while the popupMenu is shown -- this
can happen if a non favorite application was closing or crashes -- the
menu actor is improperly destroyed.
This makes the popupMenu close first and does a clean ungrab instead.
https://bugzilla.gnome.org/show_bug.cgi?id=757556
It may be 2015, but users still stumble upon the occasional .desktop
file that uses a filename encoding other than UTF-8. We currently
fail quite spectacularly in that case by not displaying any apps at
all - handle this case more gracefully, by only filtering out the
offending apps.
https://bugzilla.gnome.org/show_bug.cgi?id=651503
In some cases we might be allocated a size such that
this._grid.topPadding and this._grid.bottomPadding are both 0 which
means that the ScrollView fade effect gets removed. In that case don't
try to access the effect since it will be NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=750714
We don't need a different GSettings object for each app or
favorite item.
While it practice it does not change much (AddMatch is still
obviously sent out), it minimally reduces the overhead on
changes, and makes for cleaner code.
https://bugzilla.gnome.org/show_bug.cgi?id=746509
Currently scroll events during the swarm animation will make the
grid appear immediately in addition to the animating clones, and
there'll be a mismatch with the icon at the target position. This
badly breaks the illusion of launchers emerging from the dash and
positioning themselves in a grid - as scrolling icons "mid-air"
before they form a paginated grid doesn't make much sense anyway,
fix this issue by ignoring scroll events for the duration of the
animation.
https://bugzilla.gnome.org/show_bug.cgi?id=745574
We assume that applications that export a 'new-window' action can open
a new window, so we add an appropriate entry to the context menu.
However this duplicates functionality if the application already
exposes the action via the desktop file - don't add our own entry
in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=744446
Because there's nothing (in single-monitor setups) that could
take the drop in this case.
* js/ui/appDisplay.js:
AllView._loadApps(), FrequentView._loadApps(): Pass
an isDraggable parameter when creating the AppIcons,
depending on whether the favorite-apps key is locked.
AppIcon._init(): Check for isDraggable in the params and
do not create _draggable if it was specified, to prevent a
drag from starting.
AppIcon.popupMenu(): Check _draggable before trying to call
fakeRelease on it.
* js/ui/dash.js: Dash._createAppItem(): Check AppIcon._draggable
before trying to connect to its signals.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
In a lockdown scenario, where the favorite-apps GSettings key is not
writable, hide the menu items for adding and removing favorites from the
dash menu. Additionally, reject drops to the dash for DND.
https://bugzilla.gnome.org/show_bug.cgi?id=741325
There is currently no simple way to inject into AppIcon's state change,
so an extension that wants to do this has to destroy/remove/update all
icons in the Shell (i.e. in the Dash, AllView, FrequentView) on enable()
and disable() after updating AppIcon.prototype._onStateChange, or the
extension must require a restart of the Shell.
To solve this issue, we rename _onStateChanged to _updateRunningStyle,
and connect the notify::state signal with an anonymous function that
calls _updateRunningStyle.
This extra function call should allow extensions to just extend the
updateRunningStyle function in the prototype.
https://bugzilla.gnome.org/show_bug.cgi?id=739497
Trying to open an empty folder currently leaves the parent view in a
rather confused state. While we should look into fixing this in the
future, empty folders are not useful at all to begin with, so hide them.
https://bugzilla.gnome.org/show_bug.cgi?id=736910
Trust the heuristics in shell_app_can_open_new_window() to get it right
more often than not, and add an appropriate check in activate(). This
makes the behavior consistent with the dash, e.g. we will try to open
a new window (and show the corresponding animation) for apps that don't
have a "New window" item in their dash context menu.
https://bugzilla.gnome.org/show_bug.cgi?id=736329
Providers that need drag-and-drop behavior can implement this via the
createResultObject() hook (as the app search provider already does), no
need to duplicate that code in the generic result objects
(ListSearchResult already does not implement DND).
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design mockups, animate the icons on AllView, FrequentView,
Dash and Search to zoom out when opening a new window of the app or when
the app is not running and the user execute it.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Given that we animate indicator in, it makes sense to animate them out
as well.
Also make possible animating indicators between view changes as well.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Following design decision, we want to animate AllView and FrequentView
when opening and closing with a swarm spring form.
This involves a few changes needed to allow that, since from some time
now, we are animating page changes in viewSelector, using only a fade
transition. However now we want to let appDisplay and iconGrid apply its
own animation.
For that we special case the change to and from apps page on
viewSelector to let appDisplay to animate its own items, using and API
on appDisplay which at the same time uses an API on iconGrid.
Thanks Florian Müllner for the debugging work
https://bugzilla.gnome.org/show_bug.cgi?id=734726
Add a new animation to folder view based on designers mockups that
emulates pulsating icons.
The code on iconGrid is though to work well for the upcoming patches to
animate AllView and FrequentView.
https://bugzilla.gnome.org/show_bug.cgi?id=734726
We were setting the value of adjustment on size changes, but we weren't
changing the page value, so adjustment and page value was not in sync.
To fix it, make sure adjustment of the view is in sync with the page
value.
https://bugzilla.gnome.org/show_bug.cgi?id=734680
Currently the indicators are a BoxLayout inside a BinLayout in AllView.
BinLayout doesn't have any size constraint, so if the indicators request
a bigger size than AllView the entire overview is grown, causing the
overview to go crazy.
To avoid that, create an actor for the page indicators that request as
minimum size 0, and as a natural size, the sum of all indicators natural
sizes. Then we clip_to_allocation, so it doesn't grow more than the
parent.
https://bugzilla.gnome.org/show_bug.cgi?id=723496
If the application reports itself as single window (through
an explicit indication in the desktop file or some heuristics),
not show a "New window" item that doesn't actually open a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=722554
The long press code has been refactored so it can be used on both pointer and
touch events, and the click gesture has been made to account for button=0.
https://bugzilla.gnome.org/show_bug.cgi?id=733633
Unlike for the main app view, where we only move the key focus once the
users starts navigating, the key focus is moved immediately when opening
a folder popup. This is unexpected, so make app folders consistent with
the main view.
As arrow keys will not work while the container itself has key focus, we
handle those explicitly by translating them to TAB_FORWARD and
TAB_BACKWARD respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=731477
Commit 5d00c1a5ee moved app folder popups to GrabHelper - for some
reason, the line that ensures the current behavior of only considering
events inside the app picker to dismiss popups got lost ...
As clicks outside the app picker should still be handled normally
while clicks inside should dismiss the popup, we cannot make full
use of GrabHelper. However using it at least for focus handling
fixes some minor details we are getting wrong, for instance not
restoring the previous focus after dismissing a folder popup.
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
Folders use a 2x2 grid of the first 4 app icons as icon - if a folder
contains less apps, we currently skip the corresponding grid positions.
As a result, the overall size request may be smaller than the one for
other icons, making the folder icon look out of place.
Fix this by always using a full grid as folder icon, using dummy actors
as necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=726322
With the switch to a table layout in commit f959cafb36, setting
alignments to place the individual icons at the outer edge of the grid
stopped working. Remove that code and add some explicit spacing instead.
https://bugzilla.gnome.org/show_bug.cgi?id=726323
Add more time to the fade in/out animation when switching
views so they don't switch abruptly and add a delay
between view switch animations to avoid morphing.
https://bugzilla.gnome.org/show_bug.cgi?id=722331
The current middle-click action of opening a new window on a new
workspace is a bit peculiar; it is also not overly hard to achieve
the same result by moving a new window to the desired workspace or
selecting a workspace before opening a new window. Just opening
a new window is also a more common action, so having a shortcut
available that doesn't require a modifier is a good idea as well;
change the middle-click behavior accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Having terminal launchers behave differently than any other launchers
is non-obvious and confusing. Remove the special-casing to restore
consistency, we will make the new window action more accessible
instead.
This reverts commit 68faba6bde, 4ed0f3e5f0
and 887a21afb9.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
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
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
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
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
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
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
Rather than scanning all apps for searching, use Ryan's new desktop
file index and the glib support APIs for app searching instead of our
own system.
https://bugzilla.gnome.org/show_bug.cgi?id=711631
We want to move away from gnome-menus eventually, so the simple
utility method isn't really worth keeping around. Reimplement it
in the one place that uses it.
https://bugzilla.gnome.org/show_bug.cgi?id=698486
Long ago, the search system worked in a synchronous manner: providers
were given a query, and results were collected in a single array of
[provider, results] pairs, and then the search display was updated
from that.
We introduced an asynchronous search system when we wanted to potentially
add a Zeitgeist search provider to the Shell in 3.2. For a while, search
providers were either async or sync, which worked by storing a dummy array
in the results, and adding a method for search providers to add results
later.
Later, we removed the search system entirely and ported the remaining
search providers to simply use the API to modify the empty array, but the
remains of the synchronous search system with its silly array still
lingered.
Finally, it's time to modernize. Promises^WCallbacks are the future.
Port the one remaining in-shell search engine (app search) to the new
callback based system, and simplify the remote search system in the
process.
When we create a result actor, cache it, so it can be used for
subsearches of the same initial. For now, to keep memory usage
and the stage graph relatively clean, don't persist the actors
across searches, but maybe we should do this in the future.
This also means that we don't query getResultMetas for items
that we've seen in the same initial search.
https://bugzilla.gnome.org/show_bug.cgi?id=704912
The application picker will always open with the view that was last
selected during the session, but the selection is reset on each
restart. This results in some annoyance for users that use the
ALL view exclusively, as they have to toggle views once each
session - the same would apply to exclusive FREQUENT view users
were the defaults to be changed, so the best solution is to simply
make the selected view persistent by storing it in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=710042
Allow the prefix 'special:' applied to result IDs to mark results
that should be always shown, even when they would overflow the
maximum results cap. This will be used by epiphany for the special
"Search the Web" result.
https://bugzilla.gnome.org/show_bug.cgi?id=707055
Previously the animation was not entirely according to the mockup.
Now we are closer to the mockup.
The padding for the indicators are decremented, since we need that
to make the animation not too quick. As a drawback, maybe visually
is not as good as before, or the area to click dots is too much little.
Just make that change for now and test it widely, and we can change
that after.
https://bugzilla.gnome.org/show_bug.cgi?id=707565
The original position was calculated with the stage and the
transformed position of the indicator when mapped. The values
were wrong on some situations, so lets calculate the position
based on the dots width.
https://bugzilla.gnome.org/show_bug.cgi?id=707580
We need to adjust the offset of close buttons, in case the box
pointer has the arrow at the top. To do so, extend close buttons
to hook into a boxpointer (since that's the common use for them)
and automatically adjust their position.
https://bugzilla.gnome.org/show_bug.cgi?id=707842
For extremely silly reasons with how the class framework works, the wrapper
method requires "this" to be bound in order for it to work, or else we'll
emit errors in strict mode.
https://bugzilla.gnome.org/show_bug.cgi?id=707892
Just as we do in AllView, we set the offset of FolderViews' fade
effect so that no icon is faded when a full page is visible.
This works fine in AllView, however in the FolderView case where
the popup's offsets eat away from the available fade height, the
effect ends up being barely noticeable at all.
While it is not ideal to apply the fade to the edge of a "full page",
it looks less ugly than the current state, so pick the lesser evil ...
https://bugzilla.gnome.org/show_bug.cgi?id=707662
Since now if you focus the indicators, you can't scroll and
change pages in the app picker. That was reported as odd from
some users/developers.
So allow to scroll when the focus is in the indicators.
https://bugzilla.gnome.org/show_bug.cgi?id=707609
ClutterActor::scroll-event has a boolean return value to indicate
whether the event has been handled, or event emission should continue.
Now that we are using an StScrollView, we depend on this to avoid
propagating the event to the view's own handler.
https://bugzilla.gnome.org/show_bug.cgi?id=707409
It doesn't make sense to show the indicators in that case, so
don't show them. This has been the design in the first place,
but the code that did that was lost at some point during review ...
https://bugzilla.gnome.org/show_bug.cgi?id=707363
The frequent view is not useful when it doesn't contain any applications
yet. While the previously added label makes this state appear less like
an error (OMG, my apps are gone!), it doesn't address the issue of
usefulness - default to the more helpful All view in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=694710
