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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
-*- text -*-
* Grab specific keys
Current code grabs modifier keys and any other keypress. We need to
specifically grab the keycodes we need. xbindkeys and possibly other
programs don't work.
Partially done. Now grabs all our keys unshifted as well as shifted.
Needs a way to tell in config.h what extra modifier is used.
* MappingNotify
Need to handle any changes of the keyboard mapping.
* Feedback window
We need to tell the user the new geometry somehow. Is this what I
want?
The feedback window can also show what workspace we just changed to.
Can we cooperate with a stand-alone program? Write our status to a
root hint than can be picked up by another program?
* Changing focus from keyboard
Save the subwindows of the root window and focus each when pressing
modkey + user_key_change. First option always last focused window.
Partly done. I have added a linked list of all windows and can walk
around them in a simple window ring.
I would like it to work like this: modkey-Tab-Tab-Tab... Release
modkey to focus on a window *and* to remember the window where we
started. The window we remember would be moved to the next position
in the window list.
A single modkey-Tab would then get the focus to end up in the window where
we started.
It's possible to get a Release Event from the Alt key. Consider what
xev(1) says about the key.
I don't know if it's possible to ask the X server what keycode currently
gives you XCB_MOD_MASK_4 or whatever, which would be the nicest way.
I guess, but I haven't yet tried, that I will have to do a specific grab
key for the XK_Alt_L or whatever instead.
This also means we have to add a new state, just like MCWM_MOVE et
cetera, to know that we're currently jumping around the window list
trying to find our next focused window.
How do we re-establish stack order after moving around windows to
focus on?
* Virtual screens/workspaces
Partially done. Still needed:
- A window might be on one, *several* or all virtual screens.
We already have a way of fixing a window on all screens (Mod2-f),
but we need a way of saying "stick on this workspace". Perhaps
something like Mod2-a <n>, where <n> is 1--9 for virtual screens.
Better ways? Note that this seems to be mildly incompatible with
the EWMH _NET_WM_DESKTOP hint we're currently using: We will only
be able to save one of the desktops used.
* Hide windows
Instead of iconifying, hide them à la 9wm. Even if we use a key to
hide them, this probably means we have to have a menu to get them
back.
* Menu
We might need a menu for hidden windows (see above). Since I'm
probably implementing menu windows anyway, perhaps I should add a
menu with basic window functions, like 9wm and twm. This way, one
might use the window manager without keyboard, if necessary. Not
much work if I have to do the menu anyway... But also chords?
* Chords
Maybe have mouse button chords to do move and resize? Configurable
if on or off?
Idea from Christian Neukirchen.
* Snap to border and screen edge, which favours the edge.
* Gaps on borders for docks, status windows et cetera.
Keep space reserved for Conky, dzen2 et cetera.
Also respect EWMH hints _NET_WM_TYPE_DOCK and _NET_WM_TYPE_DESKTOP.
* Flag to disable dontmoveoff?
* RandR/Xinerama
Get physical screen characteristics for every screen. Maximize, move
to corners should respect the screen it's on. We want a set of
workspaces for every physical screen as well.
xcb_randr_screen_size_t
xcb_randr_screen_size_iterator_t
xcb_randr_get_screen_info_reply_t
xcb_randr_set_screen_size_request_t
How do we handle window moves from one screen to another. Should we
snap to the physical screen's edge and then allow move to continue?
An idea from Christian: Use a huge virtual screen and make physical
screens map to it. Perhaps we can actually manage to have a window
on two physical screens at once?
* Key to move pointer to another physical screen.
* Use xcb-event's event handlers?
* Configurable keys.
* Configuration file.
* Start configurable programs when clicking on root window.
* Handle Urgency hint
Some windows might need attention and marks this with an urgency
hint (for instance, urxvt can generate such a hint when receiving
the BEL character). Do we want to handle it? How do we tell the
user? Can this be done with some stand-alone program instead?
* Support sensible portions of ICCCM and EWMH
EWMH hints that tells applications about active workspace and
focused window...
And a few others.
* Use bitfields instead of extra lists for virtual screens?
* Dispatch table for key bindings instead of keysym->enum->case?
|