Summary: | folder list does not redraw correctly | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | artemista |
Component: | folder list | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | gassauer, grundleborg |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | RedHat Enterprise Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
artemista
2002-05-05 05:27:14 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----- 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. *** Bug 47205 has been marked as a duplicate of this bug. *** Has anyone experienced this lately? I can't reproduce, maybe because parentheses aren't used anymore? Scrap my last comment. I just accidentally found out that parentheses are indeed still used if the Unread column is disabled. Is this bug still present in a recent KDE version, such as 3.5.8? 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 |