xenocara/app/fvwm/modules/FvwmButtons/TODO

Things that should be done for the next release:

 * Work in progress: free setting of relief and shadow color, getting back
   background pixmaps. Optional extra arguments to Frame.. Frame f1 f2 would
   be for normal/depressed relief width... Frame f1 f2 f3 f4 could be
   normal x/normal y/depressed x/depressed y relief widths...

 AND

   implement padding _between_ buttons... how? Hmmm.
   -> Buttons geometry patch allows this.

 * How about being able to put a pixmap to the background of FvwmButtons?
   A marble surface would be nice. Shading for frames can be done with
   interleaving black or white pixels. This should probably be done anyway...
   This can also be used to emulate OpenStep toolbar...
   Update: This was done but disappeared in a crash, will be redone when
   I have time to do it properly.
   Update (Dominik Vogt): at least background pixmaps seem to work (but not
   with swallowed apps, only simple buttons.

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

 * Bugfixes? Bugfixes. Bugfixes!?


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?

 * Make it create hints that only allows it to be scaled to "proper" sizes,
   i.e. with all buttons properly sized.
   Today it only considers the number of buttons in the UberButton, so if you
   make one container outside all your buttons, to give it a frame, it will
   give you free resizing. (Only one button, eh?)

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

 * Investigate transparent buttons.

 * Make it possible to have buttons that hang until the window they caused
   to appear is gone again.


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.

 * 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.

 * Let containers have titles and icons. This would be awesome! Update: not
   really needed, can be done by putting some extra buttons in there...

 * Make option for using a limited colormap, say: use 16 colors max
     *FvwmButtonsColorMax 16
   This should be doable by preparing a dummy colormap to give to xpm.

 * Try to find a way to activate Popup menus and Functions. This seems awfully
   difficult, as fvwm keeps a tight lid on them. Not possible through the
   protocol. Maybe we should cheat and load the config file ourselves?
   Update: Popup menus now work courtesy of a simple hack at fvwm. Functions
   are harder it seems... at least they didn't work with the same hack.

 * 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) ".." `....`

 * Rewrite parser, somewhat lex/yacc style, let it eat the BNF.
   There is really no need for this, actually the current parser is tight
   and somewhat elegant... Update: Hmm, actually the parser code is huge...
   I can't believe how huge it is? 17kb out of 75kb .o file (Solaris 2.2) is
   made by the parser... Hmm.

 * What about resizing icons on the fly? Buttons with Resize specified can
   make icons fill it.
     *FvwmButtons(Resize Icon gigantic.xpm)
   Should Resize automatically imply NoSize (above)?

 * 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.

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