Guy Harris wrote:
Yes, but that difference would be buried inside libpcap. Libpcap 0.7.1
already introduced an API that lets it supply descriptions if the OS can
supply them.
Currently, we don't even *try* to get descriptions except from Windows,
and I am not proposing that we try to get them ourselves on non-Windows
OSes. What I'm proposing for your patch is simply that, on those OSes
where the OS does supply a description and we get that description -
meaning just Windows, right now - we don't put *two* descriptions into
the strings in the combo box, we put only one description in there,
which is:
the user-supplied description, if they supplied one;
the OS-supplied description, if the user didn't supply one and
the OS did;
nothing, otherwise.
Oh OK, I see now. pcap can help us here. Thanks for spelling it out...
We should also change Ethereal so that *if* "pcap_findalldevs()" is
available, it uses that rather than getting the information itself.
That's fairly straightforward on UNIX, where we determine what's
available at compile time. It's trickier on Windows, because we have to
check both whether
1) it's available at compile time, so "pcap_if_t" is defined
and
2) it's available at run time.
That would mean that, in order to build a version of Ethereal that could
use "pcap_findalldevs()" on Windows, it would have to be built on a
system with WinPcap 3.0 or later; a version built with WinPcap 2.x
wouldn't be able to use "pcap_findalldevs()" even if it's present on the
machine on which you run it, unless we define it ourselves *and* get a
version that matches what libpcap uses.
Hmmm... sorry I can't help here. I'll have to bow to one of the
pcap/Ethereal gurus. ;o)
I like this, however... how would GTK handle the text entry fields if
there were too many interfaces on the machine to fit in the dialog? Is
the dialog size dynamic?
Yes, but it might not fit on the screen. Another alternative might be
to make a scrolling list of interfaces, which would handle that problem.
I suppose I err'd on the side of simplicity when I worked on this. I
thought a description string was simple but still effective and
ultimately very usable.
There's more than one form of "simplicity". Having to type in a string
with a particular syntax doesn't seem as simple to the end-user as
typing in text strings, with no particular syntax, for each of the
interfaces. I'd vote for end-user simplicity in this case.
Yes, indeed. :o) Thanks for all of the input. Unless I hear
differently, I'll edit my changes so:
1) If there's an OS description, it'll be removed if there's a
user-supplied description... like you outlined above.
2) Edit the capture *preferences* dialog so it looks like:
Inteface: [fxp0 ][v]
Interface descriptions: Edit...
Capture packets in promiscuous mode: []
Update list of packets in real time: []
Automatic scrolling in live capture: []
3) The "Interface descriptions:" "Edit..." button opens another dialog
with a scrolled list of interfaces and a text entry for a description
string for the highlighted interface name:
Interface list:
<scrollable list box with interface names here>
Interface description: [ ]
OK Cancel
-Nathan