summaryrefslogtreecommitdiff
path: root/TODO
blob: 028e51d7bde3ad7af9be27fa6b6c23f4daa80a96 (plain)
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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
-*- 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.

* 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 or named pipe 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.

  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.

  This will also need to work if the change focus with the mouse.

  A single modkey-Tab would then get the focus to end up in the window
  where we started tabbing or where we last had our focus if changing
  with the mouse.

  This is now implemented like this:

    Always keep the current window as the first element in the current
    workspace window list. Always keep the window we focused before it
    as the second element.

    When we focus on the next window from the current one, the first
    Tab always goes to the window we had focus in before.

  Currently, we stop tabbing when the MODKEY is released. We might
  want to stop tabbing and focus on the new window if we get another
  command as well...

  I have bound Alt_L explicitly and looking for key release events.
  This is a bit ugly. It is possible to ask for what keys give
  XCB_MOD_MASK_4 or whatever MODKEY is.

    GetModifierMapping

    This request returns the keycodes of the keys being used as
    modifiers. The number of keycodes in the list is
    8*keycodes-per-modifier. The keycodes are divided into eight sets,
    with each set containing keycodes-per-modifier elements. The sets
    are assigned to the modifiers Shift, Lock, Control, Mod1, Mod2,
    Mod3, Mod4, and Mod5, in order. The keycodes-per-modifier value is
    chosen arbitrarily by the server; zeroes are used to fill in
    unused elements within each set. If only zero values are given in
    a set, the use of the corresponding modifier has been disabled.
    The order of keycodes within each set is chosen arbitrarily by the
    server.

    xcb_get_modifier_mapping()

    xcb_get_modifier_mapping_unchecked()

    xcb_keycode_t * xcb_get_modifier_mapping_keycodes()

    xcb_keycode_t *
    xcb_get_modifier_mapping_keycodes (const xcb_get_modifier_mapping_reply_t *R  /**< */);

    xcb_get_modifier_mapping_keycodes_length (const xcb_get_modifier_mapping_reply_t *R  /**< */);

  How do we re-establish stack order after moving around windows to
  focus on? Do we want to?

  There is a bug when we change from one ws to another and focuswin
  doesn't get reset. That is, focuswin isn't NULL but the
  focuswin->wsitem[curws] is empty.

* 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. Perhaps use an external program somehow? Needs to talk to mcwm
  anyway. Unix socket?

* 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.

* Code cleaning

  - Obivous cleanup: The event switch is way too big.

  - The states are known everywhere. A tight state machine would be
    nicer.

  - Dispatch table for key bindings instead of keysym->enum->case?

  - Use bitfields instead of extra lists for virtual screens?

* Resize behaviour

  Better resize behaviour. We want not to accidentally change the
  vertical size when changing horizontal size and vice versa.