set_ime_cursor_area uses the top left corner of the rectangle as the composition/cursor point on X11

[xorgy]

Description

On X11, unlike other platforms (windows, macOS), Window::set_ime_cursor_area behaves differently from how it is described in the documentation.
In particular, it ignores the height of the rectangle, and submits the top left corner as the composition/insertion point:

winit/src/platform_impl/linux/x11/window.rs

Lines 2034 to 2042 in c913cda

	#[inline]
	pub fn set_ime_cursor_area(&self, spot: Position, _size: Size) {
	let (x, y) = spot.to_physical::<i32>(self.scale_factor()).into();
	let _ = self.ime_sender.lock().unwrap().send(ImeRequest::Position(
	self.xwindow as ffi::Window,
	x,
	y,
	));
	}

Whereas on Windows, the height is added to produce the equivalent:

winit/src/platform_impl/windows/ime.rs

Lines 123 to 126 in c913cda

	let composition_form = COMPOSITIONFORM {
	dwStyle: CFS_POINT,
	ptCurrentPos: POINT { x, y: y + height },
	rcArea: rc_area,

And on Mac, NSView gives a rectangle for this operation, which the system will avoid placing the candidate window over (still assuming the bottom left corner, typically)

winit/src/platform_impl/apple/appkit/view.rs

Lines 370 to 384 in c913cda

	#[method(firstRectForCharacterRange:actualRange:)]
	fn first_rect_for_character_range(
	&self,
	_range: NSRange,
	_actual_range: *mut NSRange,
	) -> NSRect {
	trace_scope!("firstRectForCharacterRange:actualRange:");
	let rect = NSRect::new(
	self.ivars().ime_position.get(),
	self.ivars().ime_size.get()
	);
	// Return value is expected to be in screen coordinates, so we need a conversion here
	self.window()
	.convertRectToScreen(self.convertRect_toView(rect, None))
	}

This results in the candidate window being reliably placed overtop the preedit text, without platform-specific workarounds.

OS and window mananger

Xorg 21

Winit version

0.30.5

[kchibisov]

I think the docs mention that it's not implemented on X11? The issue is mostly that I don't think there's an API for that, winit could try to e.g. put the thing below what was submitted, but it could break.

[kchibisov]

The APIs you see on other platforms require you to pass a rectangle to not obscure an area, so they are just different and compositor positions the window in a way to not obscure it.

[xorgy]

@kchibisov The problem is that if you use this API as documented, you will obscure your text 100% of the time with the most common X11 IME (iBus). If you ignore the documentation and send only a Position at the baseline with no size, you get usable behavior most of the time, but then you are misusing the API on every other platform.

The API being called in the X11 backend as far as I'm aware is meant to be given the equivalent of ptCurrentPos on Windows, as most implementations rarely place the candidate window anywhere but below the given point, but I may be wrong about that.

[xorgy]

Of course, you could also make a case for adding width to x in this case, because ibus on XIM will still obscure the line if it is near the bottom of the screen.

[kchibisov]

The thing is that none of that will happen with any of the other backend, though, it' x11 and i don't care that much.

[xorgy]

Alright so I've talked with Fcitx @wengxt and he's willing to accept an attribute on the XIM IC, I'll see if I can confirm with Mr. Fujiwara about a name for the attribute for adding this to iBus as well.