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 23:10:43 +00:00
Owner
Copy Link

WIP

WIP
isa added 29 commits 2024-02-15 23:10:44 +00: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 286cfdc6d48dc4315df54d29d7d16b5198d92a56)
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 047691b0d3471630ec80e32f371291dd2ef02419)
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 01775609525b12de752a2f7ebac88baee9b041d3)
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 cc5cc0d653ccd307475921bf069773d44b34aa5e)
Since we are past the 40 API change hurdle, it is safe to revert this
commit.

This reverts commit 1cefd589da2edca84d19b285d553e2a68cda3e37.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2010>
(cherry picked from commit ff4ff66498ec374fce5b22b8bc01b523d1304e0b)
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 bc32a5210823c40016084c1d128c3113015e08cf)
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 79f448958b5ea16bc6a1f91117ed02a889712c90)
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 09ed1c533c2350b81e2c79f84998e8d3b4c1199a)
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 4d2b008966266ed96325dfd2cf7ebe41902aa270)
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 b93342f72e871dc8472a9e92b23b45e0e7ded282)
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 cd1102ff30b134e45e9b5ab48318e6a4eae03416.

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 ceee53aa0a4 and 5d5bfe492cd81.

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 15:34:30 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
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?