We already have ClutterColor to represent a color, and StIconColors
to hold color information for symbolics from CSS. Now that we moved
GtkIconTheme in-tree, we can make use of those types instead of
translating back and forth from GdkRGBA.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
We are still linking to GTK, and extensions may import GTK for
whatever reason, so avoid conflicts by moving the copied GTK
code into our namespace.
With that and the previous adjustments, the new code is now
finally buildable.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Its use has been discouraged for years, and glib recently deprecated
it officially (while turning it around a small wrapper around malloc).
Don't let it sneak back in through some old GTK3 code.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code predates the G_DECLARE_*() macros, so it's under- standable
that it still does all the boilerplate manually. We
don't have that excuse in 2023, so move the the standard macros.
There is no reason for GtkIconTheme to be derivable, and as that
means that the instance struct itself is private, stop adding
separate private instance data.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK uses its own private i18n header, which most notably defines
an I_() macro for interning static strings. That may be a worthwhile
idea for the entire codebase, but as it's out of scope for this
change set, just use the standard i18n support from glib for now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
Those are GTK internals that don't apply to us. Without the distinct
"screen's default icon theme", we also don't need custom theme support,
and can just always track the theme from StSettings.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
The GTK code dates back to a time when "gchar" and friends were
still considered a good idea. Replace them with standard types
except for "guint" (I'm lazy) and GtkIconCache code that relies
on glib's byte order macros.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GtkIconTheme's headers are split between a public and a private
one. We won't expose the icon theme API at all, nor do we need
to access anything beyond what the texture cache is currently
using, so merge the private header into the implementation.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
GTK4 changed icon loading significantly, it is now closely tied
to snapshots and paintables. This makes a port highly unrealistic,
so to avoid staying stuck on GTK3 forever, copy the relevant code
into the tree.
The code is unmodified except for the include names and replacing
some stray tab indentation. It is still full of GTK internals, so
it will take a while before we can actually build it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2620>
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>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the gesture when a grab operation
begins. With grab ops being based on ClutterGrab now, the gesture
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This is done just to "reset" the click action when a grab operation
begins. With grab ops being based on ClutterGrab now, the action
will be implicitly reset when these happen. This is unnecessary now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
This reverts commit 2b3ab3ecec.
Since the window menu no longer uses a MetaDisplay grab, but directly
a ClutterGrab, this is ineffective. But also, grabs are stackable, so
it's fine to push the window operation grab first and then dismiss the
window menu grab, even when MetaDisplay grabs get ported to using
ClutterGrab underneath. We now can just grab right away, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2526>
