diff options
author | MC <mc@hack.org> | 2010-06-30 14:17:42 +0200 |
---|---|---|
committer | MC <mc@hack.org> | 2010-06-30 14:17:42 +0200 |
commit | 920f5f853c6171a51e0c2cec4ebf98f68bd79462 (patch) | |
tree | 3790e405cf1847e148acf484a3be5fe41e2536f1 | |
parent | 987d76f050646b49a60fc305429373c92de52b68 (diff) | |
download | mcwm-920f5f853c6171a51e0c2cec4ebf98f68bd79462.zip |
Added notes.
-rw-r--r-- | TODO | 29 |
1 files changed, 15 insertions, 14 deletions
@@ -19,15 +19,14 @@ In order of importance: Partially done. Still needed: - Handle fixed windows when doing keyboard focus. Do we need them in - all lists? Or a special list for fixed windows? + - Handle fixed windows when doing keyboard focus. Do we need them in + all lists? Or a special list for fixed windows? - Store workspace data in an X property for the window? - - A window might be on one, several or all virtual screens. Add width - something like Mod2-f for "all virtual screens" and perhaps - something like Mod2-a <n>, where <n> is 1--9 for virtual screens. - Better ways? + - A window might be on one, several or all virtual screens. Add + width something like Mod2-f for "all virtual screens" and perhaps + something like Mod2-a <n>, where <n> is 1--9 for virtual screens. + Better ways? Note that this seems to be incompatible with the EWMH + _NET_WM_DESKTOP hint we're currently using. * "M" and "X" should toggle. @@ -42,12 +41,12 @@ In order of importance: * Use window resizing hints. Done, but needs looking over. Needs to use the data in the window - list. + list instead of asking the server every time. * Special treatment when someone resizes a maximed window... Should it - be possible at all? Set new border width. + be possible at all? Set new border width when they do it. - Set and read window hint about maximized state. + Possibly set and read hint about maximized state. * Figure out why unclutter doesn't work in default mode @@ -60,9 +59,11 @@ In order of importance: * Flag to disable dontmoveoff? * GTK apps has some extra windows that are initially unmapped. How do - we handle these? For now, we never map them and silently ignore - them. When we go to virtual desktops, this might become a problem. - How do we know that we're not supposed to map them? + we handle these? + + When we're starting and a GTK program is already running, these + windows becomes visible on a workspace. How do we handle them? How + do we know we're not supposed to map them, ever? * RandR/Xinerama |