rednotebook
rednotebook copied to clipboard
jendrikseipp
Multisession: Update content if it's changed externally
Originally reported by szybalski at https://bugs.launchpad.net/bugs/974590 (2012-04-05T20:00:11Z):
Hello, I've been using rednotebook for a week now. Its a great software but today I've got an issue.
Yesterday at work I updated my notes of what I've been doing. I left the rednotebook open without realizing it. Laster on that night I've logged in from home to my computer at work, did some work and updated a whole lot of information with todo lists, etc. Today I came in, but when I saw the rednotebook open, and when I clicked next previous days, the information I've saved yesterday was not there.
It looks like because this rednotebook was open when it autosaved it overwrote my information that I've saved using another session. I guess the rednotebook on my pc did not check if "content has changed" since the last time it was open.
Debian Linux Stable. Thank you, Lucas
Original comment by jendrikseipp (2012-04-05T23:33:20Z):
Thanks for reporting this. I'll see how we can tackle this.
Original comment by paytonturnage-deactivatedaccount (2012-12-13T14:38:13Z):
I suggest adding a sort of flag file in the journal directory. When red notebook opens, create a "lock.lock" file if it doesn't exist. If it does exist (another rednotebook instance is already open), then we can handle in that case either by warning the user or writing to a temp directory or something (or another solution).
For the "rednotebook is open" check, it will just check for a lock.lock and create it in the journal directory on open, and delete it on close. The thing I can foresee potentially being a problem is if red notebook crashes or the computer turns off suddenly, the lock.lock would remain. I guess there could be an option in the warning to say "there are no other instances open let me do my stuff".
All of these ideas apply only to red notebook. What if they open the file in notepad or vi and change it? Notepad++ checks all the open files for changes upon action. (whenever you click on the window to give it focus again) and I believe it does that by making an SHA digest of the temp file and the file on the hard disk and if they're different, asking the user if to keep using the temp file or reloading it from the drive.
Original comment by jendrikseipp (2014-09-16T19:24:43Z):
I think a good solution would be to warn the user once he wants to save a month file that has changed while he opened it (we would have to save the time of opening the file). Then he should be presented with the differences and be able to decide if he wants to merge the changes or just keep one of the versions. This would also allow to use multiple copies of RedNotebook (which is actually useful, because people often use multiple journals).
Original comment by tech-infogerance (2014-10-28T21:36:35Z):
I personally would like if rednotebook would appear (brought front) or is brought to the current workspace if I ever re-launch it.
Original comment by rupert-kolb (2015-08-21T11:00:12Z):
The suggested solution (#3) sounds good. I'm new to rednotebook. This (yet missing) feature would be very helpful for me.
Original comment by lenumina (2016-01-18T15:08:22Z):
I have a similar problem. I am using dropbox to sync data. I was able to create junctions (mklink /J) from .rednotebook into .rednotebook in my dropbox folder for laptop and desktop machines. I found that the option to "close to system tray" was an issue because it kept files open. I was also able to created multiple instances on the same machine in the system tray.
At the moment, as long as I remember to close the program, it all works, but when I change machines I get an error message that the file cannot be used and that its opening a default location. I then simply open the General journal and I have all of my data and can continue working.
I would recommend you solve this and the general issue by closing all files when you "close to system tray". That why they will get updated and resync'd automatically by dropbox. When the program is maximized (OR WHEN IT IS RESTARTED BUT ALREADY EXISTS IN THE SYSTEM TRAY) it would reopen the data file(s). If the program is already running (and minimized) it should resume that session or worst case, alert the user that an instance is already running and ask if he wants to start a new instance or resume the existing one.
If you choose to have more than one instance running (as the developer) then I suggest that the most recent datafile be shown as a hint on hovering over the icon in the system tray. I suppose that would allow several journal files to be the targets of different instances. To make it work between home and work, as other users have suggested can be dome with a simple autominimize timer. When the timer expires, the program is minimized to the task bar, and as noted above the data files would be closed.
That way, by the time you get home, the program is minimized and the datafiles are closed. You can then open up the program from another location, edit the data, and again, let it autominimize or close it to make sure the datafiles are released.
To gaurd against issues related to system or program hanging and failing to close the one might, upon finding another instance having the dropbox file open (which should never happen with a reasonably short timeout) you might offer to take notes to a "temp" journal with the user picking the target journal simply based on reading the directory journal names. When the user restarts the program, if a temp journal exists, he is offered to import that to the previously hung version.
Therefore, once the hung instance is cleared, restarting the program would notify the user that there is temp data for that journal, and ask him if he'd like to import it to the actual journal "now" or ignore it for this session. (similar to how Microsoft handles recovered word files).
I think the dropbox part of the help file needs rewriting. If you improve the functionality as noted above or some other way to fix the issue of multiple editing, I will update the documentation and provide examples.
/Len
Original comment by lenumina (2016-01-18T15:11:40Z):
Sorry for the typos in my long post. I can assure you, English is my only language. Typing is a bit rough! /Len
Original comment by jendrikseipp (2016-02-28T19:05:04Z):
I completely agree that close-to-tray is dangerous. However, it seems that users still need that functionality. Closing the files when we close-to-tray doesn't solve all the problems here and detecting whether an instance of the program is already running is error-prone, so I still believe that the solution from #3 is best.
Closing this issue since we now only allow one RedNotebook instance running simultaneously. Synchronizing content that is changed on another computer while RedNotebook is running is out of scope.