This file is horribly out of date, see the fvwm bug web site at www.fvwm.org

Things that should be done for the next release:

 * Should center icons even when out of space, not use NW gravity.

Things that will be done when I have lots of time:

 * There really should be some interactive way to build the buttonbar :-)
   Actually, I have it all worked out on paper, but it will not be done
   until late april earliest.

Things that should be done to FvwmButtons some day:

 * Get events from reparented windows to get actions on swallowed windows.
   I tried to do this, but failed. See BUGS. Help me on this, someone!
   Am I up to coding this now? Is there any need for it?

 * Proper ICCCM compliance: check for WM_DELETE_WINDOW of children to decide
   whether to kill or delete... more?

 * Expand "Mouse" command to differentiate between Click, Move, DoubleClick
   etc. Make "Key" command.

 * Make it possible to have buttons that hang until the window they caused
   to appear is gone again. (do panels do this?)


Things that could be done to FvwmButtons:

 * Make it possible to have it invisible (unmapped) until the mousepointer
   enters a specified InputOnly window on the screen - then it pops up, until
   the mousepointer leaves it. (will be fixed if we ever do style autohide)

 * Allow for linefeeds in titles, maybe have them wordwrap themselves if out
   of space. Make it an option: Wrap. Linefeeds could be "\n" inside a string.
   Mmm, linefeeds are not really needed. Wordwrap would be nice.
   Also: preforming clipping instead of chopping on titles. This would
   facilitate handling low roofs too.

 * Make commands for interactive swallow and unswallow, what about
     *FvwmButtons(Title Swallow,Action Swallow)
   which could popup a crosshair pointer. Selected window is swallowed.

 * On the subject of swallow; is it possible to make it swallow iconified
   windows? Could unswallow on deiconify - making FvwmButtons a new IconBox!
   :-) But seriously, could be worthwhile. Should be keine problem, just do
   whatever the IconBox does.
     Swallow(AsIcon) ".." `....`

 * Make it a substitute for xbiff? Let it change state (icons) changeable
   on the fly, on the output on a command run? That could be difficult as
   they're run through fvwm... What about
     *FvwmButtons(Icons nomail.xpm mail.xpm \
                  Watch 10 "/usr/spool/mail/luser" \
                  Action "Exec "exmh" (exec exmh)))
   with two new things, Icons which takes two icons, one for normal state
   and one for excited. This can also be used for normal buttons, when they
   hang on something or when they are pressed they could show another icon.
   The other new command is Watch, which takes a timeout in seconds and a
   filename. When the file grows the button changes state, changing the icon.
      How can this be extended to other things than file watching? It can't.
   It would be nice to have it run any (shell) command, and change state
   according to it's return code or output. This command could ping a host,
   check your connection is up, and return errorcodes to FvwmButtons which
   gives visual feedback. Or it could work through a pipe, getting fed back
   commands that can be actions forwarded to fvwm (Beep, Exec), and other
   icons to be shown (Icon mail-from-fvwm-list.xpm).
      Pros for having this kind of functionality in FvwmButtons: Do you know
   anyone, using FvwmButtons, that doesn't run xbiff equivalents in it?
   Cons: it would have to be as functional as most of those, or it wouldn't
   be used. this means POP, IMAP & NNTP support

   The above can all be done if FvwmButtons listens for SendToModule messages
   like SendToModule FvwmButtons <button number> title "new mail"

 * Add favourite hack here. Make it vt100 compatible, support emacs editing
   commands, or able to import Quake .PAKs. Someone probably needs that too.