Zim-desktop-wiki: Alternative filesystem layout for notebook using README files per folder

[jaap-karssenberg]

Current layout uses

• Page.txt
• Page/

Alternative would be

• Page/README.txt

Would be a notebook option that can be choosen when initializing.

Advanced version would be to use "page.txt" as long as no files are attached but convert to "README.txt" when folder is created.

[ecodiv]

I like this idea, it would result in clearer organization of folders and files. Would there be an option to convert existing Zim notebooks to this new layout?

[jaap-karssenberg]

Converting would probably be done with a special script.

[Elm7]

Hi, would be more easy to follow folders structures indeed, but why use README.txt instead of keeping the Page.txt name (same text filename as the folder name, because the "folder text" is not necessarily a "readme first" text) ?
Or maybe having it as PAGE.txt with upper case to identify it, if this is the need ?

[Osndok]

It sounds like @Elm7 is advocating either:

• Page/Page.txt (which implies that a page cannot have a child of it's own name 👎 ), or
• Page/PAGE.txt 👎

...and having a 'variable' name (that changes with the parent's name) could cause more unforeseen issues than using a constant... such as if/when directories are manually moved about, or rendered without knowing the parent directories name (like via a symlink).

I think the current layout is acceptable, and I don't really like any of these alternatives yet:

• Page/README.txt 👎

If we are going to change it, I would like to point out that the "*.txt" ending is technically incorrect b/c it is not a text file. It has http-like headers, and a semi-well defined format (that if you get wrong could result in a parse error). It also has caused problems when true TXT files are attached, that they can appear as pages.

What about something like:

• Page/index.zim
• Page/wiki.zim

Or to further separate it from nearby files:

• Page/_wiki.zim
• Page/_zim
• Page/_index.zim

Advanced version would be to use "page.txt" as long as no files are attached but convert to "README.txt" when folder is created.

And if they both exist? ... "one authoritative path" is far easier than two... especially if people want to extend zim logic for other purposes... you'd just be asking for trouble! :)

[zimdoug]

For what it's worth, the original feature request (by me) was here:
https://bugs.launchpad.net/zim/+bug/1607703

And a few related issues discussed including the .txt file issue. I'm definitely for not using .txt and even README.txt was really meant as a way to relate the concept. Although .txt could still work if it's restricted to mynote/zim.txt

The goal of this restructure was to allow zim to:
a) live well alongside any normal directory tree without causing too much clutter or confusion for people not familiar with zim.
b) Zim should be able to browse any file tree. Zim shows "attachments" as it is, and if the text file is missing it can just show a blank stub ready to edit. And it need not prevent browsing lower levels of the tree as it has done in the past.
c) Maybe ease moving and relocating. If the text file names are the same, like just .zimtext (should they be hidden?) and someone renames the folder, they don't get broken. Also by having them inside the folder, if the folder moves, they don't get disassociated.

Obviously c has issues anyway because internal links will get broken if things are renamed or moved. You could imagine using UUID for links internally, but that breaks ease of hand editing the mark-up. I could imagine zim finding any new [[pagename]] and turning changing it to [[pagename,UUID]] (or some similar syntax). It would also need to find any [[wrong-pagename-for-UUID,UUID]] and clean it to [[correct-page-name,UUID]] so that users could still both add links by hand , and understand links by eye, but hand editing an old link might result in confusion. For the traditional part of the link you could keep it relative if it started relative or absolute if it started absolute. Also this all requires that everything stays inside some top-level directory where zim can find it. That's ok.

Ideally zim would be my file browser. I want to be able to add linked notes to my work. Very often I have a bunch of files that serve a purpose and I want to be able to document that. It's not that I have a bunch of notes and I want to attach a few files, but both happen and one evolves into the other. Zim is so close to doing all this. I haven't followed recent changes though.

Personally I'd skip the "advanced" version above. Osndok is dead on. It adds complication and is based on the premise that the note comes first, and the attachments later, which isn't necessarily true. And even then, if you already have toplevel/mynote/zimtext.zim it's intiutive (for both zim and non-zim users) to add files to that folder from outside zim. If you just have toplevel/mynote.zim, it's not. You should first at least make a directory with a matching name at minimum (assuming zim will clean up). It doesn't fit natural filesystem usage. Basically, it adds complication and confusion needlessly.

I think this model would allow people to push zim into shared workspaces and for it to gain much more use. But the whole thing is definitely some real work.

[zimdoug]

I believe I saw another discussion of this issue here that seemed to miss the point. Maybe I'm confused, or can't find it now. Anyway, this one seems on target in my opinion.