This document discusses the history of X Window and Wayland, introduces Wayland and its components, describes how input method frameworks like iBus work with Wayland, and summarizes some hacks developed to improve internationalization support in Wayland. It provides background on how X Window clients render locally rather than through a central server, an overview of Wayland's design of direct client-server communication, and proposes an architecture where input method frameworks communicate directly with Wayland instead of bypassing the display server.

1. with i18n hacks
Peng Wu
Presented by
Red Hat
License statement goes here. See https://fedoraproject.org/wiki/Licensing#Content_Licenses for acceptable licenses.
Wayland intro

2. Today's Topics
1. X Window Background
2. Wayland intro
3. Wayland with input method frameworks
4. Wayland i18n hacks
5. Summary

3. X Window
Background

4. X originated at the MIT in 1984
Since then, never touched the core protocol
X Window History

5. parts of the core protocol seldom used today
X11 core graphics functionality seldom used
XIM protocol bypassed by input method
frameworks, such as ibus, scim, fcitx.
Why not X?

6. clients render locally
clients tell the X server what they've drawn
the server asks the WM to display it
the window manager decides what to draw
and where
the X server displays what the WM rendered
So, the window manager is the new X server
Client Rendering Steps

7. Wayland intro

8. Wayland - Wayland Compositor Infrastructure
Weston - The Weston Wayland Compositor
libinput - input device management and event
handling library
Wayland dissected

9. RPC mechanism designed for window system
Utility functions for client/server development
Generate codes from XML protocol definition
some client/server codes for communicating with
the display server.
Define the core wayland protocol
in protocol/wayland.xml
Wayland intro

10. The Reference Wayland Compositor
Reference Implementation
Support additionally protocols
in weston/protocol
Maybe we could call these as extensions?
For input method support
See text.xml and input-method.xml
Weston display server

11. clients render locally
clients tell the server what they've drawn
the server decides what to draw and where
So, Wayland just cut out the middle man
Client Rendering Steps

12. it's tractable
'every frame is perfect'
a set of pixels that should be shown in a window
coherently at one time
Wayland Pros

13. client says, 'display this'
server displays it
job done.
solely frame-based

14. Wayland with input
method
frameworks

15. Bus-Centric Architecture
It has an ibus-daemon, which manages all clients.
all engines, panel, config modules & clients are
clients of ibus-daemon.
iBus is based on dbus IPC protocol.
ibus intro

16. ibus architecture
ibus
daemon
Application
(GTK+)
Application
(QT)
ibus
XIM Server
ibus
panel UI
ibus
engine pinyin
ibus
engine anthy
ibus
config

17. XIM protocol is old, and have many problems.
Many GUI ToolKits implement own IMModules
Gtk+ - GtkIMContext
QT – QinputContext
The XIM is by-passed by default configuration.
ibus with X

18. Proposed architecture
Gtk+ App
Wayland
D-BUS ibus daemon

19. Every daemon serves one aspect of
functionality.
weston for display
dbus for RPC
ibus for input
Gtk+ Apps talks to the specific daemon only
when needed.
Why not by-pass display server again? ;-)
Advantages

20. Wayland i18n
hacks

21. fixes dual-width glyph spaces problem
learned it from vte widget
Fixes cursor problem with vim, emacs
respect the virtual terminal spec
weston terminal hacks

22. Wayland is wonderful
more works on Wayland i18n supports
input methods
font rendering
Summary

23. Questions?
License statement goes here. See https://fedoraproject.org/wiki/Licensing#Content_Licenses for acceptable licenses.
example@fedoraproject.org
Contact: