Looking for mailwatch app

Grant Edwards grante at visi.com
Sat Aug 30 02:22:02 CEST 2008


On 2008-08-29, Brian J. Tarricone <bjt23 at cornell.edu> wrote:

>>  1) I can't tell which icon is for which mailbox.  I guess I
>>     could create a set of my own mail icons that include the
>>     mailbox names.
>
> Yep, that's what you'll want to do.

I've almost got a shell script working that will automate the
process: it scans through all of the "mailwatch*.rc" files and
creates mail/nomail icons annotead with the mailbox names.
Next I need to add a sed command to put the new icon-names
back into the .rc files.

>>  2) I keep my panels hidden, which means I can't see the
>>     mailwatch icons.  Maybe I can create a separate panel just
>>     for the mailwatch plugins and leave that one showing.
>
> Sure, that would work, but would waste screen space.  J-F's idea to use 
> notify-send is a good one.

How does notify-send work without using any screen space?

> Maybe I could add some placeholders so you could do something
> like "notify-send Mailwatch 'You have %n new messages in
> mailbox %m'".  Someone should file a feature request ^_^.

I'm going to get it going the way it is first. :)

>>  3) In gkrellm, the indicators include the number of new mails.
>>     I think I'm going to miss that feature (but I can live
>>     without it).
>
> Well, it's shown in the tooltip, at least.
>
>> I'm going to continue playing with the xfce4 mailwatch plugin,
>> but was wondering if there was another GTK or XFCE app that
>> people suggest for watching mailboxes (it needs to support IMAP
>> w/SSL, Maildir, and mbox formats).
>
> Not that I know of.  Pasi and I wrote Mailwatch because we
> couldn't find another app that met those exact requirements.
> If you use claws-mail, I believe there's a systray
> notification plugin, but of course that only works if you use
> claws-mail, and keep it running all the time.  There might be
> something similar for Thunderbird, but I don't know.  Other 
> MUAs might have similar features.

I use mutt, and it doesn't really do any GUI/panel/plugin sort
of stuff.

> That's fixed in SVN.  I should be doing a new release Real Soon Now 
> (it's been over 2 years since the last release, I think).

Yea, it looks like the stable gentoo ebuild is a bit old.

> I was furiously hacking on Mailwatch a few weeks ago, and it's
> feeling pretty stable for me now.
>
>>  * I still can't figure out how to tell mailwatch that "INBOX"
>>    isn't the name of my inbox.  The checkbox next to INBOX is
>>    stuck in the "checked" state.
>
> That's apparently a naive assumption on my part.  Please file
> a bug on bugzilla.xfce.org.

I'd guess it's valid 99% of the time.  I think the IMAP RFC
guarantees there's a mailbox named INBOX (which in this case
there is).  It just doesn't guarantee that's where incoming
mail ends up. :)

Some people run filtering programs that suck mail out of INBOX
and sort it into other folders, so they might not want a
mailwatcher monitoring INBOX.  The way I handle my mail is
probably a bit weird. In my case, I bypass INBOX altogether and
use procmail to sort incoming mail into various folders
underneath a directory named Mail.

>>  * I was unable to configure one of my inboxes (named
>>    "Mail/inbox") on one server.  The little box next to it was
>>    checked by default, but when I traced the IMAP connection,
>>    Mail/inbox wasn't being queried.  I finally resorted to
>>    editing the mailwatch*.rc file by hand to add Mail/inbox.
>>    Now it's checking Mail/inbox -- it's still also checking
>>    INBOX (which isn't an inbox), but that's harmless.
>
> I imagine that's related to the above...

I would guess so.

> I'd be perfectly happy just editing the .rc files, but I can't
> figure out how to get the applet to re-read them without
> shutting down xfce and restarting it.
>
> $ xfce4-panel -x
> $ vim /path/to/rcfile
> $ (cd ~ && xfce4-panel & disown)

Brilliant!  

Thanks.

> (But yeah, you shouldn't need to do this... any instance in
> which you do is a bug.)

Even if I didn't need to, I probably still will (now that I
know how).  When I change gkrell config stuff, I usually just
edit the file instead of using the GUI dialogs.  It tends to be
faster and less error prone -- especially for operations like
adding a new mailbox where all you want to do is copy an
existing one and change one value.  It also lets me make sure I
typed the password correctly. :)

>> Has anybody considered just keeping the IMAP connection up
>> instead shutting down and starting up a connection for each
>> poll? Holding an IMAP connection open uses a _lot_ less
>> resources (on both ends) than does constantly re-doing SSL
>> handshaking and SSL and IMAP authentication protocols.
>
> No, I haven't considered it.  I imagine, though, that this
> isn't true for unencrypted SSL connections (yeah, I figure
> there are more people using those than I'd like).

Probably true.  It depends on how much of a hit the server
takes to authenticate a user at the application level.

> The architecture (in the current released version) is sorta
> vaguely suited to keeping the connection open, though not with
> some annoying changes.  The architecture in SVN now would 
> require major changes to keep a connection open, as now not
> even the checker thread is kept alive in between mail checks.
> I'm not convinced this is worth the time and effort to change.
>
> Though I think your concern is partly an artifact of your
> rather short interval.  A 10-minute interval without
> maintaining the connection is proably less work than
> maintaining a connection with a 10-minute interval.  The same
> may not be true for a 1-minute interval.

Even at one minute, it's probably not a big deal.

The other reason I'd do it is so that I can turn up the logging
level in my IMAP servers so that they log all login/logout
events.  With mailwatchers on 3-4 machines logging in/out of
the server every minute (or even every 10 minutes), that
creates quite a bit of noise in the server log.  If the
mailwatchers kept connections up, then I could have more
detailed IMAP logs.

-- 
Grant





More information about the Xfce mailing list