GNOME Bugzilla – Bug 612992
Notebooks lost on Tomboy restart
Last modified: 2010-10-22 22:48:49 UTC
On Mac OSX if I - create a Notebook - assign a note to it - restart Tomboy , then the - the notebook is lost - the note is still there but is not assigned to any notebook Basically all the notebooks created are lost on Tomboy restart, but the notes at least remain accessible. Notebook handling works fine on the stable 1.0.1 version. I tested 1.1.4 and 1.1.1 and both have the same notebook handling issue.
This works fine in Linux, I'll test on Mac as soon as I get a chance.
(In reply to comment #1) > This works fine in Linux, I'll test on Mac as soon as I get a chance. Let me know if I can help you with something like collecting logs, etc.
I'd like to second this bug. I have exactly the same problem with 1.1.4. No problems with 1.0.1.
I just reverted to 1.1.0 and it works in that version. By reverting I mean that I just installed 1.1.0 over 1.1.4.
I just tested 1.2.0 (the latest stable version) and this bug is not fixed. The notebooks created with 1.0.1 do not show up and all notebooks that I created got lost after restart.
I finally got a chance to try this out on my Mac, and I can now confirm that this bug does exist on 10.6. I don't know what's going on yet but will try to get it fixed for 1.2.1. All of your comments have been very helpful.
@Miklos: Thanks for saving me an hour! @Sandy (and all others) Thanks for a great effort! Possibly another clue, possibly another problem or possibly by design? On 1.1.0 the pop-up menu in the Dock icon is yellow. In 1.1.4 it is white and um, different. Again, I don't know if this is by design or not but I noted the difference.
The Notebooks are behaving very inconsistently for me (OSX 10.6.3, Tomboy 1.2.0, and Mono 2.6.3). I am also syncing (via NFS-mounted folder) with a Windows Laptop (my old machine). The Windows machine always shows all notebooks correctly. The bug appears to be in how the list of notebooks are loaded on the Mac version. If I create a new notebook with the same name as an existing one from the Windows machine, all of my notes from that task will then show up as belonging to that note. Once Tomboy is restarted however, the list of notebooks is reset once again.
I experience the same bug on Mac OSX 10.5.8 using MonoFramework 2.6.3_4 (Novell's PPC Build) TomBoy 1.2.0 On a Dual G5 PPC. Like everyone else, On Linux OS's TomBoy does not have this behavior, it seems to be unique to MacOSX.
I'm experiencing the same problem on a Mac with OS X 10.6.3. Just in case it helps in the debugging process, in my case I didn't create any notebook. The notebooks simply disappeared. The thing is, the first time I used Tomboy right after installation, all the notebooks were there. JM
I am experiencing this problem on Mac OS X 10.5.8 running Tomboy 1.3.1. The notebooks works fine on 1.0.1 and 1.1.0. Here is my history of Mono installs: MonoFramework-2.4.2.3_3.macos10.novell.x86.pkg MonoFramework-2.4.2.3_6.macos10.novell.x86.pkg MonoFramework-2.6.1_1.macos10.novell.x86.pkg MonoFramework-2.6.3_4.macos10.novell.x86.pkg MonoFramework-2.6.4_3.macos10.novell.x86.pkg
I spent some time trying to debug this...basically the notebooks add-in is getting initialized before the notes are loaded, which is not the way it's supposed to work. The optimization work I did in the 1.1/1.2 cycle is what has exposed this problem on the Mac.
I have a Mac now too and ran into that problem with tomboy 1.3.1. I will try to fix it when I have everything set up.
My experience has that any note that I put in a notebook that dissappeared, if after restarting Tomboy, the notebook is recreated, all the notes will jump right into their proper place, suggesting that the notes are retaining whatever metadata it is that they use to remember what notebook they're in.
Yup, Chris, you are right. The metadata is retained, but Tomboy is messing up at load time and not recognizing that any notebooks exist. Sorry for not making that clear earlier in the bug. There is no actual data loss, so don't worry if you are in some sort of sync scenario. The data just isn't being presented (still a big deal).
I think I understand what happens here. At startup the notebooks are created in NoteManager.LoadNotebooks() which is called from NoteManager's static constructor. NotebookApplicationAddion has a mac-specific block (line 130...) that accesses NotebookManager and causes the static constructor to be called too early. On Linux NotebookManager is not created before the search window is opened.
Ugh, static constructors are evil! Thanks for tracking this down, Stefan. If you don't get to it I'll try to work up a patch this weekend.
I tried removing all mac-specific blocks from NotebookApplicationAddin and the notebooks showed up in the user interface. Sandy, do you know why these blocks are necessary at all? I don't understand the following comment: 'Make the menu once, since Shown events aren't working in Mac Menu'. The menus seem to work right without that piece of code as well.
When I wrote this code, there was as problem where you could not remove menu items from menus properly. That is what the blocks that HideAll and then Remove were all about. I don't remember the specific problem with the comment you're referring to. I'd recommend just making sure that the File->Notebooks menu (in the mac menubar) works properly when adding and removing notebooks. It would be great if these Mac-specific blocks could be removed. It's totally possible that newer versions of gtk+ and igemacmenu bundled in latest Mono have resolved the old problems those blocks were designed to work around.
You are right, File->Notebooks still does not work without your workaround.
So what's happening here is that the NotebookApplication add-in is getting initialized *before* the NoteManager loads notes. In it's Initialize method it references the NotebookManager, which triggers the static constructor of NotebookManager to get called, and then LoadNotebooks. The current design really requires LoadNotebooks to be called *after* NoteManager is done loading notes. So we need to either redesign things in the NotebookManager to be more flexible, or we need to figure out *why* the NotebookApplication add-in is getting initialized before notes are loaded (I think this only happens on Mac, but it's possible it happens on all platforms and it's only affecting Mac because of the #if MAC blocks during NotebookApplicationAddin init reference the NotebookManager).
Created attachment 172953 [details] [review] Fix loading of notebooks Here is an idea that was easy to implement. What do you think?
Review of attachment 172953 [details] [review]: I love the idea of making the order _strict_ for dependencies like this. Didn't test this so far, just one question: It seems this event is fired once only, right? So it seems you now _rely_ on the NotebookManager's static constructor running before the NoteManager's LoadNotes(), otherwise NotebookManager:LoadNotesbooks() won't be called at all anymore? It's late though - am I missing something?
Review of attachment 172953 [details] [review]: You are right Ben, that is a problem and will only work on mac. Do you have another idea?
Created attachment 172958 [details] [review] Fix loading of notebooks 2 Here is a slightly improved version of my previous patch.
Review of attachment 172958 [details] [review]: This seems reasonable. If you can verify that it works on Linux and Mac, I'd say go ahead and push to master.
Review of attachment 172958 [details] [review]: Although this still seems to count on the ApplicationAddin.Initialize getting called before the notes are loaded. Maybe a flag on NoteManager, like NotesLoaded, would work. If NotesLoaded==True, don't subscribe to the event; just load the notebooks.
Review of attachment 172958 [details] [review]: A very, very evil way would be to track the state, like Sandy suggests, and fire the event right away in the setter if the flag is set - abusing the event way to specify add {}/remove {} instead of get {}/set {}. That would resolve the "You need to subscribe _first_" problem. Sorry for being not more productive or creative here, won't be able to apply/test (or even think) about this before the weekend.
Review of attachment 172958 [details] [review]: Thanks for all the input. NoteManager already has an Initialized flag, maybe I can use that.
Indeed it does, I forgot I'd added that. That is in fact exactly what you should use.
Created attachment 173036 [details] [review] Fix loading of notebooks 3 In this version the order of initialization of NotebookManager and NoteManager does not matter any more.
Review of attachment 173036 [details] [review]: Seems good to me, thanks! In retrospect, you could use NoteManager.GtkInvoke. In fact, that's what that method is for. But it has a stupid while spinner in it. I think I'll refactor it to use an event like what you've done. But go ahead and commit and we can clean up GtkInvoke later.
Review of attachment 173036 [details] [review]: Pushed to master. It's strange that sometimes the [mac] prefix gets lost when I use 'git am'.