Scrivener 1.1 (1.055b) Public Beta - new and updated (AGAIN)

ga
garywade
Posts: 9
Joined: Sat Jul 21, 2007 4:30 pm
Location: Orange County, CA
Contact:

Sat Jul 21, 2007 5:32 pm Post

For the margins preferences, the units are always in pixels, but the ruler can change its units to inches or centimeters, and these units, even if they relate to different things, should similarly be configurable to different units, as not everyone knows that 72 pixels equal an inch.

ga
garywade
Posts: 9
Joined: Sat Jul 21, 2007 4:30 pm
Location: Orange County, CA
Contact:

Sat Jul 21, 2007 5:35 pm Post

When selecting a folder or a file, only the backspace deletes the items rather than allowing the forward delete key also. Also, the clear key doesn't do any deleting either. When trying the escape key, it opens the name of the file/folder to be edited, something I would never expect.

User avatar
KB
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Sat Jul 21, 2007 7:32 pm Post

Hi Gary,

Whilst I appreciate your feedback, please try not to flood the forum with multiple posts where they could all be put in one post. Also, most of your posts have nothing to do with this topic as they are not beta-specific; most are the result of unfamiliarity with the application and are well-documented or explained in the Tutorial or Help file - please do refer to them.

Posted: 21 Jul 2007 04:38 pm Post subject: Version missing in the Finder
The CFBundleGetInfoString and CFBundleShortVersionString properties are missing from your Info.plist, keeping the Finder from showing the version in the Get Info window. Seen on Mac OS X 10.4.10, PPC.


Please see:

http://www.cocoabuilder.com/archive/mes ... 1/2/149287

Scrivener stores the version under CFBundleVersion exactly as it should do given that it is a Tiger and above app; doing a Get Info on most apps on Tiger reveals that version info is not displayed, so I don't think this is a "problem" specific to Scrivener.

If I do a highlight of text in the edit window, move the cursor into another field like the synopsis section, and do an Undo at that time, the highlighted text is not undone. I have to move the cursor back to the edit window and then do undo for the highlight to work.

Also, I found that if I click on the auto-generate button of the Synopsis section while my text cursor is in the edit field, undo doesn't work for the auto-generate until I put my cursor in the Synopsis section.


This is a well-documented result of the fact that the main text has a different undo stack than the binder and inspector. It is not a bug, though it takes a little getting used to. Please refer to "Undo/Redo" in the Help file (just search for "Undo").

The help tag for the toggle split control uses the Windows term "alt" rather than the Mac term "option" for the related modifier key. Although some Mac keyboards do have "alt" on them, not all do.


Well, all British ones do and I'm a Brit. :) Americans bullied me into changing the term in the Help file, so I'll change it in the app too to keep things consistent.

During the first time running Scrivener (you have to duplicate this by quitting and starting back up), when you choose Export Manuscript, choose the Text Options panel and then the Formatting panel, the check boxes for "Convert em-dashes to double hyphens" and "Convert ellipses to triple periods" shift visually to the left briefly in conjunction with the surrounding group box.


I cannot reproduce this, but given that there is no animation or movement built in here at all, it sounds like a minor drawing bug in the OS rather than in Scrivener itself.

Below the sliders used in the preference panels, there should be some numeric feedback so a user can tell if they hit the same value they were hoping for, possibly to the right in a field or below it with tick marks.


This is really a matter of opinion. See the slider in iPhoto, for instance - no feedback. Besides which, you can hit "Apply" to see if it is what you want.

For the margins preferences, the units are always in pixels, but the ruler can change its units to inches or centimeters, and these units, even if they relate to different things, should similarly be configurable to different units, as not everyone knows that 72 pixels equal an inch.


Don't blame me for the way the rulers work; I just use the standard Apple methods. Feel free to ask Apple to fix this:

bugreport.apple.com

When selecting a folder or a file, only the backspace deletes the items rather than allowing the forward delete key also. Also, the clear key doesn't do any deleting either. When trying the escape key, it opens the name of the file/folder to be edited, something I would never expect.


