Structure Based Section Type Incorrect

[Julian_M1]

Bug or UI Infelicity?

As shown by the example below, it is possible for a binder item to not follow the Structure Based Assignment even when it say it is applied, if the parent item has a different “default” for subdocuments.

Two separate “Defaults” are being applied: for the item and the parent item.

Item B sets the “default” for Subdocuments to be “N/A”, But Item C says it is structure based. I believe it should have inherited its section type (from it’s parent’s subdocument default).

This confused me greatly and took a while to track down

[AmberV]

As shown by the example below, it is possible for a binder item to not follow the Structure Based Assignment even when it say it is applied, if the parent item has a different “default” for subdocuments.

I’m confused by this wording, as you seem to be saying you didn’t do something you did. Changing the subdocument default is a structure-based declaration. This feature would do nothing at all if it didn’t change the structural defaults, or if everything ignored it and went on using the project-wide structure.

What are you expecting this feature to do, maybe there is a better approach for what you’re looking for.

[Julian_M1]

TL;DR I do understand; I was suggesting that the SBA indication is unclear as it is. Two defaults is not meaningful to me. (One in Project Settings “Default Types by Structure” and one on the section type menu “Default Subdocument Type”).

It’s not a big deal for me now I know this, but having this info in the forum now might save someone else hours.

@AmberV

I’m confused by this wording, as you seem to be saying you didn’t do something you did.

LOL! Yes, of course you are right. This is tricky! Obviously a thing I set had the effect I described, and I do see that the structure declaration for the subdocument did what it was supposed to. No argument about that.

The point I was trying to make was that inspecting the “Structure Based Assignment” of the child item shows it as (oh dear, I fear I’m going to say it wrong again) “structure based” when in fact, its own “structure based” default, has been overridden by the “structure based” subdocument default option of it’s parent.

Yes, it is structure based, whichever way you look at it, but there’s nothing to tell the user which approach to structure based assignment is actually applied (Proj. Settings default, or the menu subdocument default), hence no way to tell what to expect in the output except by inspecting all parents of an item, which would seem contrary to the apparent intent.

If the “Section Type” of the child item had been* labelled as ~“inherited SBA” (and the drop down disabled for that item?), the issue of correctness would not have arisen.

NB /* “had been” – using this form of words to avoid “were to be” in order to avoid appearing to be agitating for a change outside of the Wishlist.

[kewms]

@Julian_M1

Yes, it is structure based, whichever way you look at it, but there’s nothing to tell the user which approach to structure based assignment is actually applied (Proj. Settings default, or the menu subdocument default), hence no way to tell what to expect in the output except by inspecting all parents of an item, which would seem contrary to the apparent intent.

Except that presumably the author intentionally assigned a different sub-document default to the parent and did so for a reason relevant to the structure of the project. That is, Scrivener is making the (perhaps misguided) assumption that the author knows what they’re doing.

To see what Section Type is actually assigned to a given document, look at either the Inspector or the Outline view. Scrivener will show the applicable Section Type there, italicized if it is due to an assigned default, not italicized if applied to that specific document manually.

[AmberV]

I think we’re on the same page here, this works a bit like cascading style sheets, if that’s a useful comparison for you, I don’t know, but hopefully so. The project has some basic definitions for how the outline should by understood, based on the disposition of the outline, but we can come along as say this part off the tree over here should have a different default understanding of what these things are. Normally items at this level would be “subsections”, but in this area they are “glossary entry”.

In the Outliner it prints “Glossary Entry”, in light grey, because it is inheriting that definition from somewhere up the chain—might be the immediate parent, but it might be higher as well, each definition cascades downward indefinitely.

If when you looked at the menu it said “Glossary Entry” with a tick by it, then that would be a different declaration from what we have. That would be the result of you having come along and selected that item and manually changing it. It would at that point be full opacity and printed in Roman in the outliner, too.

So printing that in the contextual menu would be misleading, it would say the wrong thing. It’s structure based, and can be proven so by moving the “Glossary Entry” item to a different area of the tree and watching it turn into a “Sub-Section”.

So again, I think we are all on the same page with this so far. I’m just reiterating to make sure.

While in that contextual menu you will also note that it says more than just that, it prints “Structure-Based (from ‘Folder Name’)”. So now you know why it is what it is, and where that declaration is coming from.

Granted in your case you used a sentence for a heading, so it doesn’t have space to print all that and cuts it off, but that’s where that info would be given at any rate.

[Julian_M1]

Just noticed sub-documents assigned section changing in the outline view.

My problem was I was looking at a folder.

I suspect we are on the same page again at last; thanks.