Bug 42174 - folder list does not redraw correctly
Summary: folder list does not redraw correctly
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: folder list (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR minor
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 47205 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-05 05:33 UTC by artemista
Modified: 2008-01-07 05:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description artemista 2002-05-05 05:27:14 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kmail
Version:           KDE 3.0.0 
Severity:          normal
Installed from:    RedHat RPMs
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: Not Specified

When using an icon set where the folder icon is not as tall as the default folder icon (ie the Crystal Icons from Connectiva) the folder list does not redraw correctly when the last unread message in a folder is marked as read. While there is an unread message in the folder the parentheses that contain the number of unread messages are the tallest things in that line of the folder list - not the icon. When the last message is marked is read the height of the line seems to become shorter but the folders below it in the list do not redraw in their new position. In minor cases this results in little bits of the highlighted folder name being left behind when you move to a new folder above the one with the now-read messages. In more extreme examples like when several folders are emptied of unread messages without forcing the screen to redraw by switching to another program this results in the last folder(s) in the list being displayed in the completely wrong place so that clicking on one folder name actually brings you into a different folder.

(Submitted via bugs.kde.org)
Comment 1 Ingo Kl 2002-05-05 11:02:41 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 05 May 2002 08:25 Zack Rusin wrote:
> On Sunday 05 May 2002 01:27 artemista@artemista.com wrote:
> > When using an icon set where the folder icon is not as tall as the
> > default folder icon (ie the Crystal Icons from Connectiva) the
> > folder list does not redraw correctly when the last unread message
> > in a folder is marked as read. While there is an unread message in
> > the folder the parentheses that contain the number of unread
> > messages are the tallest things in that line of the folder list -
> > not the icon. When the last message is marked is read the height
> > of the line seems to become shorter but the folders below it in
> > the list do not redraw in their new position. In minor cases this
> > results in little bits of the highlighted folder name being left
> > behind when you move to a new folder above the one with the
> > now-read messages. In more extreme examples like when several
> > folders are emptied of unread messages without forcing the screen
> > to redraw by switching to another program this results in the last
> > folder(s) in the list being displayed in the completely wrong place
> > so that clicking on one folder name actually brings you into a
> > different folder.
>
> Thanks for your bug report.
> Guys I can fix it in one of the two ways: adding a repaint call
> after the unread count would go to zero or just scale the pixmaps
> up. The first way would involve a little more code the second way
> would produce butt ugly pixmaps. Anyone feeling strongly one way or
> the other?

This is the same as bug#41585.

I guess this bug is caused by the fact that the two icons for open=20
folder (shown if folder contains unread message) and closed folder=20
(shown otherwise) have different height. As the folder icons are now=20
configurable we can't make sure that the unread icon is always as high=20
as the read icon. Therefore forcing a repaint is the best workaround=20
for this.

But isn't this a Qt bug? Shouldn't a QListView automatically be=20
repainted if necessary? Or was this broken in KListView?

Nevertheless the crystal icon set must also be fixed so that all icons=20
of the same size (16x16 is used for the folder list) really have the=20
same height (and the same width of course).

Regards
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE81RFRGnR+RTDgudgRAkyRAKC0E7leAkq7FwlSwl7dKna9Ie1QVACgvl6z
nmBZ9bWX+qghMLPuNuVisLQ=3D
=3DRJrj
-----END PGP SIGNATURE-----
Comment 2 Zack Rusin 2002-05-05 15:46:25 UTC
On Sunday 05 May 2002 07:02 Ingo Kl=F6cker wrote:
> This is the same as bug#41585.
>
> I guess this bug is caused by the fact that the two icons for open
> folder (shown if folder contains unread message) and closed folder
> (shown otherwise) have different height. As the folder icons are now
> configurable we can't make sure that the unread icon is always as
> high as the read icon. Therefore forcing a repaint is the best
> workaround for this.

I agree I like Karl-Heinz proposition to repaint only if neccessary=20
I'll most propably add a flag to folders which have pixmaps smaller=20
than a certain size. I have to check how small is "small enough".=20

> But isn't this a Qt bug? Shouldn't a QListView automatically be
> repainted if necessary? Or was this broken in KListView?

Most probably but it's optimized and repainting does happen but only=20
of a single item this leaves all others broken.

> Nevertheless the crystal icon set must also be fixed so that all
> icons of the same size (16x16 is used for the folder list) really
> have the same height (and the same width of course).

ACK.

Zack


--=20
Blondes? Brunettes? Linux? The world is full of tough choices.
Comment 3 Michael H 2002-09-29 11:50:19 UTC
*** Bug 47205 has been marked as a duplicate of this bug. ***
Comment 4 Rich Birch 2005-04-15 02:11:47 UTC
Has anyone experienced this lately? I can't reproduce, maybe because parentheses aren't used anymore?
Comment 5 Rich Birch 2005-04-18 01:15:09 UTC
Scrap my last comment. I just accidentally found out that parentheses
are indeed still used if the Unread column is disabled.
Comment 6 George Goldberg 2007-10-30 05:12:52 UTC
Is this bug still present in a recent KDE version, such as 3.5.8?
Comment 7 George Goldberg 2008-01-07 05:10:02 UTC
Closing this bug due to no response. Please reopen if this bug is still present in a recent version of KDE, such as 3.5.8