Project Title, Abbreviated Title, etc. Why aren't these editable in Project Settings?

A project has a Title and an Abbreviated Title and other key project specific author selected attributes regardless of whether or not it is ever compiled. So why is the only place one can edit these attributes in buried in Compile? I get that one might want in some rare circumstances, append or adjust the title to fit a particular compile situation, but that should be an adjustment from the default. For that to happen, a default must exist for the project. No?

Those circumstances are not “rare.” They occur every time someone has more than one output document in a single project: a journalist writing weekly articles, a writer collecting short stories, a poet assembling one or more collections…

Moreover, the output document is the only place where these variables are ever needed. Nothing else in Scrivener cares who the author is or what the title of the output document is.

1 Like

Yes but the default title and abbreviated subtitle should only have to be entered once, should always be available as reference and for modification where needed in any specific Compile. Unfortunately there is no way to set a Project title and abbreviated title so these have to be remembered and retyped every time one wants to perform a Compile. Author’s are not as concerned about what Scrivener needs than they are about what they need to make their writing experience more natural and efficient.

As example, lets look at Charles Darwin’s little book:

On The Origin Of Species By Means Of Natural Selection , Or The Preservation Of Favoured Races In The Struggle For Life

If poor Chucky D had to rewrite that title every time he went to compile, well you see what I mean. Not only that but Compile does not remember titles from previous Compiles of the same project. Even that would be better.

PS. Good suggestions don’t ALWAYS have to be attacked.

I don’t think for a moment that your suggestion was attacked, merely the reason for it not being so, explained.

Darwin would not have had to type the name more than once as he went to compile.

The example @kewms gave is one that occurs frequently for me. You start a book series and write them all in the one project, character names etc carrying over. When it comes time to compile the individual book as I complete it, I add the title of that book in the series. Easy!

You do realize you don’t have to actually compile to set the names?

Go to compile, select the tag and enter the names, then Option key changes the Compile button to save.

Tap that, close the window and it’s all there and will be every time you compile.

As I (and no doubt many others) often only have a working title as I write an individual book as a project, the scenario of setting a name later on, or when I go to compile involves no extra work for me.

3 Likes

If poor Chucky D had to rewrite that title every time he went to compile, well you see what I mean. Not only that but Compile does not remember titles from previous Compiles of the same project. Even that would be better.

You seem to be implying that the problem is where the fields are, but that seems to be based upon a misconception that anything you set or do in compile is lost after you compile which is clearly a bug.

Can you reproduce that in a test project, created from the Blank starter, saved to a stable location, such as the internal drive in an area that isn’t volatile, like an iCloud synced area?

I cannot, nor can I think of a way to force it to happen. Here is my checklist:

  1. Create a new blank project, open compile and flip to the metadata tab.

  2. Enter “Chucky D” into the Author field and “On The Preservation of Data” in the Title field.

  3. Hold Option and click the Save button, closing the window.

  4. In Terminal

    $ cd ~/temp/save_test.scriv/Settings
    $ grep -A 3 'Preservation' compile.xml
    

    Result:

    <ProjectTitle>On the Preservation of Fields</ProjectTitle>
    <Authors>
        <Author>Chucky D</Author>
    </Authors>
    
  5. And of course, data on the disk doesn’t necessarily mean the UI won’t malfunction when trying to load it. So I go back to Scrivener, load Compile, and look at the metadata fields. All is well.

So what do I need to do differently to see a scenario where compile erases metadata every time I compile, and are there any other symptoms that might imply a broader loss of settings, such as checkboxes reverting, the compile group always resetting to Draft, and section layouts always having to be manually reassigned?

1 Like

Perhaps it is confusion re: needing to hit Option to save?

Maybe the buttons could always be displayed?: Cancel, Save, and Compile? Clicking Save would save the metadata and compile settings but exit the compile window, whereas hitting Compile would proceed with the compile step.

But compiling always saves (or it should). The save button is only convenient if you just want to pop in and change something quickly, like I did here.

1 Like

Yes, I know. But it may be part of the confusion for the original poster (as long as there is no bug causing deletion of the settings). What I mean is that new users will see that modal dialog and see Cancel or Compile. They expect that hitting Cancel will, well, cancel everything they have done and revert to the previous state. And if they don’t want to proceed through with Compile, then the they may feel stuck without an option to simply update/save settings. The option button to switch to the Save button is not easily discoverable. So, it may be simpler and clearer to have the Save button always visible.

I don’t disagree with that, but it’s practically a tradition at this point that the compile dialogue has a hidden save feature. :laughing:

3 Likes