Comment # 5
on bug 5703
from Anders Broman
(In reply to comment #2)
> The issue is that "frame data" color_filter isn't populating on the "first
> pass", so the hf_ item representing the coloring rule name aren't being
> called.
>
> As a test, I forced values into the hf_ items for frame.coloring_rule.string
> and
> frame.coloring_rule.name and they showed up in the column data.
>
> So is this as simple as providing the color_filter data in the "frame data"
> on the first pass? I'm less concerned about a performance hit, but more the
> architectural ramifications. The packet dissection is independent of the
> "GUI" that cares about the coloring, but its the "GUI input" that is causing
> the generated fields on future passes over the packets.
>
> Would providing the color_filter data as part of basic dissection be part of
> the solution to bug 5158 (color coding in tshark)?
Hmm not doing coloring on the first pass may have been part of the packet list
optimization.
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.
