Independence of graph name from folder structure and reduced clutter

I believe that basing graph names on its parent directory name while there is no way to override this behavior by supplementing your own custom name is a very flawed concept.

It’s easy to imagine that some people might want to organize their projects with structure like HOME/projects/PROJECT_NAME/. However, doing so will clutter project directory with 3 new folders created by Logseq, which decreases clarity and slows down navigation if user keeps some other files or documents related to this project in the same folder.

Above issue can be easily mitigated by simply adding extra folder containing Logseq files within project directory, and the most logical solution here would be creating a new directory like HOME/projects/PROJECT_NAME/logseq. However, this causes yet another issue where now your graph is named after it’s parent directory, which not only looks awkward but can also lead to some minor confusion for users who would like to use Logseq for more than one project. For example, creating a structure like HOME/projects/PROJECT_A/logseq and HOME/projects/PROJECT_B/logseq would cause both projects to be displayed as just “logseq”.

The only reason why this issue is rather minor, is thanks to the fact that graph switcher shows you the name of the grandparent directory, turning it into just a slight inconvenience paired with awkward naming scheme, since at this point the “/logseq” part of the name wouldn’t even be needed.

For those reasons I suggest:

  1. Allow users to override graph names, ideally as early as during graph new creation. Current naming behavior should serve as fallback in case when user didn’t specify any other name.

  2. I believe it’s fair to claim that in modern user experience it’s often assumed by the user that unless all data is contained within a single file, application will create a new container folder for those data as its default behavior. I am aware that instructions inform you about this behavior, but I don’t think there is any valid excuse for going against what would be the more intuitive solution in this case.