Beta Bugs - Post Them Here

[KB]

That array is created by Scrivener when it empties the Trash. It is used to ensure that there are no ID clashes. For instance, if you sync and a document with ID "4" is in the sync folder, then you trash that file and create another file that is given the same ID (because IDs can be reused), then Scrivener needs to know that the document in your sync folder isn't the same as the one in the binder, but one that was previously deleted. The "deletedDocIDs" array should disappear the next time you sync. But any files that are in there will indeed get moved to the "Trash" folder - but they are getting moved from the "Draft" or "Notes" folders, which suggests that these files are there already. That is, Scrivener cannot *create* these files each time you sync. They must be somewhere to start with, and Scrivener is moving them there.

So, I'm a little confused as to where the files can be coming from - are you syncing with another program that might be adding these files back to the "Draft" or "Notes" folders at all? I would suggest starting a new project - just for test purposes - and seeing if you can reproduce this problem with a handful of test files. I have tried to do so, but so far, everything is working as expected for me.

Thanks and all the best,
Keith

P.S. I'm away for a week now, so please forgive me when it takes me a week to get back to you (I haven't been around much this week, unfortunately, either - sorry about that).

[ajbuch]

I manually emptied the array in folder-sync.plist, and the sync is now quick.

However, I have reproduced the problem on my machine.

- I created a file (under Drafts) with content, then moved it to the trash, then synced. It appeared in the Trashed Files folder (with ID "2139"), but not in folder-sync.plist.
- In Scrivener I moved two Untitled empty file to Trash (that had been outside Drafts), synced, and they disappeared from the external folder (not in Notes or Trashed Files (or Drafts)), though they were still in the Scrivener trash. The deleted items plist entry was still empty.
- I then emptied the Scrivener Trash, and after syncing the three IDs appeared in the plist file!
=> I thus had, after syncing, three IDs in the deleted items plist, none of which existed anymore in the Scrivener file, and only one of which existed in the external folder, and that one was in "Trashed Items".
- So I added a new, empty file. You do indeed reuse IDs, after syncing it was given the ID of the original file, "2139"! The plist was unchanged, and still had the three IDs in it, one of which was now a new file in Scrivener.
- Sure enough, on syncing, the new file appeared in the "Trashed Items" folder, even though it had not been moved to the Scrivener Trash or deleted. Each time I sync, it adds to the "Trashed Items" folder so:

Code: Select all

