Wireshark · Ethereal-dev: Re: [ethereal-dev] Possible crash problem in file.c

[Guy Harris <gharris@xxxxxxxxxxxx>]

On Tue, Jun 27, 2000 at 11:03:54AM -0500, Gilbert Ramirez wrote:
> Removing the progress bar from the main window would give us a little
> more real-estate for a display filter. I tend to write long display
> filters.

Done.

The status line still has the status item, so you don't get *all* of it
(other than the "Filter:" and "Reset" buttons) for the filter.

While Ethereal is:

	reading a capture file;

	filtering a capture file (which includes "Follow TCP Stream");

	searching within a capture file for the next packet that matches
	a particular filter expression;

there's a modal dialog box popped up with:

	an indication (in the titlebar, if your window system has
	titlebars, and in the window itself) of what's being done;

	a progress bar;

	a Cancel button.

Clicking the cancel button cancels the operation:

	For reading, it closes the capture file (as if you'd done
	"File->Close", i.e. no packets are displayed).

	For filtering, it just stops (which means you see those packets
	that match the filter *and* that were looked at before you
	clicked "Cancel" - reverting to the previous filter, or even
	turning off the filter, would take at least as long to finish as
	would finishing the filtering operation, and you presumably
	clicked "Cancel" because you didn't want to wait for the
	filtering operation to finish; I think that if, as, and when I
	get around to creating a "virtual" CList widget and making
	Ethereal use it, it may be possible to make turning off the
	filter happen reasonably quickly - and if the previous
	matched/didn't match status was saved for each packet, it might
	also make reverting to the previous filter happen reasonably
	quickly).

	For searching, it cancels the search and leaves you at the
	packet you were on before the search was started.

The dialog box is modal, which means that you can't do arbitrary things
in the UI while the operation is in progress; this should close a bug
Ben Fowler found wherein doing "File->Quit" in the middle of "Follow
TCP Stream" caused a crash (the same would probably happen if you did
that whilst filtering), as you *can't* do "File->Quit" in the middle of
that - you have to cancel the operation and *then* close the file. 
(Canceling the operation may often be what you really wanted to do;
prior to my checkin, the only way to cancel long-running operations such
as that would have been to quit Ethereal or maybe to close the file),
and may also fix similar bugs that nobody'd found yet because they
hadn't tried all possible UI operations allowed whilst long-running
operations such as that were in progress.

The change also moves some UI code out of "file.c" and into
"gtk/progress_dlg.c", which is a step towards the goal of moving *all*
code that knows about GTK+ into the "gtk" subdirectory; this might allow
non-GTK+ UIs (the curses UI Gilbert's talked about, a KDE UI, a GNOME
UI, a native Windows UI, etc.) to be implemented.  (Ethereal would
require GLib in all those cases - but I don't know of any reason why it
would in principle be impossible to use GLib inside a KDE or native
Windows application; GLib is separate from GTK+, GTK+ just happens to
use it for many things.)

Unfortunately, like all our other dialog boxes, the progress dialog box
may pop up at a random location on the screen, rather than popping up
atop the main window.

I think there's a way to specify that the dialog box top-level window
"belongs" in some sense to the main window (I'd have to dig through a
fair bit of X documentation to remember what that involves, but I'm not
certain whether it involves making the window "transient for" the main
window or not - I think there's *some* mechanism used for things such as
pull-down menus, and that it might be the "transient for" mechanism and
that it might, in order to make it work properly in that case, have
semantics, e.g. "don't decorate this window", that would be
inappropriate for top-level windows, but I could be completely
misremembering here).

Unfortunately, I don't know whether any X window managers treat this as
a hint to position the window on top of the main window ("on top of" in
the X-and-Y-axis sense, not just in the Z-axis sense), so that wouldn't
necessarily help.

I seem to remember some discussion on one of the GTK+ lists implying
that you have to position the dialog box manually if you want that to
happen, which suggests that it doesn't help; I also seem to remember
trying to do the above trick a while ago, and finding that it didn't
make a bit of difference with KWM.

I don't know whether there's any reason why this, apparently, isn't done
by most window managers; at this point, it'll probably be a long time
before enough window managers do it to allow applications or toolkits to
rely on it.

It might be nice if toolkits that had the notion of pop-up dialogs
either always did this or could be asked to do this, so that
applications didn't have to; I would not be surprised to find that
making all the major X toolkits do it was easier than making all the
major X window managers do it.

For now, we'd probably have to do it ourselves; I might look into that
at some point (making it, ideally, Another Damn GTK+ Helper Routine to
get around stuff GTK+ doesn't *quite* make convenient enough, so that
it's relatively straightforward to make our pop-up dialogs do it).