Ethereal-dev: Re: [Ethereal-dev] capture.c: seperate the mix of GTK and GUI independant things
Guy Harris wrote:
On Nov 13, 2003, at 9:16 AM, Ulf Lamping wrote:
The stuff in the file "capture.c" is currently a mix of the "capturing
engine" and the GTK things involved with it.
Currently capture.c consists of three "main topics":
-generic capturing things (wiretap, pcap, ...)
-capture info GTK dialog (the one displayed when the capture is in
progress)
-GTK specifics (some of the pipe handling, ...)
IMHO it would be nice to seperate the generic capturing things (leave
it in the "capture.c" file) and put the GTK specific things into the
gtk dir.
Note that, currently, if you're not doing an "Update list of packets in
real time" capture, the capture loop also has to do GUI stuff, so
Ethereal can see packets and respond to user input in the same loop. As
such, the capture loop would, at least in part, be GTK+-specific,
although it might be possible to have the main capture loop call a
routine in the GTK+-specific code.
Hmmm, this GUI update is simply done by:
while (gtk_events_pending()) gtk_main_iteration();
in some places in the file, but this could be easily wrapped into a
function. But there are other places more complicated, like the pipe
sync things for the "Update list..." feature, when receiving data from
that pipe.
If the Ethereal main loop worked by adding the file descriptor for the
pcap_t on UNIX, or the handle for it on Windows, to the list of objects
the GTK+ main loop should select on, that could perhaps be cleaned up
somewhat, although that wouldn't work on
1) older versions of WinPcap (there's a problem where
"pcap_getevent()" was returning bogus information on NT - "NT" including
NT 5.x);
2) FreeBSD 4.5, I think (a workaround for a problem with BPF and
"select()" won't, I think, work on 4.5).
Another possibility would be to run the low-level capturing in a
subprocess all the time, and have the UI code just select from a pipe
from the subprocess, although I'm not certain you can do that on Windows
OT (95, 98, Me).
Well, these things are somewhat complicate in this file, I know. I
simply wanted to seperate the dialog stuff from the capture.c file as a
first step. Let's do things step by step, as I think this stuff wasn't
build in a day, and so we don't have to get a completely clean solution
overnight. I don't want to solve all problems of the world in one night ;-)
My idea was to start working on the things which are really odd and
could be solved more easily. Then go on to the more complicated ones,
like the things you describe.
My experience on getting problems solved in a matter that everyone is
pleased, is solving it step by step and asking other people (devels and
users) if this was a step in the right direction.
"I have a dream" myself: It would be very nice to see simultaneously
what's going on (on the network), for every network card (not only one),
and display a short info, even if we are currently not doing a capture.
This would be really nice to have, but I want to have a somewhat clean
base to start new features, and I think this is best achieved by doing
changes in a smooth fashion.
Regards, ULFL
P.S. If my changes are seemed to be spreaded all over the source tree in
a wildly manner, that's simply because I've prepared changes for the
last weeks, and now I'm committing them step by step.
I don't think, that the changes I've done are really finished. I will
continue working on them, when my own source tree is somewhat in better
sync with the CVS tree.
