The save "dialog" could be console-based like in the old days.  For each 
open outline a line would be emitted:

Do you want to save unsaved-file.leo (Y/N)? Y

That might be considerably easier to implement than a GUI-style dialog, and 
TK wouldn't need to be imported if Qt weren't available.
On Sunday, August 1, 2021 at 7:01:29 AM UTC-4 Edward K. Ream wrote:

> 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/fd96e084-499a-4eef-a48b-e256c06b5f41n%40googlegroups.com.

Reply via email to