https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5158
--- Comment #2 from Chris Maynard <christopher.maynard@xxxxxxxxx> 2010-08-30 18:16:24 PDT ---
So would that likely mean:
1) we'd be limited to the lowest common denominator, presumably 16 colors?
2) those that support 256 colors would use 256 colors and
a) the others would only use 16 colors?
b) the others would not have any color support?
c) we would require other shells that support 256 colors for the others,
assuming there are others? (Does powershell 2.0, e.g., support 256?)
3) something else?
And if 16 colors is the best we could do for certain platforms, would that be
good enough?
>From my own experience, I can say that having even a few colors really helps.
I've written my own libpcap-based command-line capture tool for decoding some
proprietary protocols and I've added color support to it. I and those who use
it find the colorization very helpful to more easily pick out traffic of
interest as it scrolls by. The tool I wrote runs on Linux but I only used the
basic colors. Still, it does the job quite well, at least for our purposes.
Admittedly, the number of protocols the tool colorizes is very small since
we're primarily only interested in a small number of core protocols, but even
though tshark obviously supports a huge number of protocols, the basic set of
Wireshark color rules is really not that big at all, so I don't think a 16
color limitation would necessarily be too bad if that's all we could get.
That said, I don't know what it would really take to integrate color support
into tshark, so I'm not sure the level of effort this entails, and I can
foresee extra problems/headaches with having to support different color modes
for different platforms. Anyway, I hope any 16 color limitation doesn't
prevent colorization entirely, but I would understand if it did. Thanks.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.