On Sun, Jul 06, 2003 at 03:13:03PM -0400, Nathan Jennings wrote:
> Guy Harris wrote:
> > On Wed, Jul 02, 2003 at 09:47:41PM -0400, Nathan Jennings wrote:
> >>Yeah, I thought about that too... the OS may provide a description. But,
> >>like you mentioned, sometimes you may have two or more of the same
> >>type/brand of NIC and that's not helpful.
> >
> >
> > Yes, that's the point - if the user has supplied their own name for an
> > interface, it probably has all the information they need, and the
> > OS-supplied description won't be useful, so there's not much use I can
> > see for supplying both of them, so I think just showing one name, and
> > having that name default to the OS-supplied name if present, and letting
> > the user replace that name, would be the right thing to do.
>
>
> Yeah, OK. I think this would be a nice feature too. How much complexity
> do you think this would introduce given the number of OSes Ethereal runs
> on? Wouldn't the code to pull the descriptions be different for each OS?
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.
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.
> 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.
> Given that we have six interfaces on one of our
> machines, I can see where in some installations the capture dialog (GUI)
> might become too cluttered.
The capture dialog, in the sense of the dialog that pops up when you
select Capture > Start, isn't affected by your patch or by my suggested
change to that patch.
The capture *preferences* dialog is affected, but that's not used on
every capture.
