Re: [Evolution] Feature request - live debug

[Patrick O'Callaghan <poc usb ve>]

On Fri, 2012-02-03 at 14:56 -0700, Zan Lynx wrote:
> On 2/3/2012 3:20 AM, Pete Biggs wrote:
> > On Fri, 2012-02-03 at 12:06 +0200, Mark Elkins wrote:
> > > On a slow internet connection line - watching my 'sending messages -
> > > 25%' - wondering whats going on... 
> > >
> > > It would be handy to view the live, raw interaction of what is going on
> > > at times, whether for downloading or sending - restricted to significant
> > > events (SSL validation, mail header exchange, data count every 10Kb -
> > > etc). 
> > >
> > > One might view this by mouse over the dynamic info bars at the bottom of
> > > the evolution screen? or is there a log file option I'm unaware of?
> >
> > Well there's always the debugging variables:
> >
> >   http://projects.gnome.org/evolution/bugs.shtml
>
> I agree that I'd really like to see what is going on, plus what has been
> happening in the background. This should be done without needing
> debugging variables because when I want to know why it is slow or
> unresponsive, I wasn't planning on that happening. And, often when that
> happens Evolution does not *want* to shut down. It can take literal
> *minutes* for Evolution to decide to quit when an IMAP connection has
> gone wonky.

Make that "an indeterminate number of hours". IIRC I once left it
waiting for a several days and it didn't time out.

> You can always force-kill it of course but I hate doing that. After all,
> if it was completely safe to force-close then why is Evolution waiting
> instead of quitting? Which would be the question that the interaction
> log would answer.

AFAIK it *is* always safe to force-shutdown. I've never lost a single
email in many years of recovering from hangs in multiple versions of
Evo. Which is why I can't understand why Evo can't just timeout a hung
connection after a minute or two and restart it. Mail systems are
designed very conservatively to be able to survive flaky connections. Of
course some hangs may be due to internal deadlocks, but poor network
connections simply should not cause this.

poc