button"; "Stop" should be used for operations that can only be stopped
(meaning that what it's already done isn't undone), not cancelled
(meaning that whatever it's already done *is* undone), for which
"Cancel" is used.
Allow the merging process to be cancelled.
Clean up indentation.
Update some comments.
svn path=/trunk/; revision=16489
they have LF at the end of the line on UN*X and CR/LF on Windows;
hopefully this means that if a CR/LF version is checked in on Windows,
the CRs will be stripped so that they show up only when checked out on
Windows, not on UN*X.
svn path=/trunk/; revision=11400
changed window_xy (dialog) function calling in a lot of gtk files
cleanup of file selection code
cleanup in dlg_utils/file_dlg/ui_util
Please report any problems!!!
svn path=/trunk/; revision=11003
As this will always be a Cancel of a running operation, this parameter was removed.
This makes us also able to use a stock button for this.
svn path=/trunk/; revision=9774
pointer to const, to emphasize that it does *not* modify the time
pointed to by the argument.
Make the initial delay for delayed progress bars 1/10 second rather than
1/2 second, as a 1/2 second delay is noticeable, especially when loading
a file for the first time (as the main window looks a bit blank). Even
at 1/10 second you can still notice it, but it's not *as* noticeable.
svn path=/trunk/; revision=6118
information.
Fix the types of some variables (make the file position in
"read_cap_file()" a "long", as Wiretap supports "long" offsets, and make
processed-packet counts in packet-processing loops "int"s, as the total
packet count in a "capture_file" structure is an "int").
svn path=/trunk/; revision=6112
Ethereal sometimes creates a progress dialog bar and then, if
the processing is fast, quickly destroys it. The resulting
"flash" can be disconcerting. This set of patches ensures a
progress bar is either not created or is displayed for a minimum
time.
svn path=/trunk/; revision=5916
as, on a large capture, it could take a significant amount of time.
Let the user stop the computation and, if they do, don't pop up the
statistics dialog box.
Create a new header file declaring the routines to create, update, and
destroy progress dialog boxes; those routines' APIs don't depend on
GTK+, but others declared in "ui_util.h" do, and we don't want to oblige
a source file to depend on GTK+ headers unless it uses a GTK+ API or an
API that depends on GTK+.
svn path=/trunk/; revision=3179
for the dialog window as an argument (as various dialog creators in GTK+
do), not oblige every caller of it to cut-and-paste a
"gtk_window_set_title()" call after it.
svn path=/trunk/; revision=2345
TRUE, meaning "don't delete this", and if its "stop this operation"
button gets clicked, don't have its handler delete the progress dialog;
instead, leave the deletion of the window up to the code using the
dialog, as it'll do so when it stops the operation.
Make the "read file" operation destroy the dialog; all the other
operations already did so (as they just broke out of the loop doing the
operation, rather than returning).
Don't catch the "destroy" operation on the dialog box - its handler
appeared never to get called; we can just free the "progdlg_t" for the
dialog in "destroy_progress_dlg()", right after destroying the dialog
box widget.
svn path=/trunk/; revision=2122
dialog box; that lets us do some type-checking, but we can still typedef
it to an incompletely-defined structure to hide the implementation
details from the caller.
Make "create_progress_dlg()" take, as an argument, the title to put in
the "stop the operation" button, and use "Stop" rather than "Cancel" if
stopping the operation doesn't undo all the work it's done.
Thaw the clist if we break out of a "read the file" operation, as we
freeze it before the operation.
Have the handler for the "delete" event on the progress dialog box
return FALSE, to let GTK+ know that it should, in fact, delete the
window. ("delete" event handlers should return TRUE if the window
shouldn't actually be deleted, FALSE if it should; they should not
return "void".)
svn path=/trunk/; revision=2120
rather than an Alignment; that appears to be the correct way to keep
buttons from expanding to the full width of the window.
Don't use "gtk_widget_show()" on every single widget in the progress
dialog box, use "gtk_widget_show_all()" on the top-level widget.
svn path=/trunk/; revision=2114
"gtk_grab_add()"; the former makes it a bit clearer what's being done,
and I think it may be considered the right way to do it (GTK+ remembers
the state of the window and appears to add and remove the grab as
appropriate).
svn path=/trunk/; revision=2113
window and makes it transient for the top-level window; the
transient-for at least provides a hint to X window managers to
minimize the dialog if the main window is minimized;
keep the dialog on top of the main window in the Z order for
windows;
perhaps (if there are any window managers that actually *do*
this) even put it atop the main window in the X-Y plane (KWM
doesn't and I seem to remember that the Exceed X server for
Windows doesn't).
It's generally considered the Right Thing To Do for dialog boxes.
Use that routine to create dialog boxes, rather than doing it directly
in the code for that dialog box.
svn path=/trunk/; revision=2112
parameters and doesn't have to be stuffed into a GtkAlignment to align
it on the left. (Alas, GtkButton *isn't* a subclass of GtkMisc, so we
have to stuff the Cancel button into an alignment to keep it from
growing to the width of the window.)
svn path=/trunk/; revision=2105
potentially long-running operation that has a progress indicator, pop up
a modal dialog box with
an indication of what is being done;
a progress bar;
a "Cancel" button to stop the operation.
This:
leaves more room on the status line for a filter expression;
provides a mechanism to allow the user to cancel long-running
operations (although the way we do so may not back out of them
as nicely as the user might like, if it's not obvious what the
"right" way is or if the "right" way is difficult to implement
or involves doing as much work as letting the operation
continue);
means that, because the dialog box is modal, we don't have to
worry about the user performing arbitrary UI operations out from
under the operation and changing arbitrary bits of state being
used by that operation.
svn path=/trunk/; revision=2103
Guy Harris