Hi, There is kind of a standard way to deal with this problem, already. 1) an option to allow multiple versions of the app to run, or not. (maybe check if a file exists in the folder you keep your database file in) 2) When refreshing the display, check if a later version of the file exists than what is opened. (if the stored version is later than the last saved or loaded version) If so, ask the user if the user wants to load the later version of the file.
I think this behavior is in Notepad++ which is a good template for what works well for people. It would be so cool to actually diff the two versions and show the user ....wouldn't it? (in a separate floating window) Sorry I'm being extraneous. thanks! Todd. On Saturday, June 20, 2015 at 7:01:07 PM UTC-4, Edward K. Ream wrote: > > #199 <https://github.com/leo-editor/leo-editor/issues/199> is presently > the most serious bug in Leo. Sometimes, but not always, cancelling the > load of an already-opened .leo file will hard crash Leo (Python). > > This post is an Engineering Notebook post. It's most notes to myself and > Terry. Feel free to ignore. > > I am studying a core dump on Ubuntu. It's been fun learning about > apport-retrace > <http://manpages.ubuntu.com/manpages/vivid/en/man1/apport-retrace.1.html>, > but not *that *much fun. Terry's analysis of the problem is good enough > for me. It's time to solve the problem with design, not mere code. > > > > *The original problem*Leo should indeed warn users when they attempt to > open an already-open file, call it *f.leo*. Saving either copy of f.leo > could destroy data previously saved in the *other* copy of f.leo. > > The problem is not actually very serious, because Leo *already *warns if > f.leo has been changed outside of the presently executing copy of Leo. For > example, suppose two invocations of Leo exists. Let's call them *A* and > *B*. Suppose Leo A saves f.leo. Later, if B saves f.leo, Leo B will > issue a warning that f.leo has been changed outside of B. > > Still, I think it is best to warn the user if f.leo is already open. > > The mechanism for checking for already-open files is fine. Leo makes > entries in the global db file when opening a file and deletes entries in > the db when closing the file. This can lead to spurious "already open" > messages if Leo is killed rather than being closed normally. The db will > contain an entry for a .leo file that is not, in fact, open. Happily, this > has never been a big deal. Furthermore, the following scheme handles this > case even more smoothly than before. > > *Proposal: always open files, even if already open* > > Leo will no longer issue *per-file* requests for guidance. Instead, Leo > will open all possibly-already-open files, putting warnings about them in > the log. Finally, Leo will raise a *single *warning dialog. This dialog > will list the files that might already be open, and suggest that the user > close duplicate files in whatever copy of Leo is more convenient. > > This scheme solves several problems: > > 1. Leo always loads files. This instantly eliminates the possibility of > hard crashes. > > 2. It's faster than the existing scheme. The user only has to dismiss the > summary dialog. > > 3. The user will never have to choose *right now *what action to take. > Such choices are *always *odious and stressful. Instead, the user can > choose to close the duplicate f.leo file in either A or B. In most cases, > it's safe to leave *both* copies open, as long as both don't change. To > repeat, Leo will issue a warning if that happens. > > 4. Closing a duplicate file, in either A or B, automatically clears the db > entry for that file. There is no need to ask the user whether to reset the > db! > > The only complication will be knowing exactly when/where to issue the > warning dialog. The details will be different depending on whether Leo is > loading multiple files at startup, or loading a single file later. But > this is only a coding detail. > > *Summary* > > A single dialog that warns about possibly-already-open files is the > simplest thing that could possibly work: > > - It's easy to code. > - It will stamp out hard crashes. > - It's simpler, faster, more flexible and less stressful for the user. > > Unless there are strong objections to this scheme, I plan to put it into > effect immediately. > > Your comments, please, Amigos. > > Edward > <http://manpages.ubuntu.com/apport-retrace> > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
