When we show(), we need to make sure that the hiding animation
doesn't reach the end, otherwise we would hide the actor but
still have _visible = true.
We were relying on tweener overwriting to do this, but it
doesn't quite work, so better be explicit and do it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=707814
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
A11y users who use the magnifier may have trouble
focusing when they're typing or trying to keynav.
Implement a new system so that they can have the
magnifier track the caret and focus instead instead
of just the mouse.
Bug https://bugzilla.gnome.org/show_bug.cgi?id=647074
While this is good style anyway, after the latest appDisplay changes
the first call to get_preferred_height() happens before we properly
compute those properties, resulting in a size request of NaN that
triggers a Clutter warning.
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
Similar to adapting the spacing dynamically to the available
space we already do, scale down icon sizes if the grid is too
small to fit the requested minimum number of rows/columns.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
IconGrid has never really been a general purpose container, but has
always been used in conjunction with BaseIcon. IconGrid will soon
gain the ability to adjust the item size dynamically to adapt to the
available space, which will require that we can make some more
assumptions about the items added to the grid (namely: we need
access to BaseIcon's setIconSize() method).
So change addItem() to take an object instead, which should have
an actor and a (BaseIcon) icon property.
Based on a patch by Carlos Soriano.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Add methods to open/close extra space for n rows. The app picker
will use those to make AppFolder popups appear inline with the
main grid rather than on top of it.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
The popup of the FolderView is now contained inside
the parent view, solving the overflow of apps with a ScrollView.
Also, solved a lot of bugs in popup/FolderView calculation
of position and size.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Add a property to also add the calculated spacing
around the grid.
This will allow FolderView to be aligned with the
main grid without cutting off any of the surrounding
boxPointer decorations or the close button
https://bugzilla.gnome.org/show_bug.cgi?id=706081
When we adapt the grid to different display sizes,
we don't want the number of displayed items to get
too small. In the future we will scale down icons to
make sure that the grid fits add least minRows
x minColumns items, but for now we only take the
properties into account when calculating the dynamic spacing.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Organize applications in AllView by pages using the new PaginatedIconGrid
added previously. Pagination is generally a better pattern for collections
than scrolling, as it better suits spacial memory.
Hook into AppDisplay's allocation function to communicate the available
size to the different views before child allocations - this is only
required by the paginated view (as pages must be computed before
calling get_preferred_height/get_preferred_width), but doing it for
all views will guarantee that their dynamic spacing calculation is
based on the same values.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
Since the parameter of the function is the width, reflect that in
the function name. Also, since we are counting columns, not only
children for each row, reflect that in the function name also.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
The new PaginatedIconGrid class acts as a container for pages.
So the new class provides the container behaviour and some
useful functions like positions of pages, number of pages, etc.
But, it doesn't add indicators of the pages and doesn't manage
the scroll of the pages, neither any management of the pages
like in which page currently it is, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=706081
This method, which accepts a .desktop filename, is used to highlight
a specific application in the overview, for example because it has
just been created or installed.
https://bugzilla.gnome.org/show_bug.cgi?id=654086
We added special code to sort each row in the overview so that
windows were less likely to cross lines, but the awkward control
flow meant that everything but the last row got sorted.
https://bugzilla.gnome.org/show_bug.cgi?id=707197
Activating the overview is fairly easy (hot corner, <super>), so doing it
automatically after closing the last window on a workspace does not save
a lot of effort; it does result in a surprising context switch when the
user does not expect the behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=662581
