isa/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

citadel #1

Closed
isa wants to merge 29 commits from citadel into citadel-45.0
pull from: citadel
merge into: isa:citadel-45.0
Conversation 0 Commits 29 Files Changed 68 +5801 -2707
isa commented 2024-02-15 18:10:43 -05:00
Owner
Copy Link

WIP

WIP
isa added 29 commits 2024-02-15 18:10:44 -05:00 
If we get '' from the IM as the preedit string, it is pretty safe
to handle it as "no preedit" altogether.

(Cherry-picked from commit 286cfdc6d4)
This is now done in the ClutterInputFocus for us, since
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940. There
is no need to duplicate this call, and it happens to cause undesired
scrolling to content in some cases when this reset happens during
a change in the IM focused client state.

Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4647

(Cherry-picked from commit 047691b0d3)
If the preedit is in invisible state, the last preedit string that
was sent around is already null, so there is no need to clear the preedit
in that case.

(Cherry-picked from commit 0177560952)
Like the old Tweener API, ease() allows to transition multiple
properties at once. If autoReverse or repeatCount are specified,
they should apply to all transitions, but right now we only set
them for the first one.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2007>
(cherry picked from commit cc5cc0d653)
Since we are past the 40 API change hurdle, it is safe to revert this
commit.

This reverts commit 1cefd589da.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2010>
(cherry picked from commit ff4ff66498)
Windows from some applications, such as guake, are created as showing on
all workspaces. When these windows are put on the workspaces via
set_workspace_state() during construction, the first time the window is
added to a workspace in the loop triggers the shell app tracker which
then tries to move the window to its startup workspace. This makes the
window unsticky which triggers another set_workspace_state() which
tries to remove the window from all workspaces, but currently it is only
on the first one and then adds it to the startup workspace. Once that is
finished, the first set_workspace_state() continues adding the window
to the remaining workspaces, despite the window now no longer having
on_all_workspaces set to true.

When the window is now unmanaged, the window according to its internal
state is only found on the startup workspace, so it will only be removed
from that. This causes the assertion to fail that checks that the window
is no longer present on any workspace after this.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4720

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2014>
(cherry picked from commit bc32a52108)
Unlike g_warning() and friends, g_printerr() does not append
a trailing newline.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit 79f448958b)
We currently ignore any error that may occur when calling the
OpenExtensionPrefs D-Bus method. Right now such an error is highly
unlikely, given that we already checked that we are running under
gnome-shell and the extension in question exists and has prefs.

We'll soon make sure that only one dialog is shown at any time,
which is an error that we can realistically expect, so handle that
properly.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit 09ed1c533c)
GTK4 relies entirely on refcounting for cleanup (that is,
there is no longer a destroy() method that forces a dispose
run regardless of the refcount).

Unfortunately that makes cleanup harder in (some) language
bindings, where an object may be kept alive implicitly by
closures etc.

Address this by releasing the hold count when the window
is closed rather than when it is destroyed.

This isn't the most elegant, but it ensure that the service
doesn't get stuck if an extension doesn't carefully clean
up everything in its prefs widget.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit 4d2b008966)
Showing multiple preference dialogs at the same time (for instance
by repeated `gnome-extensions prefs` calls) may or may not work as
expected, depending on whether any of the dialogs is modal or not
(read: opened via the Extensions app).

The easiest way to address this is to disallow more than a single
dialog at the time. It's arguably also the more predictable behavior,
and means extensions don't have to deal with inconsistent state
caused by multiple dialogs.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4564

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2013>
(cherry picked from commit b93342f72e)
The change unvealed a series of mutter bugs that for most
users are worse than the issue that was fixed. So revert
the change on stable branches until the mutter side is
fixed.

This reverts commit cd1102ff30.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2022>
The changes introduce crashes, so back out until we
figure those out.

This reverts commits ceee53aa0a and 5d5bfe492c.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2022>
Update NEWS.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2022>
isa closed this pull request 2024-06-07 11:34:30 -04:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: isa/gnome-shell#1
No description provided.
Delete Branch "citadel"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?