In this Engineering Notebook post, I'll discuss how Leo handles "file not saved" dialogs and how to do roughly the same thing in leoInteg. See leoInteg issue #142 <https://github.com/boltex/leointeg/issues/142>.
*Background* The problem is to issue warnings about unsaved *.leo* files when vs-code is about to close. Alas, leoInteg can not issue "file not saved" warnings directly. vs-code does not tell leoInteg that vs-code is about to close!! Félix tells me that a workaround is possible. leoInteg starts leoserver.py in a separate process that *won't* automatically die when vs-code dies. At present, leoserver.py kills itself when it detects a broken connection. The idea is to have leoserver.py issue the warnings (and save the files!) before dying. *Related code in Leo* When Leo *itself *quits, Leo's shutdown logic eventually calls LeoFrame.promptForSave for every unsaved (dirty) .leo file. The LeoFrame class is the base class of all frames, so promptForSave is a gui-independent method. promptForSave calls g.app.gui.runAskYesNoCancelDialog, so the task is to make runAskYesNoCancelDialog functional in leoserver.py. *Note:* It would be wrong to change runAskYesNoCancelDialog directly in Leo's NullGui class because Leo's unit tests (and maybe other code) expect the NullGui class *not* to wait for user input. Therefore, leoserver.py should monkey-patch runAskYesNoCancelDialog. leoserver.py accesses Leo's code via Leo's bridge. Some experiments will show what happens if the client (of leoBridge.py) closes a dirty .leo file. I suspect that the leoBridge.py does *not* call promptForSave. *Implementing runAskYesNoCancelDialog * leoInteg *can not* assume that the leoInteg user has installed Qt. However, for prototyping I *will *assume that Qt *is* available. Even so, raising LeoQtGui.runAskYesNoCancelDialog isn't entirely trivial: it will involve instantiating (parts of) a Qt gui in leoserver.py. When the Qt dialog works, I'll turn my attention to implementing runAskYesNoCancelDialog using python's Tk package. In general, leoInteg *can* assume that python contains the Tk package. Implementing runAskYesNoCancelDialog in Tk will take some work. Leo already uses Tk to implement g.EmergencyDialog. However, this class implements something like Gui.runAskOkDialog. Not exactly what we want. *Summary* leoInteg needs help to warn the user when closing unsaved .leo files. leoserver.py knows when vs-code has closed and can issue the desired warnings with help from leoBridge.py. leoserver.py will monkey-patch NullGui.runAskYesNoCancelDialog to raise a *visible, functional* warning dialog. As I write this, I see that the "Cancel" option should *not* be available. There is no way to tell vs-code not to quit! So the monkey-patched code will look and work like LeoQtGui.runAskYesNoDialog. Some easy experiments will reveal how leoBridge.py can call LeoFrame.promptForSave. NullFrame objects are subclasses of LeoFrame, so calling c.frame.promptForSave will raise the desired dialogs. In short: leoserver.py will: - monkey-patch LeoFrame.promptForSave so that it raises a *visible, functional* warning dialog. The code will use Qt if available, falling back to Tk otherwise. - call c.frame.promptForSave for every unsaved open commander that leoBridge.py is managing. All questions, comments, and corrections are welcome. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/131a9d86-e29f-4308-9764-260dd0b4b83cn%40googlegroups.com.
