Allow for file arborescence
Popolechien opened this issue · 9 comments
Ideally the content should not be a bunch of files but we should have the ability to deal with subfolders
Well nautilus's spec was “a bunch of files as a ZIM” 😉
I agree this would be a lot better for large collections. This would require a UI do-over which would be welcome as the current one is very basic.
I agree this would be nice, but I would just like to point out that no matter how fancy the UI becomes, we shouldn't forget the basics of listing all the final documents in the ZIM's title index, so that the documents can be found by using native search in a client, and the ZIM can still be accessed by users who cannot run JavaScript (and so cannot run the custom UI). The associated issue is #42.
I'm not super convinced that arborescent view would be the best. Before moving on this I would like to assess this approach based on real problematic use cases.
@kelson42 zim-requests/issues/469 is probably a good use case. What started as 5-6 potential zim files (had arborescence been available) ends up being 53 separate zim files because otherwise there would simply be too much content to parse.
Same thing with https://library.kiwix.org/zimgit-post-disaster_en which I ended up breaking down into medical, food, and other subsets.
@Popolechien How would look like the arborescence for these examples.
Nothing fancy - clicking on a folder icon would open up a new page/list.
How many items? How deeps? Maybe a simple tag system is better!
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.