Summary: | make new messages visible when selected and new messages fit in header view | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | Toni <toni.brkic> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | marrandy, r, samer.abdallah |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Toni
2002-10-17 18:01:54 UTC
*** Bug 52484 has been marked as a duplicate of this bug. *** *** Bug 70580 has been marked as a duplicate of this bug. *** *** Bug 74770 has been marked as a duplicate of this bug. *** This bug is really a showstopper for many of my clients when moving them from other mailclients to kmail. Since this behaviour is not present in any other mailclient it's hard for the users to get used to the kmail behaviour. This is especially true for people having alot of emails in the inbox, since it's almost impossible to see that the scrollbar has moved down one pixel or so. Since this wishlist bug have been reported a long time ago, is there any status if this will be implemented in the near future, i.e. make it possible for my clients to go truly kde. On Tuesday 10 February 2004 21:06, robert lindgren wrote: ... > ------- This bug is really a showstopper for many of my clients > when moving them from other mailclients to kmail. Since this > behaviour is not present in any other mailclient it's hard for the > users to get used to the kmail behaviour. This is especially true > for people having alot of emails in the inbox, since it's almost > impossible to see that the scrollbar has moved down one pixel or > so. > > Since this wishlist bug have been reported a long time ago, is > there any status if this will be implemented in the near future, > i.e. make it possible for my clients to go truly kde. Personally I don't have any plans to implement this in the near future. But I am in the process of creating a commercial service for implementing KMail improvements which are in high demand. If this improvement or any other is voted up (see http://kontact.org/votes.php ) near the top of the list I'll consider implementing it. Currently HTML editing is at the top of list and I'm contributing to help get that feature into cvs. Don. So what's the status of this bug, it just isn't going to be fixed? There are so many bug reports with this description it seems crazy not to fix it. The main point is that if you are scrolled all the way to one edge, it should remain scrolled to the edge when new messages arrive. It is kind of a special case which is unique only to email clients. If you are scrolled somewhere in the middle of your inbox, then no scrolling change should occur. I just don't see how the community in general would not agree that this is a user friendly way of doing things. It's not just a question of being "user friendly" or not -- the current behaviour is simply wrong -- it is precisely the opposite of what 99.9% of users want 99.9% of the time. Tell me, who gets new mail and does NOT want to see who it's from and what the subject is? I think we agree on this issue Samer. As much as I hate Outlook, I have to quote the way Outlook handles this just because it is an example of a client that works the "natural" way and it is available to me here at work. Below are the use cases: * If you are scrolled all the way to the edge with the newest message (whether it be the top or the bottom) and a new message comes in, the list scrolls back to the edge so that new messages come into view * If the scroll is offset by even a single line, new messages will not scroll into view, but will rather correct the alignment in the scrollbar only (you see no movement in the list) * If you are scrolled all the way to the edge and you are currently highlighting a message at the opposite edge, new messages will force the list to scroll and the highlighted message goes out of view. This happens like %0.00001 of the time and is an acceptable trade-off. I bet maybe one in 100 users would even notice the quirk, and that one person probably wouldn't care. I don't know how else to put it. If KMail worked this way, it would just be the expected behavior. What works, works, why try to philosophize so much? Agreed: this behavior should be a preference. please consider implementing this for our sanity ;) *Please* fix this annoying bug! This is all the more confusing, since you may get a "new mail message" and do not see the new mails without scrolling. Most people will keep the newest mail "active" and keep reading incoming messages during the day, so this appears to be an important feature. SVN commit 425948 by zander: When new emails are added to the current folder re-init the view to show any new email that would otherwise have appeared outside of the widget. BUG: 49292 M +31 -28 kmheaders.cpp M +1 -4 kmheaders.h M +0 -5 kmmainwidget.cpp --- trunk/KDE/kdepim/kmail/kmheaders.cpp #425947:425948 @@ -778,7 +778,7 @@ QValueList<int> curItems = selectedItems(); updateMessageList(); // do not change the selection // restore the old state - setTopItemByIndex( i ); + setTopItemByIndex( i, true); setCurrentMsg( cur ); setSelectedByIndex( curItems, true ); connect(this,SIGNAL(currentChanged(QListViewItem*)), @@ -2352,37 +2352,40 @@ //----------------------------------------------------------------------------- int KMHeaders::topItemIndex() { - HeaderItem *item = static_cast<HeaderItem*>(itemAt(QPoint(1,1))); - if (item) - return item->msgId(); - else - return -1; + int i=0; + HeaderItem *topItem = static_cast<HeaderItem*>(itemAt(QPoint(1,1))); + QListViewItem *item = firstChild(); + while(item && item != topItem) { + item = item->itemBelow(); + i++; + } + if(item) + return i; + return -1; } -// If sorting ascending by date/ooa then try to scroll list when new mail -// arrives to show it, but don't scroll current item out of view. -void KMHeaders::showNewMail() -{ - if (mSortCol != mPaintInfo.dateCol) - return; - for( int i = 0; i < (int)mItems.size(); ++i) - if (mFolder->getMsgBase(i)->isNew()) { - if (!mSortDescending) - setTopItemByIndex( currentItemIndex() ); - break; - } -} - //----------------------------------------------------------------------------- -void KMHeaders::setTopItemByIndex( int aMsgIdx) +void KMHeaders::setTopItemByIndex( int aMsgIdx, bool fuzzy) { - int msgIdx = aMsgIdx; - if (msgIdx < 0) - msgIdx = 0; - else if (msgIdx >= (int)mItems.size()) - msgIdx = mItems.size() - 1; - if ((msgIdx >= 0) && (msgIdx < (int)mItems.size())) - setContentsPos( 0, itemPos( mItems[msgIdx] )); + int y = 0; + QListViewItem *item = firstChild(); + while(item) { + if(aMsgIdx-- <= 0) + break; + y += item->totalHeight(); + item = item->itemBelow(); + } + if(fuzzy) { + item = item->itemAbove(); + while(item) { + int mesgId = static_cast<HeaderItem*>(item)->msgId(); + if( !mFolder->getMsgBase(mesgId)->isUnread() ) + break; + y -= item->totalHeight(); + item = item->itemAbove(); + } + } + setContentsPos( 0, y ); } //----------------------------------------------------------------------------- --- trunk/KDE/kdepim/kmail/kmheaders.h #425947:425948 @@ -125,9 +125,6 @@ /** Read color options and set palette. */ virtual void readColorConfig(void); - /** Scroll to show new mail */ - void showNewMail(); - /** Return the current message */ virtual KMMessage* currentMsg(); /** Return the current list view item */ @@ -142,7 +139,7 @@ virtual int topItemIndex(); /** Make the item corresponding to the message with the given id the top most visible item. */ - virtual void setTopItemByIndex( int aMsgIdx ); + virtual void setTopItemByIndex( int aMsgIdx, bool fuzzy=false); virtual void setNestedOverride( bool override ); virtual void setSubjectThreading( bool subjThreading ); /** Double force items to always be open */ --- trunk/KDE/kdepim/kmail/kmmainwidget.cpp #425947:425948 @@ -847,11 +847,6 @@ if (mBeepOnNew) { KNotifyClient::beep(); } - - // Todo: - // scroll mHeaders to show new items if current item would - // still be visible - // mHeaders->showNewMail(); } |