Hi, all,
Since most of you guys (esp Bulia and Mental) are not on Jabber during the day while I am logged in, I thought I would send a bit of info to this list regarding finding the hang-on-close bug.
I have been trying for the last day or so to find the reason that event processing, and thus gtk_main_loop() keeps running when all views are gone, and one or other of the dialogs managed by DialogManager have been displayed.
Three things I know:
1) It is not the SPView in imageicon.cpp messing with the View-tracking code. I commented it out, no change.
2) It is not the result of wrap()-ing the SPView in a Gtk::Widget. Again, I commented it out with no change.
3) The DialogManager's destructor code seems to never be called, so explicitly deleting the managed dialogs would be a moot point.
But if you think about it.. a dialog undisplayed with F12 is hidden, not killed. Of course it is still processing events.
Below is the part of interface.cpp that is used for View deletion. sp_ui_close_view() is called by the verb for the File/Close menu item, while sp_ui_delete_view() is called by clicking the close [x] button. (I don't get that one. It seems to be a read-only function)
By tracing, I found that sp_ui_close_view() always reaches the end of the method, and calls gtk_destroy_widget().
I can only guess that the persistence of Gtkmm objects is different from C Gtk objects, and that maybe we cannot just use the same idea that when all visible frames are gone, the application will just "go away." Maybe some explicit frame-counting and deletion would be necessary. Maybe transientizing needs to be done differently.
Maybe maintain a std::map<Glib::ustring, SPView *> map of name->view of all editing windows.. When it goes to zero length, explicitly quit. This would also give us the ability to have a "Windows" menu.
Bob (ishmal)
==== SNIP ====== void sp_ui_close_view (GtkWidget * widget) { GtkWidget *w;
if (SP_ACTIVE_DESKTOP == NULL) { return; } w = (GtkWidget*)g_object_get_data (G_OBJECT (SP_ACTIVE_DESKTOP), "window"); if (sp_view_shutdown (SP_VIEW (SP_ACTIVE_DESKTOP))) { return; } gtk_widget_destroy (w); }
/** * sp_ui_close_all * * This function is called to exit the program, and iterates through all * open document view windows, attempting to close each in turn. If the * view has unsaved information, the user will be prompted to save, * discard, or cancel. * * Returns FALSE if the user cancels the close_all operation, TRUE * otherwise. */ unsigned int sp_ui_close_all (void) { /* Iterate through all the windows, destroying each in the order they become active */ while (SP_ACTIVE_DESKTOP) { GtkWidget *w; w = (GtkWidget*)g_object_get_data (G_OBJECT (SP_ACTIVE_DESKTOP), "window"); if (sp_view_shutdown (SP_VIEW (SP_ACTIVE_DESKTOP))) { /* The user cancelled the operation, so end doing the close */ return FALSE; } // gtk_widget_destroy (w);
// Spackle for Bug [ 1217361 ] "freeze on quitting with transform dialog" // The following code is intended to be temporary and IS NOT NEEDED once this part // of Inkscape is de-bugged, when the single line above should be re-instituted.
// At present, SP_ACTIVE_DESKTOP does not guarantee to return a gtk_widget: If we find // that we have been issued an object other than a widget we assume that something is // wrong upstream and quit immediately. if( GTK_IS_WIDGET(w) ) { // fprintf( stderr, "sp_ui_close_all( ) About to call gtk_widget_destroy ( %08p )\n", w ); gtk_widget_destroy (w); } else { g_warning( "Desktop has passed us a non-widget! : %p", w ); gtk_main_quit(); break; } }
return TRUE; }
static gint sp_ui_delete (GtkWidget *widget, GdkEvent *event, SPView *view) { return sp_view_shutdown (view); }
On 7/15/05, Bob Jamison <rjamison@...357...> wrote:
Hi, all, ...
I have been trying for the last day or so to find the reason that event processing, and thus gtk_main_loop() keeps running when all views are gone, and one or other of the dialogs managed by DialogManager have been displayed.
Three things I know: ...
- The DialogManager's destructor code seems to never be called, so
explicitly deleting the managed dialogs would be a moot point. [ snip ] I can only guess that the persistence of Gtkmm objects is different from C Gtk objects, and that maybe we cannot just use the same idea that when all visible frames are gone, the application will just "go away." Maybe some explicit frame-counting and deletion would be necessary. Maybe transientizing needs to be done differently.
Bug [ 1217361 ] "freeze on quitting with transform dialog" could well be manifestation of the same problem, and it might be better to fix this first.
participants (2)
-
Ben Fowler
-
Bob Jamison