Allow documents to have child documents

[vkbo]

I am not entirely happy with the lack of distinction in the project tree between chapters and scenes. While you can create whatever tree structure you like with folders, it would be nice if documents were allowed to have other documents as child nodes.

Since it is the format of the first header of the document that determines what structural level a document is on, there can be no restriction on how documents are organised. Any document should be allowed to be a child document of another document. It would make it possible to sort scenes under chapters for instance, which is the main use case I can see.

Folders are still a neat feature as they can be used freely without affecting the compiled result. I personally use them to split the story up into acts, and to organise my project notes.

Technically, novelWriter doesn't care what item in the project is a child or parent of another item. The current rules are only enforced by the display widget of the project tree in that making a document the child of another document is blocked in the drag and drop feature. That is all. The core project code pretty much allows you to do whatever you want, so lifting some of these restrictions isn't particularly difficult.

I would like to hear some opinions on this. Would this be too confusing or messy? Thoughts, @jyhelle, @Ellipsine, @johnblommers, or anyone else?

[johnblommers]

The idea of lifting restrictions on the depth of a tree structure of folders and files has a good ring to it.

Personally I'm an H1 H2 H3 kind of writer where H1 is the title of the book, H2 is the title of the chapter and H3 is the title of the scene. novelWriter handles this kind of project very well.

But I can see some writers doing one huge novelWriter project consisting of a series: Book1 Book2 ... Bookn each containing Part1 Part2 and Part3 each of which contains chapters and scenes. novelWriter should handle this case as well.

[Ellipsine]

Hi, thank you for asking me :) I would appreciate this fearture, as it would render the project tree much more rational, without the need of using folders to render my books :

• Book I file

• Acte I file

• Chapter 1 file

  • Chapter 2 file -> Acte II file

  • Chapter 1 file

  • Chapter 2 file

• Book II file

  • And so one…

I could use it for my project notes as well. Right now I use Obsidian, especialy for my researches and the outlining pane which makes it easy to navigate through a big note, like character notes (Look, psychology, magic, trivia…). But children docs could be really convenient for notes.

[vkbo]

Personally I'm an H1 H2 H3 kind of writer where H1 is the title of the book, H2 is the title of the chapter and H3 is the title of the scene. novelWriter handles this kind of project very well.

That would not change. I'm merely suggesting adding the ability to put a scene file as a child of a chapter file visually in the project tree. You could put a chapter as the child of another chapter as well, which would make little sense. That's the downside of this feature: you could actually do that. This is why I'm a bit concerned that it may be potentially messy.

Regardless of structure, the text will still be processed from top to bottom from the project tree, and any "indentation" due to hierarchical organisation just ignored.

[vkbo]

Hi, thank you for asking me :) I would appreciate this fearture, as it would render the project tree much more rational, without the need of using folders to render my books :

The idea behind the way it currently works is that you should be able to write your story in terms of scenes, and then insert chapters later. That is why the scene and chapter files are on the same level so to speak. They are just breaks in the flow of scenes. Like I currently do in my own project:

+ Novel (Folder)
  + Act One (Folder)
    - Chapter One (File)
    - Scene 1 (File)
    - Scene 2 (File)
    - Chapter 2 (File)
    - Scene 3 (File)
    - Scene 4 (File)

With my proposed change you can still do this. But you can also do something like this:

+ Novel (Folder)
  + Act One (Folder)
    + Chapter One (File)
      - Scene 1 (File)
      - Scene 2 (File)
    + Chapter 2 (File)
      - Scene 3 (File)
      - Scene 4 (File)

This is more natural in many ways, but the Novel view of the project tree already provides such a structured view, so it may be somewhat redundant. You can actually work mainly with the main tree in Novel view and edit your text in fewer files and then split them later. The Novel view will display the internal structure of your files instead of the files themselves.

I could use it for my project notes as well. Right now I use Obsidian, especialy for my researches and the outlining pane which makes it easy to navigate through a big note, like character notes (Look, psychology, magic, trivia…). But children docs could be really convenient for notes.

Absolutely. This is my other use case. Especially for my world building notes having additional documents below other documents is handy.

As for the Outline tab in novelWriter, I plan to add detailed views for notes as well soon. Similar to what currently exists for the story itself. Actually, there are probably a bunch of improvements that can be made to this feature that would help the writer structure the novel. I plan to get on this side of things for release 1.8, after I do a revamp if the Build Tool in 1.7.

On the topic of multiple novels, I'm working on allowing multiple root (top level) folders of the same type now. Which means you could for instance add three novel folders for three novels in a trilogy if you wish. The current restriction is another thing that is mainly only enforced on the GUI side of things, and not on how the project data is handled. So it's fairly easy to remove the restriction. The only issue is that the novel story builder will combine the novel root folders into one, so I need to make some changes on that end to keep them separate.

