GNOME Bugzilla – Bug 305118
Remember position, open/closed state of notes and recall them at startup
Last modified: 2008-02-26 20:52:42 UTC
It'd be nice if notes remembered where they were and whether they were open or not so when Tomboy is started (at login for instance) they reappear just like they were left. I use it for a todo list, but sometimes forget to look at the todo list which makes it not so useful for deadlines! If it was always open on my first desktop it'd be harder to ignore.
So as a short-term solution, if you have a Tomboy built with dbus support, you can add something like "tomboy --open-note MyTodoList" to your session startup. Just make sure that this gets run after the panel applet is already running, since dbus activation doesn't work currently.
*** Bug 330311 has been marked as a duplicate of this bug. ***
Just a second to affirm that this is a useful and desired feature (I was going to file a bug report about it, but found this one already there). Ideally, I think Tomboy should have full session support; not sure how this works with the whole applet thing though.
Created attachment 85775 [details] [review] Startup notes patch Hi, I tried to implement that very useful feature. My patch introduces a new GConf entry, where a whitespace-separated list of note URIs is stored, much like the list of pinned menu items. When Tomboy shuts down, the URIs of all visible notes are written to that entry, on startup these notes are opened automatically.
This looks promising so far. Good work! I question our use of GConf since it makes it a little harder to migrate notes from machine to machine. Also, would there be a benefit to using a list in GConf instead of a whitespace-separated string? Finally, this ought to be a configurable setting with a checkbox setting in the preferences.
Thanks for the hint! Using a list seems much more logical to me because we don't have to split that string then. I will rewrite the patch. Also, where can I add the preference setting? I think it does not fit well into the Editing-tab.
I think the Editing tab is the best bet for now. Seems like it may be okay to put it there for now.
Unfortunately it is not possible to store an empty list with gconf# because of this bug: http://bugzilla.ximian.com/show_bug.cgi?id=81188 Probably that is why a whitespace-separated string has been used for the pinned menu items.
That sucks. Is there any advantage to using a list, and just keeping in a member called "empty" or "last" or "placeholder" or something like that?(In reply to comment #8) > Unfortunately it is not possible to store an empty list with gconf# because of > this bug: That sucks. Is there any advantage to using a list, and just keeping in a member called "empty" or "last" or "placeholder" or something like that? Or is it easier just to use a whitespace-separated string? And excellent work on this! I know I'll appreciate this feature, and I'm sure others will, too.
(In reply to comment #5) > I question our use of GConf since it > makes it a little harder to migrate notes from machine to machine. So I'm assuming you're not suggesting adding some sort of configuration file to .tomboy, and you probably want to see something stored in the note XML indicating that it should be opened on start-up? That makes sense to me... after all, we're already storing the size and location of the note within its XML. Why not add some information indicating whether or not the note was open last time Tomboy quit?
Storing that in the note itself makes also sense to me. But then the information, if a note is pinned, should also be stored there, just to be consistent.
(In reply to comment #11) > Storing that in the note itself makes also sense to me. But then the > information, if a note is pinned, should also be stored there, just to be > consistent. I would agree with this assesment. Or at least, the pin/unpin status should be synchronized whenever note synchronization is implemented. With my current mechanism for synchronizing Tomboy (Unison to sync tomboy dirs, then restart Tomboy), the pin information is lost.
(In reply to comment #11) > Storing that in the note itself makes also sense to me. But then the > information, if a note is pinned, should also be stored there, just to be > consistent. Agreed. Also, I'm wondering if there's any value in saving the workspace number of the note as well. If people like having all the notes that were open when they closed come back up when Tomboy opens, they might also expect them to show up in the correct workspace. Although for some users, this behavior might be confusing. If we implemented it, perhaps there could be a "hidden" gconf pref that defaulted to showing all notes on the current workspace when Tomboy starts? Thoughts? I suppose the easiest thing to do is get the current behavior cleaned up and checked in, and see if people complain when they get the first development release.
Created attachment 85895 [details] [review] Extended startup notes patch The new patch is pretty big, I hope I did not change too many things at once. The option in the preferences dialog is still missing, I will add it next week in a second patch. * Tomboy/NoteManager.cs: All notes that were visible when tomboy quit, are reopened on startup. * Tomboy/Note.cs: Added/changed properties IsPinned and IsOpenOnStartup in NoteData and Note. Implemented reading and writing for these properties in NoteArchiver. * Tomboy/Preferences.cs, data/tomboy.schemas.in: Removed the GConf key menu_pinned_notes, added enable_startup_notes which is enabled by default.
This is looking pretty good. I'm not 100% sure about defaulting the pref to true, but at least for development releases it's probably a good way to advertise the feature. Here are my nitpicky comments: 1) In data/tomboy.schemas.in , remove the comma between "quit" and "will". 2) Our coding standards dictate that we don't use curly braces in "if" or "for" or whatever statements unless the body is more than one line. 3) Start-up speed is always a concern with Tomboy. I wonder if it would be measurably better to remove "ShowStartupNotes" and migrate its logic to "LoadNotes". That way we're only iterating through the list of notes once. 4) Shut-down speed also seems to be affected by this patch, but I guess that's inevitable since we're doing an actual save on each note when it closes ("Save" has always been called on each note, but normally there are no changes so it will just return). One possible approach to this: Set IsOpenOnStartup to true when the note is opened, and set it to false when the note is closed (except during shutdown). In theory this behavior would only modify the note as much as dragging it around the screen would; the content isn't changing, just some of the metadata associated with it. Thoughts?
(In reply to comment #15) > 3) Start-up speed is always a concern with Tomboy. I wonder if it would be > measurably better to remove "ShowStartupNotes" and migrate its logic to > "LoadNotes". That way we're only iterating through the list of notes once. Good idea, I will change that. > 4) Shut-down speed also seems to be affected by this patch, but I guess that's > inevitable since we're doing an actual save on each note when it closes ("Save" > has always been called on each note, but normally there are no changes so it > will just return). One possible approach to this: Set IsOpenOnStartup to true > when the note is opened, and set it to false when the note is closed (except > during shutdown). In theory this behavior would only modify the note as much > as dragging it around the screen would; the content isn't changing, just some > of the metadata associated with it. Thoughts? I don't think shut-down speed is that much affected because only open notes will be saved, Save() will still return for all other notes.
(In reply to comment #14) > * Tomboy/Note.cs: Added/changed properties IsPinned and IsOpenOnStartup in > NoteData and Note. Implemented reading and writing for these properties > in NoteArchiver. > * Tomboy/Preferences.cs, data/tomboy.schemas.in: Removed the GConf key > menu_pinned_notes, added enable_startup_notes which is enabled by > default. So the dark side of this change is that users lose their old pinned notes when they use Tomboy with this patch applied. I still believe it's the correct solution, though. Possible workarounds: 1) A plug-in to update your notes from the old gconf pref (seems a little heavy). 2) Some extra logic in the code to check the old gconf pref, update the relevant notes, then clear the old gconf pref. But then how long do we maintain this? What are our responsibilities as part of GNOME to maintain this sort of user metadata?
(In reply to comment #17) > What are our responsibilities as part of GNOME to maintain this sort of user > metadata? I have found some recommendations about Backward/forward compatibility [1]: "...To allow applications to add new features, we do allow that if you are logged in using two versions, you may need to configure 'the same' thing twice, once per version. Of course it's best to avoid this..." I think we have to find a compromise between effort and compatibility. We could also pin the notes from the old gconf pref to be backward compatible but should not clear the pref, so the older version will have that notes still pinned. If a note is pinned with a newer Tomboy version, that information will only be available for the newer version then. What do you think? [1] http://www.gnome.org/projects/gconf/
(In reply to comment #18) > I think we have to find a compromise between effort and compatibility. We could > also pin the notes from the old gconf pref to be backward compatible but should > not clear the pref, so the older version will have that notes still pinned. If > a note is pinned with a newer Tomboy version, that information will only be > available for the newer version then. What do you think? In my mind, the only users who will be switching back to old versions fall in one of these categories: 1) Users who build a devel release or SVN, but then decide to go back to their distro-provided Tomboy. 2) Users who have ad-hoc synchronization solutions set up between machines running different versions of Tomboy. 3) Random weird edge cases. While in the future sync will be a real issue, for now I think we only have to worry about group #1. Therefore, I tentatively agree with you. Although now that you bring it up, it does suck that folks in group #1 will lose any newly-pinned notes if they decide to use an older Tomboy.
Created attachment 86135 [details] [review] Backward compatible startup notes patch "ShowStartupNotes" has been merged into "LoadNotes", the old gconf pref is also imported there. Some clean-ups. Group #1 loses the state of newly pinned notes when using an older version, as Sanford explained in the post above.
(In reply to comment #19) > While in the future sync will be a real issue, for now I think we only have to > worry about group #1. Therefore, I tentatively agree with you. Although now > that you bring it up, it does suck that folks in group #1 will lose any > newly-pinned notes if they decide to use an older Tomboy. I still do not have an idea for solving that problem. If we cannot decide on a solution, I could remove all things related to pinning from the patch.
Stefan, could you update the patch to remove all of the pinning stuff? I'd like to commit the rest of this. If you have time, could you create a new bug with a patch for the pinning stuff? I'd like to capture that, too. Thanks!
While it's lame that we'd have to do anything like this, I'd prefer to see some sort of code that runs near startup time once that checks for pinned notes being specified in GConf and migrates them over. Maybe after a couple of stable releases, this could be removed. We've also got to figure out something smart for dealing with pinned notes ... so we don't have to go grep through all the *.note files every time we want to know the pinned-note list. (sorry if you've already implemented that ... haven't made the time to review your patches specifically)
Created attachment 87022 [details] [review] Startup notes patch without pinning changes I removed the pinning stuff from the patch.
bug 433412 created for pinning stuff
Thanks Stefan, I'll double-check this and commit it ASAP (probably tomorrow).
Committed in r1154. We may still want to expose the GConf pref in the preferences dialog.
Stefan, this patch doesn't work when I have notes open and log out, then log back in. This is the exact sequence I tried: 1. Log in. 2. Open Tomboy. 3. Open three notes. 4. Log out. 5. Log back in. 6. Open Tomboy. No notes opened. I don't have time to look into it right now, so I'm just reopening the bug. :-)
(In reply to comment #28) > Stefan, this patch doesn't work when I have notes open and log out, then log > back in. This is the exact sequence I tried: > 1. Log in. > 2. Open Tomboy. > 3. Open three notes. > 4. Log out. > 5. Log back in. > 6. Open Tomboy. > No notes opened. > I don't have time to look into it right now, so I'm just reopening the bug. > :-) I do not have much time now too, I will investigate in the problem next week.
I forgot to mention, but I assume the issue is that when you log out, the window manager closes all of the open windows before it tells Tomboy to quit. But I could be wrong.
(In reply to comment #30) > I forgot to mention, but I assume the issue is that when you log out, the > window manager closes all of the open windows before it tells Tomboy to quit. Whether or not that is the case, maybe Tomboy should update the status whenever a note is opened or closed? That way, in case of a crash (in Tomboy or the panel, etc.) Tomboy would come back as expected.
(In reply to comment #31) > (In reply to comment #30) > > I forgot to mention, but I assume the issue is that when you log out, the > > window manager closes all of the open windows before it tells Tomboy to quit. > > Whether or not that is the case, maybe Tomboy should update the status whenever > a note is opened or closed? That way, in case of a crash (in Tomboy or the > panel, etc.) Tomboy would come back as expected. That's exactly how this feature works.
(In reply to comment #32) > (In reply to comment #31) > > Whether or not that is the case, maybe Tomboy should update the status whenever > > a note is opened or closed? That way, in case of a crash (in Tomboy or the > > panel, etc.) Tomboy would come back as expected. > > That's exactly how this feature works. Oh, duh... and when the windows close, the status is updated. I see, I see... I'll go back to just reading the comments on this bug. O:-)
It would also be nice to have a show/hide all notes feature.
(In reply to comment #34) > It would also be nice to have a show/hide all notes feature. I'm not sure how that would work with hundreds of notes, but if you're interested in that you should file it as a new bug.
To solve some misunderstandings, the state is only updated when Tomboy exits, this is done in NoteManager.OnExitingEvent. In the Application class (Utils.cs) SIGTERM and SIGINT are caught to call NoteManager.OnExitingEvent but strangely enough that does not happen when logging out. I think it has nothing to do with the window manager. When calling OnExitingEvent manually just before "All done. Ciao!", everything works fine.
Created attachment 87540 [details] [review] Use SaveYourself event to remember open notes I think I've got it! Tomboy now responds to the SaveYourself event to call NoteManager.OnExitingEvent. I tested the patch with my old Gnome 2.14 and the notes open as expected when logging in again. I did not test running Tomboy as panel applet because I do not know how to do that with an uninstalled Tomboy. So please give the patch an extensive review.
Stefan, you rock! Though, this doesn't always work for me. Works fine when I run Tomboy as a panel applet. But I never use the panel applet. :-) Does not work when I start Tomboy from the Applications menu, open a note, log out, log back in, and start Tomboy from the Applications menu. Perhaps SaveYourself only gets fired if Tomboy is part of the GNOME session or something? I intentionally don't run with Tomboy as part of my GNOME session.
http://live.gnome.org/SessionManagement might be of interest. But I don't have the time right now to pursue it. We can probably go ahead and commit this patch since most users run Tomboy as part of their session. I'll do it this weekend if somebody doesn't beat me to it.
(In reply to comment #38) > Does not work when I start Tomboy from the Applications menu, open a note, log > out, log back in, and start Tomboy from the Applications menu. Perhaps > SaveYourself only gets fired if Tomboy is part of the GNOME session or > something? That's strange. I started an uninstalled Tomboy from the command line and everything worked fine. Perhaps that event has been changed since Gnome 2.14. Sandy, could you try out the patch using the Die event instead of SaveYourself?
(In reply to comment #40) > (In reply to comment #38) > > Does not work when I start Tomboy from the Applications menu, open a note, log > > out, log back in, and start Tomboy from the Applications menu. Perhaps > > SaveYourself only gets fired if Tomboy is part of the GNOME session or > > something? > That's strange. I started an uninstalled Tomboy from the command line and > everything worked fine. Perhaps that event has been changed since Gnome 2.14. > Sandy, could you try out the patch using the Die event instead of SaveYourself? That didn't work. I tossed it into the OnSessionManagerDie method which is already signed up for the Die event. Committed your patch as-is in r1160, since it seems to fix the normal Tomboy use case. I'd like to leave this bug open, though, and see if we can resolve my little edge case. :-) Thanks again, Stefan.
Now that I finally run the current Gnome 2.18, I tried to reproduce the problem. I tested the feature with installed and uninstalled Tomboys, launched from the Applications menu, command line or as startup program. It worked every time, the notes were opened as expected. Sorry, I could not reproduce your problem, Sandy.
Can anybody reproduce this? 1. Log in, no Tomboy instance running. 2. Start Tomboy. 3. Open some notes. 4. Log out. 5. Log back in (no Tomboy instance running, again). 6. Start Tomboy. Desired result: Notes you left open reopen. Actual result: No notes reopen. I'm using GNOME 2.18.1 as provided by Ubuntu Feisty, running latest Tomboy SVN, which I have installed with --prefix=/usr.
Do you still have problems with this feature, Sandy, or can we close the bug?