The ForwardKeyEvent ibus signal is used to maintain ordering between CommitText events and non-IME key events.
The ordering is important for Korean IMEs, where it automatically commits text whenever a character is fully composed. This is different from Chinese/Japanese IMEs, where user manually presses a key to commit each word.
Without this patch, kitty can't handle non-IME key events when used with ibus-hangul, which utilizes ForwardKeyEvent signal.
Without ForwardKeyEvent:
```
key | sequence of events from application's view
r | UpdatePreeditText 'ㄱ'
k | UpdatePreeditText '가'
1 | (receives the reply to ProcessKeyEvent call: "native_key: 0x31 release: 0 handled: 0")
| -> UpdatePreeditText ''
| -> CommitText '가'
```
Application receives "1가", which is incorrect.
With ForwardKeyEvent:
```
key | sequence of events from application's view
r | UpdatePreeditText 'ㄱ'
k | UpdatePreeditText '가'
1 | (receives the reply to ProcessKeyEvent call: "native_key: 0x31 release: 0 handled: 1", and kitty discards the event)
| -> UpdatePreeditText ''
| -> CommitText '가'
| -> ForwardKeyEvent keysym=0x31("1")
```
Application receives "가1", which is correct.
Relevant ibus-hangul github issue to implement ForwardKeyEvent: https://github.com/libhangul/ibus-hangul/issues/42
Relevant changes in Qt to handle ForwardKeyEvent: https://codereview.qt-project.org/c/qt/qtbase/+/212179, https://codereview.qt-project.org/c/qt/qtbase/+/255587
fcitx5 works fine with kitty, except that when you restart fcitx5, kitty stop working with fcitx5, because the dbus_connection_get_is_connected(ibus->conn) in #check_connection is always true when you use fcitx5.
this patch add a dbus name owner changed detection to detect the online status of ibus, in case the ibus backend uses the session bus, like fcitx5.
Try to ensure we have a functioning displaylink always.
GLFW skips over sleeping monitors during a poll and also
had a bug where the display link was not re-created for a monitor
that already had a glfw monitor entry.
Also add a bunch more debug reporting
Sway will send the next configure event (for example when focus changes)
with titlebar height added, so to avoid a sudden resize at that time,
bump the height by the titlebar.
This is caused, as far as I can tell, by CVDisplayLink getting stuck.
Apple apparently are incapable of writing a simple timer robustly.
So if it remains stuck after a second delete and recreate it to force it
to restart.
Fixes#2016
Apparently mutter needs window geometry set after the surface commit not
before, otherwise it doesnt "stick". When decorations are not hidden
there were other commits caused by the decorations, masking the issue.
Fixes#3507
The constants `NSControlStateValueOn`, `NSControlStateValueOff` and `NSControlStateValueMixed` are only available for macOS 10.13 or above according to https://developer.apple.com/documentation/appkit/nscontrolstatevalueon?language=objc.
Without this commit, compilation fails with this message:
```
glfw/cocoa_window.m:1537:28: error: use of undeclared identifier 'NSControlStateValueOn'
item.state = NSControlStateValueOn;
^
glfw/cocoa_window.m:1539:28: error: use of undeclared identifier 'NSControlStateValueMixed'
item.state = NSControlStateValueMixed;
^
glfw/cocoa_window.m:1542:47: error: use of undeclared identifier 'NSControlStateValueOn'
item.state = controller.isDesired ? NSControlStateValueOn : NSControlStateValueOff;
^
glfw/cocoa_window.m:1542:71: error: use of undeclared identifier 'NSControlStateValueOff'
item.state = controller.isDesired ? NSControlStateValueOn : NSControlStateValueOff;
^
```
To fix this, simply redefine the constants to use the old and now deprecated constants on older macOS versions.
The code that causes this was introduced in 98519bf326834a126e89489a6a221ff21fab100f.
The current version of GNOME has a regression that causes the compositor
to send incorrect geometry with the next configure event if the CSD
buffers are created after a call to set_window_geometry.
So call set_window_geometry last. And shake head sadly.
