Community
Participate
Working Groups
Show attachment size column on attachment table from bug editor.
We don't get the attachment size in the xml although there may be a way to query for this information since it IS available in the HTLM. Either way, RepositoryAttachment should have this facility and should be exposed in the editor so that other connectors can display this info if available.
Rob: also consider making the corresponding enhancement request to Bugzilla.
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=366059
FYI, I have a patch almost done. I hope to submit soon.
Great to hear Willian. Thanks for letting us know you are working on this.
Created attachment 88208 [details] Patch
Created attachment 88209 [details] mylyn/context/zip
This patch adds an size attribute to repository attachment, and implements the attribute capturing for bugzilla. The attachment table in task editor includes a new "size" column. For bugzilla < 3.0 and connectors that don't supply that attribute, an "-" is shown. Unfortunatelly, I couldn't find a way to determine if an connector have this capability, so you may end up with an bogus "Size" column filled with "-" for some cases. The formatting is done according to the magnitude of the size value, so instead of "123456789 bytes", you read "123,46 MB". The rouding is done for 2 decimal places. There are tests for the formatting cases, and I did manual tests in landfill.bugzilla.org for 2.22 and 3.0 bugzilla instances.
Great patch! +1 for merging
Awesome Willian! Patch applied, ip log updated.
Fixed.
I just noticed that we're using "kB" instead of "KB", and the latter is the common capitalization. Could we change this? Also, there appear to be some string matches for ".. kB" which would be good to avoid.
Rob changed the original patch from KB to kB. But according to wikipedia either is valid.
Rob? Windows uses KB and afaik it is more standard given that it parallels the metric system abbreviation, so unless there's a reason to go with "kB" could we make the change?
I suggested this change due to the mismatch of the sizes displayed in the Bugzilla web UI. The Bugzilla web UI assumes that 1 KB = 1024 bytes whereas the task editor attachment table assumes that 1 kB = 1000 bytes. I am okay with changing it to KB but then the unit conversion should be changed as well.
I decided to use 1 KB == 1000 bytes because it is easier to convert and round. But I agree that the right approach would be to use 1024 instead of 1000 as the unit conversion, and it is what I learned in school, but thanks to HD manufacturers and their marketing department, some people tend to use 1000 bytes = 1 KB. There is a nearly unknown standard that, for clarity, encourages the use of another family of units, and says 1024 bytes should be called 1 KiB (kibibyte). See a more complete explanation on this blog post: http://www.codinghorror.com/blog/archives/000950.html And the wikipedia entry: http://en.wikipedia.org/wiki/Kilobyte This is not largely used, but I know at least 1 app, NetMeter, which I use here, that uses KiB to denote 1024 and KB to 1000. So I changing the grouping to multiple of 1024 bytes, I think we should also change the units to KiB, MiB, GiB, to eliminate ambiguity.
I didn't realize that this question was so interesting and had never heard of KiB's. When there is no clear answer, my instinct is to go with something that will meet most user's expectation but that's still accurate. So I think that we should go with the same thing as the OS does. For most Eclipse users is it's Windows, which in the file dialogs reports units in KB = 1024. Willian: you OK with this?
OK, no problem.
If we want to go ahead with this change it should be done soon so it can go into the 2.3 release.
Created attachment 90444 [details] Complementary patch Patch for using 1024-based units and KB instead of kB. There is a minor issue with this approach I simply don't know how to resolve, which is for values near 1 MB, 1 GB, which when rounded to 2 decimal places are formatted to incorrect magnitude. I.e. 1048576 bytes is formatted to "1.00 MB" (exactly), but 1048575 bytes is formatted to "1024.00 KB" due to rounding up.
Created attachment 90445 [details] mylyn/context/zip
Patch applied and IP log updated. Thanks Willian! It's good to have this in time for the release so we don't confuse users by displaying different sizes later on. We could change the implementation so that anything >= 1000 bytes shows up in KB, i.e. 1023 bytes would show up as 0.99 KB. I think the current implementation is consistent with the Bugzilla web interface so I'm okay with keeping it the way it is now. Do you know what Bugzilla displays for attachments that are 1048575 bytes in size?
(In reply to comment #22) > Do you know what Bugzilla displays for attachments that are > 1048575 bytes in size? I have no idea what algorithm bugzilla uses for formatting.
Just tried it on mylyn.eclipse.org and got this error when I tried to upload a file that was 1048575 bytes in size: The file you are trying to attach is 1024 kilobytes (KB) in size. Non-patch attachments cannot be more than 1000 KB
Steffen, is this a bugzilla test installation? AFAIK, there is a configuration in bugzilla to limit the size of attachments accepted, which by default is low.
Yes, it's the repository on mylyn.eclipse.org. I should have added that the size in the error message seems to be consistent with your comment #20, so it's all good :).
