[Tickets #6921] Change Search UI screen to search by KB instead of bytes

bugs at horde.org bugs at horde.org
Fri Jun 13 18:46:17 UTC 2008


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6921
-----------------------------------------------------------------------
  Ticket             | 6921
  Created By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Change Search UI screen to search by KB instead of bytes
  Queue              | IMP
  Version            | HEAD
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Horde Developers, Michael Slusarz, Jan Schneider
-----------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2008-06-13 14:46) wrote:

A better idea would be to add a dropdown list MB, KB, Byte and the
value in the field would automatically multipled by the selected
setting - this way you are not limiting yourself to a specific range
if you search by byte count internally already

Agreed - changing this to search for KB (or MB) will break all current
virtual folders unless some kind of in-place updating of preference
data is done.

Why? All you have to do is to calculate to bytes before storing it in
the virtual folder preference, and the opposite when reading it.

How do you tell whether the the previous search was in bytes, KB, or
MB? (I would not agree on any change that would simply make KB the
default - I think bytes makes more sense as a default than KB).
Scenario:

1. User searches for something in KB.
2. Search returns no result.
3. When search is reloaded, his search will be displayed in bytes, not KB.

Although not incorrect behavior, it probably isn't the expected
behavior.  Additionally, the textified representations of the search
will be incorrect also.  Thus the need to alter the stored virtual
folder value in someway to indicate the search type.

I think it's safe to assume that the user entered the lowest number
possible with the units available. Thus we can calculate back from the
bytes to largest unit possible without loss. We do something similar
in Kronolith when calculating alarms (saved in minutes) to hours and
days.

E.g. the user enter 2 KB, we save 2048. When displaying the value
again, we see that we can divide by 1024 without loss. If he entered
2000 bytes instead, we would display 2000 bytes.





More information about the bugs mailing list