[meld] Don't rely on HistoryFileEntry's file dialog existing



commit d4eaa458a6ce6c46ec17cc3438d0c764aeabd81a
Author: Kai Willadsen <kai willadsen gmail com>
Date:   Sun Jul 5 13:11:00 2009 +1000

    Don't rely on HistoryFileEntry's file dialog existing
    
    By just hiding the file dialog, we relied on the dialog not being deleted
    somewhere else, such as in the default gtk.Dialog delete-event callback.
    This led to a bug where closing a filechooser using the window manager
    close button would cause a traceback when opening the dialog for a second
    time. Destroying the dialog widget on response and setting our filechooser
    member accordingly works around this problem.

 historyentry.py |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/historyentry.py b/historyentry.py
index 93357ed..fb440c4 100644
--- a/historyentry.py
+++ b/historyentry.py
@@ -345,7 +345,8 @@ class HistoryFileEntry(gtk.HBox, gtk.Editable):
     def __browse_dialog_response(self, widget, response):
         if response == gtk.RESPONSE_ACCEPT:
             self.__browse_dialog_ok(widget)
-        widget.hide()
+        widget.destroy()
+        self.fsw = None
 
     def __build_filename(self):
         text = self.__gentry.get_entry().get_text()



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]