Escape is used for this to make those familiar with outliners such as OmniOutliner feel comfortable. If you never expected it, why try it? Well, now at least you know. :) As for the forward delete, you are right about that - I've added it for the next version.

All the best,
Keith

User avatar
AmberV
Posts: 20613
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Sat Jul 21, 2007 8:29 pm Post

garywade wrote:For the margins preferences, the units are always in pixels, but the ruler can change its units to inches or centimeters, and these units, even if they relate to different things, should similarly be configurable to different units, as not everyone knows that 72 pixels equal an inch.


That isn't even universally true. It was a good rule of thumb prior to 2000, but with the proliferation of high, and ultra-high resolution flat panel displays in laptops and high-end desktop models, an inch can often contain a lot more than 72 ppi. Some prototype models are all the way up to 300ppi, which is getting awfully close to laser jet quality.

So the problem that arises is: Would the user, presented with the option to use metric or standard measurements for their margins, expect to see literal lengths on their display, or print setting lengths? The former would require Scrivener to get the current display's PPI (which may or may not be easy), and do the math to generate the number of pixels required to fill out the designated length. The latter would produce results less than the full length (much less for some people, like those on those new MacBook Pros), requiring a certain amount of guesswork for people who are not acquanted with PPI, and the maths required to calculate to standard ruler lengths. Since most people will be guessing anyway, might as well just use pixels which is far easier.

Finally, not everyone likes a big fat margin. Some may only want five or ten pixels between the text and the window border. Are they going to have to input tiny fractions?
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

ga
garywade
Posts: 9
Joined: Sat Jul 21, 2007 4:30 pm
Location: Orange County, CA
Contact:

Sat Jul 21, 2007 8:54 pm Post

Since I'm testing your beta product, it make sense to me these are beta issues. If these exist in prior versions, you should consider them priority now.

Since 10.4.10 == Tiger and all Apple's products (see iTunes, QT Player, etc.) provide all three keys, you should consider that the information you are viewing isn't correct. If I cannot tell what version an application is without launching it, this tells me the developer didn't consider the basics needed to produce a finished Mac OS X product.

Also, no professional application requires separate undo buffers where the user must choose one field over another to undo their previous operation; see any successful commercial application for examples. Commercial software developers would consider this a bug.

Perhaps the redrawing/invalidating issue on the export dialog only shows up using a slower machine; try using Quartz Debug to see if you can reproduce it with it active. Since it only happens the first time, it appears you're not initializing something correctly, but once the panel comes up, that apparent value gets initialized, keeping it from happening any more while the application is up.

Perhaps it's a matter of opinion to see actual results without having to apply them first and then have to reapply them just to get that little difference between "23" and "24", but most people prefer to know what a slider's value is before applying changes and then having to go back and redo things.

So, are you telling me that Apple produced the text "px" on your panel and that they are the ones who will fix this? The disparity between "px" and "cm" and "inches" is what I'm talking about. If you open up Photoshop, you'll see that you can see any measurement in inches, centimeters, and pixels, rather than forcing you to use two different measurement methods if you are only comfortable with one.

Like most everyone else, I use the escape key as a means of deleting a value, along with its character/keycode sister Clear. To cause an edit field to open up when typing that character is highly unexpected. If I ever start using OmniOutliner and it does this as you say it does, I'll report this unexpected behavior to them, too.

ga
garywade
Posts: 9
Joined: Sat Jul 21, 2007 4:30 pm
Location: Orange County, CA
Contact:

Sat Jul 21, 2007 9:09 pm Post

