aboutsummaryrefslogtreecommitdiffstats
path: root/gtk/progress_dlg.c
AgeCommit message (Collapse)AuthorFilesLines
2000-08-23Bleah. What was I thinking? "dlg_window_new()" should take the titleGuy Harris1-3/+2
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
2000-07-07If the progress dialog gets a "delete" event, have the handler returnGuy Harris1-38/+19
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
2000-07-07Use "progdlg_t *" rather than "void *" as the handle for a progressGuy Harris1-32/+63
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
2000-07-05Put the "Cancel" button in a progress dialog box in an HButtonBox,Guy Harris1-15/+13
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
2000-07-05To make windows modal, use "gtk_window_set_modal()" rather thanGuy Harris1-2/+2
"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
2000-07-05Add a "dlg_window_new()" routine, which creates a GTK_WINDOW_DIALOGGuy Harris1-2/+3
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
2000-07-03GtkLabel is a subclass of GtkMisc, so it has alignment and paddingGuy Harris1-9/+8
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
2000-07-03Remove the progress bar from the status line, and, instead, for anyGuy Harris1-0/+190
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