* Does WMBiff have a mailing list?
Subscribe to firstname.lastname@example.org.
echo "subscribe wmbiff-devel" | mail email@example.com
* Why doesn't WMBiff update immediately after I read my mail?
WMBiff looks only at the flags associated with mail messages
to decide if they've been read. If your mail reader doesn't
bother to update those flags immediately after you read a
message, WMBiff has (essentially) no way of knowing that
you've read the message.
There are some workarounds: In mutt, you can ask it to sync
the mailbox using the sync-mailbox command: it will write
the mailbox file to disk (or back to the IMAP server) so
that WMBiff can update its counters. Mutt's sync-mailbox
command is bound to the $ key by default. In Mac OS X mail,
changing to a different mailbox usually flushes changes,
so I often hit Command-4 to switch to the sent mailbox
for a few seconds.
No workarounds are known for Kmail, which updates the status
flags of all mail as if it were read, then adds its own
status field to note that some are unread. (sourceforge
* WMBiff doesn't work. How do I submit a bug?
See the Troubleshooting section of the wmbiffrc man
If that doesn't work, run 'wmbiff -debug > wmbiff.log' and
remove any passwords left in wmbiff.log. Submit this log
and your wmbiffrc (sanitized of passwords of course) using
'reportbug' under Debian, or by sending mail to
* WMBiff doesn't do something I want. How do I suggest a feature?
If using Debian, use 'reportbug wmbiff' and submit a
wishlist bug. Or, send mail with your suggestion to
firstname.lastname@example.org. Feature requests on
sourceforge don't get the same attention.
Some previously requested features can't be done:
- Count IMAP deleted messages separately (the protocol
doesn't support it without locking the mailbox).
- Reset the count of new messages to zero when spawning
a mailer (it would just jump back again the next time
Previously suggested features that are really hard:
- Support dock sizes other than 64x64
- Inverse video on new mail (or do more visually to grab attention)
* I'm about to start writing a patch. How do I make sure it will
get incorporated in WMBiff?
Start a conversation on wmbiff-devel, and you'll probably
get some help.
Avoid creating new Clients.
- If you want an existing client to do something differently,
find a way to parameterize its behavior.
- If you want to use a shell command to get some
information, make a recipe for ShellClient (open wmbiff.c
and search for 'gicu').
If you must create a new client, Avoid Duplicating Code.
Document your patch. Add entries as appropriate to:
* How do I get the very latest WMBiff from SourceForge CVS?
See http://sourceforge.net/cvs/?group_id=26389, or
http://sourceforge.net/projects/wmbiff then click on CVS.
cvs -d:pserver:email@example.com:/cvsroot/wmbiff login
cvs -z3 -d:pserver:firstname.lastname@example.org:/cvsroot/wmbiff co wmbiff
* I added a feature to WMBiff. How do I submit a patch?
** If you've modified code from a .tar.gz
If you've modified a version of WMBiff downloaded from the web:
(in the wmbiff-x.x.x/wmbiff directory)
mv wmbiff-x.x.x wmbiff-changed
tar xvfz wmbiff-x.x.x.tar.gz
diff --unified --recursive --new-file wmbiff-x.x.x wmbiff-changed > my-patch
** If you've modified code from CVS
(in the wmbiff/wmbiff directory)
[ optionally 'make distcheck' ]
cvs update -d
[ resolve any conflicts ]
cvs diff -u | less [ make sure the differences are roughly correct ]
mv wmbiff wmbiff-changed
[ now checkout a new copy of wmbiff ]
diff --unified --recursive --new-file --exclude CVS wmbiff wmbiff-changed > my-patch
** Sending the patch
Submit my-patch as an attachment to mail sent to
wmbiff-devel. Don't forget to subscribe to the mailing list
so that we can discuss your patch. This is roughly the same
procedure you'll use to submit patches to any code, although
others may not have the 'make indent' step.
* This FAQ is wrong.
Send mail to email@example.com.
;;; Local Variables: ***
;;; mode: outline ***
;;; End: ***