Apparently you missed my point; this has nothing to do with 72 as a magic number for screens and printers (consider Leopard's ability to break that barrier) as writers don't deal with pixels but inches or centimeters (without foreknowledge, only my 25-year-old pica pole gives me some visual sense of the comparison between inches, centimeters, and pixels), and since the hardcoded presence of "px" implies the user must do that calculation themselves, the UI produces a disconnect for the average writer.

User avatar
KB
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Sat Jul 21, 2007 9:18 pm Post

Oh, I see which part you mean now - you mean the margin boxes. That has nothing to do with anything printed; it is purely a screen thing. I think that nowadays, most computer users have some concept of pixels. Mind you, points might be more accurate in the future. But cm and inches have no real place there just yet.
Best,
Keith

bg
bgordon
Posts: 9
Joined: Fri May 18, 2007 6:37 pm

Mon Jul 23, 2007 3:05 am Post

I have encountered an odd and growing discrepancy between the word count in the footer view and in the selection pane of the statistics panel. I have a document with just under 2800 words - no annotations or footnotes - but the selection statistics panel only indicates about 1900 words. I have been working on this document over the past couple of days, and I have found that the size of the discepancy seems to be growing. The word counts in both the header view and the statistics panel both keep on increasing, its just that they are failing more and more out of line. I'm pretty sure that the footer view count is accurate, so it would seem to be something revolving around the statistics panel?

User avatar
AmberV
Posts: 20613
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Mon Jul 23, 2007 4:09 am Post

I just tested a few of my projects and they are all 100% synchronised. If I do a full Edit Scrivenings on the entire draft, the result matches that in the project stats panel (both project stats and selection stats match each other if I select Draft and turn on sub-folder counting). What options do you have selected in the Options tab? If you have it set to exportable only, and are putting content into folders, that might explain a count discrepency, as folders default to not exporting.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
juh
Posts: 156
Joined: Fri Dec 01, 2006 11:43 am
Location: Germany
Contact:

Mon Jul 23, 2007 10:50 am Post

In Project Statistics "Count only documents marked for export" does not work for me. I checked this but still the whole bunch in draft is counted.

BTW: Another question. Can we post bug reports to the current beta outside this thread, which is so long that it is impossible to search for related bug reports before posting them.

User avatar
KB
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Jul 23, 2007 2:50 pm Post

juh wrote:In Project Statistics "Count only documents marked for export" does not work for me. I checked this but still the whole bunch in draft is counted.


I can't recreate this. Are you sure that you have anything in your Draft that is not marked for export, and if so, if those documents marked not to export have any text in them?

BTW: Another question. Can we post bug reports to the current beta outside this thread, which is so long that it is impossible to search for related bug reports before posting them.


No, please keep them to this thread, otherwise the rest of the forum gets confused. Just post away on this thread and don't worry too much about whether it's been posted before. A new 1.1 beta is coming shortly and following that 1.1 will be hot on its heels. :)

Best,
Keith

bg
bgordon
Posts: 9
Joined: Fri May 18, 2007 6:37 pm

Mon Jul 23, 2007 7:22 pm Post

AmberV,

The document is just a simple text file, there are no sub-documents and no folders within which it is embedded. The document is set up to be exported in the inspector pane, and in terms of options I have set it up to count all documents and to exclude annotations (of which there are none).

This morning when I did a word count, the selection statistics actually fell by about 600 words, even though I had added a couple of hundred new words to the file before I viewed the statistics. However, and this is the interesting part, when I selected a couple of adjacent documents and then used the edit scrivenings function (which I have not previously used for this project yet), the word count between the footer and the statistics panel suddenly came back into sync. After that, I went back to looking just at the one document alone and after adding or subtracting a couple of words and re-examining the statistics panel, the two numbers seemed to be staying in sync. Weird.

User avatar
KB
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Jul 23, 2007 7:36 pm Post

bgordon - are you sure that the selection in the binder was exactly the document you were expecting to be counted? The "selection" stats in Project Statistics refer to documents selected in the binder (or in the outliner or corkboard, depending on what has the focus - the binder if none have the focus).

Best,
Keith

bg
bgordon
Posts: 9
Joined: Fri May 18, 2007 6:37 pm

Mon Jul 23, 2007 7:49 pm Post

Keith,

Now I'm not sure. The document that I was intending to count was locked into place in one of two split screens, so while I was working in the locked document it may have been de-selected from the binder. Probably just a case of user error. :oops:

User avatar
KB
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Jul 23, 2007 7:53 pm Post

I like user error - it takes no work on my part. :) I'll assume that was the case unless it crops up again (makes my life easier).
Best,
Keith