| Project: | Mori |
| Version: | 1.6.11 |
| Component: | Miscellaneous |
| Category: | bug |
| Priority: | critical |
| Assigned: | Alfonso Guerra |
| Status: | active |
Description
I am often seeing long delays when I try to edit the text of an item.
I have a workbook that has folders for the last 5 or so years. Within each year, I clip interesting web pages (mostly news, but not always). I have on average 1000 items per year with a max of just over 1500 items.
The most reliable slowdown I see is when I decide to edit one of the web clippings I've just pasted into an item. Just deleting a few lines usually takes over a minute.
I also use Mori to take notes during meetings at work and now and then, it will just lock up. Probably, these lock-ups are mostly around the same thing: editing.
I'm using 1.6.11 on a MacBook Pro which is running 10.5.4.
Updates
| Assigned to: | » Alfonso Guerra |
If you can get Mori to beachball (become unresponsive) on a particular clip after editing, please drop a link to it here (and identify what you began editing). I'll attempt to isolate the cause from that.
Alfonso
I don't think it has anything to do with specific clips. I see these slow downs when creating new entries, when beginning to edit an entry's notes, and when clipping using the Service menu
I'm reverting to 1.6.10. Will keep all informed
Bob
Version 1.6.10 seems to have the same issue with the spinning beach ball of death. But it also has a problem with emptying the trash. Giving 1.6.11 another try
Bob
If the original reporter is seeing what I see, there's no beachball. But the caret stops blinking. It feels like some kind of autosave that takes several seconds and blocks the whole aplication.
| Priority: | normal | » critical |
Is this the problem where the console is filled with messages about "menu: 1048576 event: -2138046456"? I first heard about it from Rolf, where it was discovered to be a conflict with some plugins.
Alfonso
At least I don't have any plugins installed and don't get messages in console.log.
I just saw the problem when typing in the table as well. This time with beachball.
It only occurs when starting new texts, either by typing in the note of an entry for the first time or by creating a new entry with a title. I'd say it happens in 1/3 of all such cases.
I'm seeing the following in the console when this happens:
10/25/08 10:47:59 AM mdworker[5115] Error loading /Applications/Mori.app/Contents/Library/Spotlight/MIDocumentMetadataImporter.mdimporter/Contents/MacOS/MIDocumentMetadataImporter: dlopen(/Applications/Mori.app/Contents/Library/Spotlight/MIDocumentMetadataImporter.mdimporter/Contents/MacOS/MIDocumentMetadataImporter, 262): Library not loaded: @executable_path/../Frameworks/Blocks.framework/Versions/A/Blocks
Referenced from: /Applications/Mori.app/Contents/Library/Spotlight/MIDocumentMetadataImporter.mdimporter/Contents/MacOS/MIDocumentMetadataImporter
Reason: image not found
10/25/08 10:47:59 AM mdworker[5115] Cannot find function pointer MetadataImporterPluginFactory for factory 800F2EC7-E580-457D-AE0F-677341335F99 in CFBundle/CFPlugIn 0x129a00 (bundle, not loaded)
I just want to add fuel: random very annoying delays and unresponsiveness is a typical treat of Mori, and has been so ever since I bought an upgrade to Mori from HBN in August 2007. I use Leopard on a MacBook Pro. I have NO plugins. I view in Widescreen mode. Just about all my entries are text entries, i.e almost no images or other objects, but a fair number o links.
I don't get delays of the size of minutes, but a few seconds, which is bad enough.
It can happen just about any time, not just new entries. Usually after just switching to an entry. But mostly it appears to happen randomly while writing, or when I start to add some text to a note.
Clicking the Help menu issues the dreadful beach ball! For nine seconds!!!
I have actually lost most faith in thinking Mori will ever come to grips with this, since it has been reported long ago (and I think I reported that a year ago) and nothing happens.