Jeff Morriss wrote:
>Guy Harris wrote:
>> Jeff Morriss wrote:
>>
>>> What about renaming the current field "frame.time_delta_displayed" and
>>> name the new one "frame.time_delta"? That changes the current field
but
>>> it sounds a whole lot more intuitive to me.
>>
>> Or "delta_displayed" and "delta_captured", which means that any
>> "frame.time_delta" filter would fail rather than filtering something
>> different from what it did before the change.
>
>Or, as per my comment in bug 491 (which I've just now recalled):
>
>> Another might be to prohibit filtering on this field altogether since
it's,
>> well, kinda illogical.
>
>I know now (though I didn't know then) that it is possible to make
>fields not filterable (by making the filter field an empty string) so
>what about:
>
>- add a new field (with filter "frame.time_delta") which is the time
>delta to the previous frame in the file
>- keep the display of the time since the previous displayed packet, but
>make the field is not filterable
>
>?
>
>Normally I'd see the use in not changing semantics for a field, but I
>don't think the current semantics make any sense at all so I can't
>imagine it is being used [therefor it's OK to change it].
It makes no sense in a display filter, but it is useful in a colour filter
or in Edit > Find Packet > By Display filter.
I often use a colour filter to highlight frames with frame.time_delta>x,
where x is something small. Of course it's only meaningful if the
displayed frames are all related in some logical way, but that often
applies because I've used capture or display filters to get such a
display.
I don't mind a name change, but don't want to lose the present
functionality.
Julian.