| Quick navigation: | Home | Site Map || References | Biography || Copyright | Other copyright | Contact us | | |
|
Re: [ccp4bb] WM DELETE WINDOW |
|
CCP4bb navigationCCP4bb <-- 2008 <-- March 2008 <-- 04 March 2008Subject: Re: WM DELETE WINDOW From: James Stroud jstroud {- at -} MBI {- dot -} UCLA {- dot -} EDU Date: 2008-03-04 > I would argue that consistency with other applications is less > important than the irritation of another confirm button. I'm surely > not the only one who grumbles 'yes of course I wanted to exit, why > else do you think I clicked the exit button'.... ;-) First, the close button could map to a different call back than the EXIT button. Intercepting and putting up a confirmation dialog is trivial and amounts, inclusively, to (1) changing the already existing binding self.winfo_toplevel().protocol("WM_DELETE_WINDOW", self.wm_delete) plus (2) three new lines of code: def wm_delete(self): if tkMessageBox.askyesno("Exit", "Exit ccp4i?"): self.exit() Second, I think the behavior most consistent with almost every application created in the last 15 years is to ask to close if the user has made unsaved changes. This could be as simple as adding a callback to the input fields when they lose focus (which I assume are already sub-classed any way). Consider, for example, one's trying to import a CNS file, where one spends 25 minutes getting the 6x,F10.5,6x,I10,etc. just right, and after the 5th iteration one tries to close the task input window only to close the main ccp4i window, which exits without so much as a core- dump. For my 4 function calculator, I don't want it to ask me if I want it to close. For my word processor, I expect confirmation if I've made changes. For a crystallography suite, I would err on the side of caution. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com CCP4bb navigationCCP4bb <-- 2008 <-- March 2008 <-- 04 March 2008 |
| ProteinCrystallography.org: Copyright 2006-2007 by Quid United Ltd |