Multisession: Update content if it's changed externally

Bug #974590 reported by lszyba1 on 2012-04-05
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
RedNotebook
Medium
Unassigned

Bug Description

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

Related branches

lp:~przemub/rednotebook/lock-journal
Przemysław Buczkowski (community): Disapprove on 2014-09-19
Jendrik Seipp: Needs Fixing on 2014-09-16
Jendrik Seipp (jendrikseipp) wrote :

Thanks for reporting this. I'll see how we can tackle this.

Changed in rednotebook:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Jendrik Seipp (jendrikseipp)
summary: - Multi Session Lock not working
+ Multisession: Update content if it's changed externally
Changed in rednotebook:
assignee: Jendrik Seipp (jendrikseipp) → Przemysław Buczkowski (przemub)
assignee: Przemysław Buczkowski (przemub) → nobody
Jendrik Seipp (jendrikseipp) wrote :

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).

I personally would like if rednotebook would appear (brought front) or is brought to the current workspace if I ever re-launch it.

ruko (rupert-kolb) wrote :

The suggested solution (#3) sounds good.
I'm new to rednotebook. This (yet missing) feature would be very helpful for me.

umina (lenumina) wrote :

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

umina (lenumina) wrote :

Sorry for the typos in my long post. I can assure you, English is my only language. Typing is a bit rough! /Len

Jendrik Seipp (jendrikseipp) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers