syncing with latst changes, because cvs will be moved
[wmaker-crm.git] / TODO
blobbde63d4c13be2926196b9ce8d43b97bf993ef879
2 Do ASAP:
3 ========
4 - fix bestvisual selection code. Broken.
5 - fix RemakeStackList() to account for transient windows
6 - blink border of clients with UrgencyHint set between red and black
7 - finish session stuff
8 - fix scroller to not jump while dragging knob
9 - add multiline support for balloons
10 - move/add balloon to WINGs
11 - finish XStandardColormap stuff in wrlib
13 Need to do:
14 ===========
15 - allow user to select/restore default root menu from wprefs
16 - fix windoze cycle window patch
17 - support for X11R6.4 extension for getting extra visual info in wrlib's
18   automatic best context guessing
19 - docklet to control AccessX (keyboard accessibility) functions
20 - rewrite all redundant stuff to use WINGs
21 - resizebartexture option
22 - add function to directly make a thumbnail of an image, using the
23   functionality provided by the image libraries to load a minimal
24   amount of data.
25 + investigate memory leaks 
26 - rewrite defaults/wdefaults stuff to use WINGs UD stuff. Search list:
27   ~/G/D/WindowMaker /u/l/s/W/D/WindowMaker built-in-defaults
28 - remake internal string processing to use wchar? unicode?
29 - add new file for stuff like default commands and dnd commands for
30 docked apps, balloons for the dock etc
31 - alpha-channel app specified icons 
33 Maybe some day:
34 ===============
35 - virtual workspace
36 - optimize for size
39 Never: (so, dont even bother to ask)
40 ======
41 - different themes for each workspace. Unless you give us a SGI/Power Onyx
42 with 2 CPUs ;). 
43 - anything that requires the mouse pointer to be jumped by WindowMaker to
44 somewhere. This is *terrible* behaviour. And it's not just IMO.
47 - ICCCM 2.0: ICCCM 2.0 (not 1.0, which is what everybody supports so so) is
48 a relatively new standard and nobody, AFAIK, complies with it (not even
49 twm as people tend to think). It has some neat things, but many of the new
50 stuff is really weird and tricky to implement, not to say unworthy (read the
51 specs and you'll see). This is not bad, since I think it is very unlikely
52 that a client that requires it exists... Anyway, if we get an "official"
53 sample implementation (twm?) it might be supported. Maybe dtwm supports
54 it? I dont know...