251204 - Folder/message size could be expressed in max. 3 digits to save space

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[:aceman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla 1.7

I am talking about the size of folders as displayed in the left folder pane of
the 3-pane mail window. The size is rendered in KB, MB etc, according to the
value. I guess if 1024KB is reached, the string changes to 1MB. Therefore
4-digit numbers are shown only for values in the range 1000-1024. That is a very
small part of the whole interval of 1-1024. But I have to enlarge the column to
take 4 digit values to be universal for all cases. If we reduce the possible
range to 1-999 we could shrink the column and save this space for more useful
data (e.g. the folder name).

The same algorithm should then be applied to the sizes of messages in the top
message pane.

If under current conditions it is not possible to render 1000KB as 1MB, then bug
251202 could help.

Reproducible: Always
Steps to Reproduce:

Comment 1

[:aceman]

Attachment: Patch that does this.

This patch also fixes bug 251202.

Comment 2

[David :Bienvenu]

Comment on attachment 159483 [details] [diff] [review]
Patch that does this.

I like the idea. But, are we currently using the floating point library in the
base code? If not, could this bloat the code?
Or does it just convert to a float w/o linking in the whole fp library?

Comment 3

[:aceman]

Attachment: Patch avoiding float.

I don't know. But here is a safe version.

Comment 4

[:aceman]

Could somebody look at it?

Comment 5

[:aceman]

Mscott probably doesn't like it.

Comment 6

[Scott MacGregor]

Comment on attachment 159591 [details] [diff] [review]
Patch avoiding float.

I like this suggestion.

Comment 7

[Scott MacGregor]

I'll check this in if it gets approved

Comment 8

[Scott MacGregor]

thanks for the patch

Comment 9

[[e-mail]]

Comment on attachment 159591 [details] [diff] [review]
Patch avoiding float.

>+    #define DIVISIONWITHCEIL(num, div) (num/div+((num%div>0)?1:0))
Do you not like spaces? ;-)
Seeing as div is only going to be 1024 and you're also assuming num is positive
you could just write ((num + 1023) >> 10).
Anyway, my real point is that we went to great lengths to ensure that the IMAP
search by size code actually returned results that displayed the size being
searched for. Local searches already did this too, and both searches will now
be incorrect...

Comment 10

[[e-mail]]

Attachment: Make search match display (as per comment)

Comment 11

[[e-mail]]

Comment on attachment 186789 [details] [diff] [review]
Make search match display (as per comment)

Sorry, I misread the bug. Please ignore me ;-)

Comment 12

[:aceman]

I know nothing about IMAP search, but you could have a point. If the user enters
1023KB the found messages may have the size displayed as 1MB. But I would accept
that as long as the message really has the needed size in the background. But,
who will actually search for 1023KB? Nobody will see such string since now, so
will probably not search for it.

Anyway, thats for accepting this, guys! Two notes:
1. I hope it goes in the suite too, as that is what I use (and it was a patch
against 1.8a3).
2. If any new bugs caused by this are filled, you can assign them to me.

Comment 13

[David :Bienvenu]

Comment on attachment 159483 [details] [diff] [review]
Patch that does this.

clearing obsolete request

Comment 14

[:aceman]

Great! Verified with seamonkey 1.0.