diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 66 |
1 files changed, 49 insertions, 17 deletions
@@ -28,32 +28,64 @@ 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. + 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. - A single modkey-Tab would then get the focus to end up in the window where - we started. + 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... - It's possible to get a Release Event from the Alt key. Consider what - xev(1) says about the key. + 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. - 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. + GetModifierMapping - 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 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. - 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. + 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? + 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 |