We currently create the default folder with the corresponding
app list, regardless of whether the apps are actually part of
the default install or not.
This matters when a user explicitly install such an app later,
as it will be hidden away in the folder rather than appended
to the app grid as expected.
To avoid that, only add currently-installed apps to the folder
when creating it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
Defining default apps as serialized GVariants isn't very human-friendly,
which likely contributes to the fact that the lists are in parts horribly
outdated (Books! Cheese! Screenshot! gedit!).
Instead, generate the lists at build time from simple text files, which
should be much easier to update.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3632>
This adds a comment to make clear that the Utilities category is
intended to be organized alphabetically by the display name of
the apps (*not* by the desktop file names), and adds comments
with the current display name of each app.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3609>
These have (Logs) or previously had (Characters) the
X-GNOME-Utilities category in their .desktop file and so showed
up in the Utilities folder (despite 152faae claiming that the
category was "completely unused"). Characters had the category
removed in
https://gitlab.gnome.org/GNOME/gnome-characters/-/commit/210eb09
in apparent expectation that it would be added to the list, but
it seems it was not.
We could restore consideration of the category, but I guess let's
just list the apps instead? I don't know if any others are
missing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3607>
Instead of having the name of the directory be X-GNOME-Utilities. This
also allows translating the name to the user's language. The name is
chose to be different to X-GNOME-Utilities from GNOME Menus.
In the process, also remove the categories. The menu definition from
gnome-menus is not used, and it's not a category that apps list
themselves, so it's completely unused anyway.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3526>
When an app folder is opened it would do so without grabbing the
keyboard focus, so one could not navigate with the arrow keys without
pressing Tab. This adds the focus parameter to popup()'s grab, which
sets the key focus to the elements of the folder when it is opened.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
The AppFolderDialog would lose keyboard focus after editing the title
(likely due to the folder entry grabbing key focus). This commit adds
navigate_focus() to _showFolderLabel() to send key focus back to the
dialog's elements after editing the title.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3338>
The offset was given as a hardcoded (physical) pixel value and did not
take scaling into account. This lead to it being shifted closer towards
the icon as the scale increased.
This now replaces the hardcoded value with a CSS property which
automatically includes the scale factor.
Further this allows simplifying some calculations that previously were
trying to counteract the hardcoded offset using margins by using the
intended offset directly.
With this the dot in the dash is also now placed at exactly the bottom
of the hover highlight, while previously there was an unintentional 1px
space.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7488
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3245>
We use the pagePadding to adjust for the large indicators that we add on the
left and right of the appGrid.
While the original padding needs to be applied to the padding for the
indicators (as it was in super.vfunc_style_changed already), there's no
reason to add an extra row and column spacing to the pagePadding on all
sides, so remove that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3278>
- updated mixin for tile_button
- dropped the overview_button mixin
- minor changes to dash, appDisplay and switcherPopup JS to accommodate new stylesheet
- new focus style for all tile buttons
- improved high contrast style support for app grid and dash
- renamed some style-classes
- tidied up dash stylesheet
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3017>
- new drawing function to convert px to em, for select instances
- updated fontsize function to convert fonts in pt to em
- replace instances of discrete sizes with defined values
- fix instances where assets or icons did not scale along with text
- rework panel buttons to accommodate the scaling padding and icons
- new 'scalable' definitions for elements that follow text scaling
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3033>
These have been long deprecated over in clutter, and (via several
vtables) simply forward the call to the equivalent ClutterActor methods
Save ourselves the hassle and just use ClutterActor methods directly
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3010>
When GridSearchResults::_getMaxDisplayedResults() is called after the
first character has been entered in the search, GridSearchResults has
no children yet. _getMaxDisplayedResults() tries to determine the
maximum number of search results based on how often the largest child
would fit into the allocated size or -1 (i.e. no limit) if there are no
children. So for the initial search there is no limit and in the app
search all matching apps get added as possible results, which due to the
search term being only a single character is almost all installed apps.
This now causes allocation to be run for all these results, despite the
vast majority of them never being visible, which on slower machines can
cause noticeable delays before the search results are displayed.
This now adds the ability for search providers to specify a maximum
number of results that gets used instead of -1 when specified. By being
provider specific this means extensions implementing their own providers
will not be affected by this.
Further this sets the maximum for the app search provider to 6 as per
the current designs.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7155
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3004>
We have been using type-safe comparisons in new code for quite a while
now, however old code has only been adapted slowly.
Change all the remaining bits to get rid of another legacy style
difference.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
We have made good progress with transitioning to the new style,
to the point where we can complete it with a final push.
Start with changing the remaining places that still use double
quotes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2866>
These traditionally got the various ClutterEvent subtype structs as their
argument, so it was not allowed to use ClutterEvent generic getter methods
in these vfuncs. These methods used direct access to struct fields instead.
This got spoiled with the move to make ClutterEvent opaque types, since
these are no longer public structs so GNOME Shell most silently failed to
fetch the expected values from event fields. But since they are not
ClutterEvents either, the getters could not be used on them.
Mutter is changing so that these vmethods all contain an alias to the
one and only Clutter.Event type, thus lifting those barriers, and making
it possible to use the ClutterEvent methods in these vfuncs.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2950
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2872>
The FolderView is a subclass of BaseAppView, which already has a
full-blown SwipeTracker attached to it. So no need to add another
PanGesture on top, the SwipeTracker will handle it for us.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2318>
This behavior makes more sense to have in the iconGrid itself: When a
page is filled up with items, the new item should never go to the start
of the next page, but always to next empty slot.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Folders reflow across pages because they don't set
allow_incomplete_pages to true. This means we want the nudging of items
to happen slightly differently when dragging an item across pages:
- When dragging from lower page index to a higher one, always reflow
towards the start of the grid (because there's now an empty slot on the
old page and items on the new page will force-reflow towards that)
- When dragging from a higher page index to a lower one, we can reflow to
the end as we usually do
To archive this, factor out the selection of "reflow direction" into a
separate variable that always defaults to "end" (because empty space is
always at the end of the grid). Set it to "start" when the item created an
empty slot on the current page or (and this is new:) on a previous page in
the folder case.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
The iconGrid's getDropTarget() API supports dropping items to adjacent
pages just fine, but in the AppDisplay, we clip the grid and don't show
those adjacent pages. That doesn't stop getDropTarget() from picking
drop targets which are on adjacent pages though, so we need to filter
those out in the layer above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Returning a page and a position for the drop target seems more
straightforward than returning an actual grid item in getDropTarget().
With the next commit, this will allow us to throw away drop targets that
are not on the current page.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
_getLinearPosition() is a function that converts a page and position
index to the "accumulated" index that includes all pages before the
page. The function is used by _addItem() and _moveItem() for getting the
new index of an item inside the _orderedItems array.
Now when passing -1 as position to _addItem() or _moveItem(), this means
the item should be appended to the page. Right now _getLinearPosition()
returns the last item index on the page when passed -1, inserting the
item into _orderedItems at this index will actually not append it, but
insert it between the second last and last item.
To fix it, let's make the whole thing more robust by explicitly passing
an item to _getLinearPosition(). This means we simply no longer have to
assume what "-1" means. Moving the call to _getLinearPosition() to
happen after addItem() and moveItem() ensures that the new item position
is used and not the old one.
This fixes issues where the _orderedItems array gets out of order when
moving or adding items.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2348>
Dropping a icon from the dash to the application grid will set this._placeholder
to null. However the AppIcon is still used to represent the application in the
application grid. If we click on it we emit a pressed event. Stop assuming
that this._placeholder is still valid in the callback, use the icon parameter
instead.
This fixes the following error:
```
Gjs-CRITICAL **: 18:22:39.003: JS ERROR: TypeError: this._placeholder is null
_ensurePlaceholder/<@resource:///org/gnome/shell/ui/appDisplay.js:1477:17
vfunc_button_press_event@resource:///org/gnome/shell/ui/appDisplay.js:3121:27
```
Fixes: 6fc93b78bc54763c0876951f2425fcfd96f61f00
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6317
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2606>
