1 This file is horribly out of date, see the fvwm bug web site at www.fvwm.org
3 Things that should be done for the next release:
5 * Should center icons even when out of space, not use NW gravity.
7 Things that will be done when I have lots of time:
9 * There really should be some interactive way to build the buttonbar :-)
10 Actually, I have it all worked out on paper, but it will not be done
11 until late april earliest.
13 Things that should be done to FvwmButtons some day:
15 * Get events from reparented windows to get actions on swallowed windows.
16 I tried to do this, but failed. See BUGS. Help me on this, someone!
17 Am I up to coding this now? Is there any need for it?
19 * Proper ICCCM compliance: check for WM_DELETE_WINDOW of children to decide
20 whether to kill or delete... more?
22 * Expand "Mouse" command to differentiate between Click, Move, DoubleClick
23 etc. Make "Key" command.
25 * Make it possible to have buttons that hang until the window they caused
26 to appear is gone again. (do panels do this?)
29 Things that could be done to FvwmButtons:
31 * Make it possible to have it invisible (unmapped) until the mousepointer
32 enters a specified InputOnly window on the screen - then it pops up, until
33 the mousepointer leaves it. (will be fixed if we ever do style autohide)
35 * Allow for linefeeds in titles, maybe have them wordwrap themselves if out
36 of space. Make it an option: Wrap. Linefeeds could be "\n" inside a string.
37 Mmm, linefeeds are not really needed. Wordwrap would be nice.
38 Also: preforming clipping instead of chopping on titles. This would
39 facilitate handling low roofs too.
41 * Make commands for interactive swallow and unswallow, what about
42 *FvwmButtons(Title Swallow,Action Swallow)
43 which could popup a crosshair pointer. Selected window is swallowed.
45 * On the subject of swallow; is it possible to make it swallow iconified
46 windows? Could unswallow on deiconify - making FvwmButtons a new IconBox!
47 :-) But seriously, could be worthwhile. Should be keine problem, just do
48 whatever the IconBox does.
49 Swallow(AsIcon) ".." `....`
51 * Make it a substitute for xbiff? Let it change state (icons) changeable
52 on the fly, on the output on a command run? That could be difficult as
53 they're run through fvwm... What about
54 *FvwmButtons(Icons nomail.xpm mail.xpm \
55 Watch 10 "/usr/spool/mail/luser" \
56 Action "Exec "exmh" (exec exmh)))
57 with two new things, Icons which takes two icons, one for normal state
58 and one for excited. This can also be used for normal buttons, when they
59 hang on something or when they are pressed they could show another icon.
60 The other new command is Watch, which takes a timeout in seconds and a
61 filename. When the file grows the button changes state, changing the icon.
62 How can this be extended to other things than file watching? It can't.
63 It would be nice to have it run any (shell) command, and change state
64 according to it's return code or output. This command could ping a host,
65 check your connection is up, and return errorcodes to FvwmButtons which
66 gives visual feedback. Or it could work through a pipe, getting fed back
67 commands that can be actions forwarded to fvwm (Beep, Exec), and other
68 icons to be shown (Icon mail-from-fvwm-list.xpm).
69 Pros for having this kind of functionality in FvwmButtons: Do you know
70 anyone, using FvwmButtons, that doesn't run xbiff equivalents in it?
71 Cons: it would have to be as functional as most of those, or it wouldn't
72 be used. this means POP, IMAP & NNTP support
74 The above can all be done if FvwmButtons listens for SendToModule messages
75 like SendToModule FvwmButtons <button number> title "new mail"
77 * Add favourite hack here. Make it vt100 compatible, support emacs editing
78 commands, or able to import Quake .PAKs. Someone probably needs that too.