[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: system tray notification patches updated for 3.1
From:       Ryan Breen <ryan () porivo ! com>
Date:       2002-06-16 22:31:59
[Download RAW message or body]


I gave it some more thought this week, and IMHO, it makes more sense to revert 
to connecting to KMFolder numUnreadMsgsChanged signals.  

AFAICT, connecting to delayedUpdate on KMFolderTree has more performance 
overhead since there is no guarantee that there are new messages when we 
receive that signal (leading to needless execution of the systray code).  
Also, delayedUpdate is not folder specific, so we are forced to walk every 
folder to determine unread status.  By connecting to the numUnreadMsgsChanged 
from each folder, we know exactly which folder has been modified, reducing 
execution of the systray code to the necessary minimum.  See, I have been 
paying attention to your sig, Aaron ;-)

The only extra overhead is the task of keeping the folder connections up to 
date.  I connect to the foldersChanged signal from kernel->folderMgr and 
kernel->imapFolderMgr and, when a folder is added or deleted, refresh the 
connections.  However, folder adds and deletes are relatively infrequent (at 
least an order of magnitude more rare than delayedUpdate messages, I would 
guess), so this overhead is negligible.

The new kmsystemtray.cpp is over 100 lines shorter than previous incarnations 
(~150 lines with comments), and the class is only based on singleton objects 
(no dependencies on KMMainWin or KMFolderTree).  I've played around with it a 
good bit -- opening new mail clients, deleting folders that have unread 
messages, etc -- and it looks solid so far.

The patch can be found at http://www.ryanbreen.com/kmail/basic

Ryan

On Sunday 09 June 2002 07:06 am, Aaron J. Seigo wrote:
> On June 9, 2002 05:42 pm, Ryan Breen wrote:
> > As for the 'friend' association, KMSystemTray is a friend of
> > KMFolderTree, not KMMainWin.  I needed this mod to connect to the
> > mUpdateTimer for receiving delayedUpdate signals.  If there is a less
> > obtrusive way of doing this, please let me know.
>
> perhaps KMFolderTree could emit a signal of its own when the timer times
> out by connecting the timeout() signal of the timer to this new
> KMFolderTree signal ...
>
> > I switched to basing system tray notification off of
> > KMFolderTree::delayedUpdate in response to a suggestion by Michael Häckel
> > last November (http://lists.kde.org/?l=kmail&m=100506753530462&w=2).  The
> > very earliest versions used KMFolderManager, but the suggestion was to
> > use delayedUpdate to avoid additional folder traversal overhead.
>
> ah..

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]