1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
Communication between the selector and indicator
================================================
The idea behind selectors and indicators is following:
The current selection is always published in a property of the root
window. If it is not set, default keymap is assumed.
The indicator is used to indicate a selected keyboard (normally in
the panel, taskbar etc.). The indicator announces its presence by
creating a property on the root window stating a window that should
receive the notifications.
The selector provides a way to select a keyboard from the ones defined
in xkbsel database. It may query the system for a configured short
list (get_menu_info) or it may set any of the existing keyboards
expicitly. After successfull change it queries the indicator's
property on the root window and sends a notification there
(some sanity checks are performed).
As soon as the notification is received, the indicator fetches the
current keyboard from the root window property and displays it.
The X protocol already contains a property notification event,
but this option is not used here for the notifications. As there
are highly abstract toolkits where there might be a problem
to install a custom X event filter, the notification simply
simulates a left button click on the notification window.
If there is a real click, nothing bad happens - the indicator
simply redraws itself. This implies of course, that you cannot
install any other action on the button press - you probably best
use some invisible (moved out of sight, 1x1 pixel, ...) window
for this. Bear in mind that this window must be realized
(physically exist in server), otherwise you have nothing
that can receive events.
The selector and indicator can be (and normally will be) combined
into one program , but it is not a must.
The protocol:
selector root window indicator
| | |
1. | | announces its presence
| |<------------------------------|
| | |
| | |
2. selects keyboard | |
| | |
| | |
| | |
3. announces the current selection | |
|-------------------------------->| |
| | |
| | |
4. reads where the indicator resides | |
|-------------------------------->| |
| | |
| | |
5. notifies the indicator | |
|---------------------------------------------------------------->|
| | |
| | |
6. | | reads the current selection
| |<------------------------------|
| | |
| | |
7. | | displays the selection
| | |
1. notify_me() called by indicator at start
3., 4., 5. publish_current_sel() called by selector after keymap selection
6. get_current_sel() called by indicator at click in the window
Window properties:
Root window:
XKBSEL_CURRENT_KEYBOARD(STRING)
current keyboard selection
format: map_name<space>shortcut
shortcut may contain spaces
XKBSEL_INDICATOR(WINDOW)
a window where a keypress should be generated
Indicator window:
XKBSEL_MAGIC(STRING)
Used for sanity checks, so we don't send artificial clicks
to something that is not an indicator (in the case the indicator
crashes and X server reuses the window). The content is ignored.
|