$ ls -1t */*2139*
Notes/266 Untitled -2139-.rtf
Trashed Files/266 Untitled -2139--2.rtf
Trashed Files/266 Untitled -2139--1.rtf
Trashed Files/266 Untitled -2139-.rtf
Trashed Files/0019 Testing -2139-.rtf


Since I know how to quash the symptoms, it is not urgent for me. Hopefully this helps you track the problem down.

[ajbuch]

PS. I deleted the ID "2139" file (moved to Trash and emptied Trash), and this time the deleted items list became empty again, as it should.

[DMaunder]

Searching for words highlights them in the editor but not in quicklook windows.

Not sure if this is a bug with the beta or just something that's not implemented but I just noticed it.

To reproduce: Search for any word, in the binder 3 finger quicklook or spacebar any document, no word is highlighted. Click document so it opens in an editor and word is highlighted.

[KB]

Hi,

Thanks for trying the beta. This isn't a bug - search operates on the main window, and search highlights aren't intended to affect QR panels.

All the best,
Keith

[DMaunder]

Hi,

Thanks for trying the beta. This isn't a bug - search operates on the main window, and search highlights aren't intended to affect QR panels.

All the best,
Keith

Sigh. It would be nice if they did, or at least have the option.

[robertdguthrie]

I don't auto-hide the inspector and binder in full screen, but I often do have one or the other turned off manually or in a saved layout. The previous behavior has been for those elements to slide in when I move the mouse cursor to the appropriate edge of the screen, but that no longer happens unless I have "Hide binder and inspector when entering full screen mode" ticked.

Is this intentional behavior? If so, is there some hidden option I can toggle to make them slide in even if I don't have them hidden automatically when entering full screen?

Build: 24052

[KB]

Yes, that's intentional behaviour. Many users don't like them sliding in all the time. There's no optional way of changing this, no.

[robertdguthrie]

I've been trying to live with this change, but I have to come back and say that my life has been ruined. Ruined!

In all seriousness, I do find being able to have the binder and/or the inspector slide in very handy without wanting them both to slide out of sight when I enter full screen mode (or when Scrivener automatically opens my last project which was in full screen when I quit). I can tweak the behavior to my liking by setting up my full screen project with the inspector showing, but the binder hidden, then visiting the preferences and telling it to "Hide Binder & Inspector when entering full screen". This allows me to have the binder slide into view, but keep the inspector visible. However, this means that I have to manually un-hide the inspector, which I want in full view at all times (and there was much wailing and gnashing of teeth).

Would it be possiblefor the behavior to be reversed for that option? Instead of automatically hiding the binder & inspector, the phrase would read "Slide hidden binder and/or inspector into view in full screen mode" ** and would behave accordingly. That way, when I quit Scrivener for the day (in full screen), and then launch it again tomorrow, the hidden Binder still slides in, but the not-hidden inspector stays put.

** Obviously, that sentence needs tweaking and mentioning of the screen edges.

[KB]

Oops, sorry Robert, I meant to reply and tell you that I'd split this into two options, so that now you can choose whether to hide the binder and inspector on entering full screen separately to whether the inspector and binder should slide in when hidden. So you can set it up how it used to be, and people who don't like the slide-in behaviour can turn it off. This is in place for the next beta.

All the best,
Keith

[robertdguthrie]

Oops, sorry Robert, I meant to reply and tell you that I'd split this into two options, so that now you can choose whether to hide the binder and inspector on entering full screen separately to whether the inspector and binder should slide in when hidden. So you can set it up how it used to be, and people who don't like the slide-in behaviour can turn it off. This is in place for the next beta.

All the best,
Keith

Hooray! Now my life is no longer in shambles! What a relief. Well, it won't be in shambles once you release the next beta. That will be coming presently, yes? *puppy dog eyes*

Thanks, really. This is a great solution.

[nom]

Oops, sorry Robert, I meant to reply and tell you that I'd split this into two options, so that now you can choose whether to hide the binder and inspector on entering full screen separately to whether the inspector and binder should slide in when hidden. So you can set it up how it used to be, and people who don't like the slide-in behaviour can turn it off. This is in place for the next beta.

All the best,
Keith

(Robert wasn't the only one)

[robertdguthrie]

Not sure if this is a Beta bug (don't have the release version handy), but I've noticed that when I quit scrivener in full-screen mode with a scrivenings session in the editor, and then re-load, it doesn't scroll to the cursor's position. I tested this recently, thinking that the cursor was also at the top of the scrivenings view, but when I move the cursor with my keyboard (or type anything), then the editor scrolls to where I was in the last session.

It seems that the correct behavior is almost there, except for it restoring the scroll position in the editor.

Settings which may be important:
I have the setting on for hiding the binder and inspector when going into full screen, which is triggered when I load my project.
When I quit Scrivener, I usually have the inspector un-hidden.
I have multiple empty documents below the one I'm working on, where I leave my cursor when exiting.
Right before closing the project, I often move forward in my document history to a single document (I record word count, location, and time for analysis later), then back through the history to where I was last working.

As a follow-up, I wanted to point out that the cursor pops up to the top of the document I was in if I switch to cork board or outline mode and then back without having done anything else in between the switching. It would be nice if the cursor position was remembered and scrolled to in the above situation as well as when switching viewing modes on the same selection of documents.

[DMaunder]

Project statistics is broken in the latest beta. Scrivener locks up and you have to force close.

8/10/13 11:27:38.738 PM WindowServer[102]: CGXSetWindowBackgroundBlurRadius: Invalid window 0xffffffff
8/10/13 11:27:38.752 PM WindowServer[102]: CGXSetWindowBackgroundBlurRadius: Invalid window 0xffffffff
8/10/13 11:27:44.000 PM kernel[0]: 13921.232378: osif_com_vap_event_handler vap delete event
8/10/13 11:27:44.000 PM kernel[0]: 13921.232386: deleteVap ****SYNC VAP DELETE SUCCESS
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextScaleCTM: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextSetFillColorWithColor: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextSetStrokeColorWithColor: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextGetCTM: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextGetDefaultUserSpaceToDeviceSpaceTransform: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextSaveGState: invalid context 0x0
8/10/13 11:29:47.831 PM Scrivener[2087]: CGContextConcatCTM: invalid context 0x0
8/10/13 11:29:47.840 PM Scrivener[2087]: CGContextDrawImage: invalid context 0x0
8/10/13 11:29:47.840 PM Scrivener[2087]: CGContextRestoreGState: invalid context 0x0
8/10/13 11:29:58.968 PM Scrivener[2087]: CGContextScaleCTM: invalid context 0x0
8/10/13 11:29:58.968 PM Scrivener[2087]: CGContextSetFillColorWithColor: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextSetStrokeColorWithColor: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextGetCTM: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextGetDefaultUserSpaceToDeviceSpaceTransform: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextSaveGState: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextConcatCTM: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextDrawImage: invalid context 0x0
8/10/13 11:29:58.969 PM Scrivener[2087]: CGContextRestoreGState: invalid context 0x0

[markusbern]

not bug ---- Thanks for the German translation