[vkbo]

I just had a thought. Perhaps it would make more sense if the user actively allowed certain documents to have child documents by flipping a switch on certain files. It may make it a bit simpler to control the flow when using the drag and drop feature. Perhaps with a slightly different icon to indicate it. I could sumper-impose a folder icon on the document icon for instance.

To make it more user-friendly, if you drop a document on top of another document, a dialog box could ask if you want to allow the drop target to have child documents.

I have to test this and see how it works as a workflow. Adding an additional step would make it easier to maintain the current functionality if one prefers that over the one proposed here.

[Ellipsine]

I understood the way hierarchie would work but the github editor is just a pain without tab, I'm sorry T_T I would be great, even if I don't work with scene structure at all, I totaly see the potential of this kind of structure for my own work.

On the topic of multiple novels, I'm working on allowing multiple root (top level) folders of the same type now. Which means you could for instance add three novel folders for three novels in a trilogy if you wish. The current restriction is another thing that is mainly only enforced on the GUI side of things, and not on how the project data is handled. So it's fairly easy to remove the restriction. The only issue is that the novel story builder will combine the novel root folders into one, so I need to make some changes on that end to keep them separate.

I remember we talked about this and it is still a wonderfull idea :) . So we would have :

• Main projects component -root - with a refracted export tool
• Inside a component root, the ability to add children documents to a file, with a little pop up maybe to warn the user (that sounds great. I would add keyboard hotkeys to manipulate the tree as well)
• a possibilty to outline notes as well

For the outlining pane, that how I use it and find it really, really handy :

As soon as I click on a title from the right panel, it is like a superpower : I teleport myself on it (and Medea is not happy to be featured here) :

That tool allows to me to add many subparts in longer notes without loosing time scrolling.

[vkbo]

That is more of a document (note) outline of the headings inside the file. I've thought a bit about that too. It would indeed be quite useful for individual notes that are long. It's an old idea to add this, and it's been discussed before.

I'm not sure where in the GUI it would make sense to add this. I've been thinking about having it as either a third tab on the project tree, or as a collapsible panel below it.

I'm working on a parallell app to novelWriter written from scratch with a different design philosophy. Mostly because I want to play with a different approach to see if that works better. One thing I've done in that app that I want to do in novelWriter as well is to add a vertical toolbar on the left edge of the main GUI and move all the current tabs to that location. It is sort of similar to what a lot of GUI apps do these days, like Slack, Teams, VS Code, etc.

[Ellipsine]

Yes, it is !  I was imprecise in my formulation : it is an outline of the headings inside the file, indeed :)

You could create a third tab at the left "doc outline", just like the tree documents or the novel outlining, or a right "doc outline" tab that would pop up at the right of the document ?

One thing I've done in that app that I want to do in novelWriter as well is to add a vertical toolbar on the left edge of the main GUI and move all the current tabs to that location. It is sort of similar to what a lot of GUI apps do these days, like Slack, Teams, VS Code, etc.

Are you talking about the dock thing at the very left edge of the screen ? It would be handy and helps you to suppress tabs on the main GUI. Everyting would appears at the left after clicking on the button : the doc tree, the doc outlining, the novel outlining, the main editor view, the outliner novel view. I think it can be a good idea from my perspective.

[vkbo]

You could create a third tab at the left "doc outline", just like the tree documents or the novel outlining, or a right "doc outline" tab that would pop up at the right of the document ?

I've thought about this too. My main concern is that it will take up a lot of space on for instance laptop screens. Especially if you have the editor and viewer up, with an outline each. That will effectively split the GUI in five columns. I could combine the outline for the editor and the viewer into a single column, which would make it four. But I think it may still be too much for a laptop screen.

Are you talking about the dock thing at the very left edge of the screen ? It would be handy and helps you to suppress tabs on the main GUI. Everyting would appears at the left after clicking on the button : the doc tree, the doc outlining, the novel outlining, the main editor view, the outliner novel view. I think it can be a good idea from my perspective.

Yeah, it would be a sort of dock bar, or toolbar, or something like that with a bunch of buttons to change the main window layout to for instance one of the following:

• Explorer View = Project Tree + Editor [+ Viewer]
• Story View = Novel Tree + Editor [+ Viewer]
• Document View = Document Outline + Editor [+ Viewer]
• Story Outline
• Notes Overview

I could also add the focus mode toggle button to this toolbar and make it one of the views. It would make sense.

I will move this to a separate issue ticket. I think this will be a nice improvement to the user interface.

[vkbo]

I've made the change to allow documents to have other documents below them. Check #1047 for a full list of changes.

I also chose to allow drag and drop of documents and folders with other documents or folders below them. This means there are almost no restrictions left on what you can do in the project tree. The only remaining restriction is that you cannot drag and drop root folders.