Browsing user files: display the tree collapsed & load files only if parent folder clicked?

[slrslr]

Hello,

i have tried to search the file i am sharing (global all users search). I have clicked myself and then the button to display all shared files.

1) There is too many shared files and it seems that sub-directories are expanded showing all files inside them as these are loaded. And when i click some directory to close it, it is quickly auto-expanded again as new files are loaded. This prevents effectively browsing other user library (until everything is loaded. means 1+ hour for several hundreds of thousand files).

IDEA: Ideal would be to display everything collapsed by default (showing only root directories)

2) Also if there is hundreds of thousand items, the process of loading all the files is slow and possibly majority of content is of no interest of the user. So ideal would be if it preload only parent folders and then only content of particular sub-folder user will click. Or if it will preload only limited number of files in first level directories etc.

[zlatinb]

Re 1: I agree the auto-expansion isn't working very well as the tree is being loaded. I might get rid of it altogether.

Re 2: Theoretically this is doable, but it would be a very big change that impacts everything - the network protocol, the core code and the UI representation. Also it means the Table view of the shared files will need to be removed because it's not compatible with opening folders. Also it would not be very smooth experience because the lag over I2P can be quite bad. To make it work and be efficient, there would have to be automatic pre-loading in the background which is even more complicated.

I don't want to make any promises, but I'm not saying no. It would be a great feature to have, I just think the complexity is so great that I would have to work on nothing else for an entire release cycle, maybe more.

[someguy2013]

"IDEA: Ideal would be to display everything collapsed by default (showing only root directories)"

I agree with that idea. I suggested the same thing in #65, point #3.

I think the search tab's "browse files" was probably based upon the same search tab's display of search hits. But, I think "browse files" would be more intuitive if it looked like a ftp client gui. (Start at the top with the high-level, concise view. The person browsing can choose which branch to expand, see deeper.).

Browsing the sharer's directory structure seems to replace (or supplement) the collections tab & search>browse collections. There can be a "collection" inherent in the shared directory structure. Each subdir can be a collection (and sub-collection within collection.). Symbolic links can make it easier for the sharer to create/organize this "collection" view if the actual shared content is all over the disk.

So, I think Searches>Browse Files should present the top level (like Browse Collections does), and let the shared directory structure speak for itself. (A "collapse/expand ALL" toggle could be offered. I would default to collapsed. Let the browsing visitor expand all if they wish. Otherwise, the visitor can expand individual folders.).

To me, the value of browsing the sharer's structure is the "collection" functionality built into how the sharer chooses to organize what their sharing. So, if it defaults to ALL expanded, then that obscures the organization. (If it defaulted to all collapsed, the benefit of organizing the shared items becomes more evident with each "browse files" impression. I think it would help people "do the right thing" compared to default "everything" view.

Honestly, I think the "collections" functionality isn't intuitive and could be replaced by this cooperation between "Searches>browse files" and the sharer's choice of organizing their shared files into directory structures. Maybe it's just me. But, "collections" seems like a long way to do what can be done in a more 1-to-1 mapping at the shared level. I would replace "Collections>create collection" with "Manage Shared Structure" and give the sharer an interface to create symlinks. (I.e., if creating a meaningful shared structure, particularly with symlinks, is too complicated for muwire users, then offer a front end to give them the tools to do it. Instead of tools to do the same thing in something called a "collection." Guide the sharer to maintain their collection on their disk, not within something internal to muwire. That UI could educate the user how to do this at the command line for their OS? Training wheels for what they can do themselves.).

I wonder if there are any stats about how much "Collections" are defined/used? Maybe it's too much in use to "replace" it as I suggest. But, if not... I think keeping the "view" of this on the user's disk would be simpler, more intuitive. The "Searches>browse files" is kind of makes its adjacent "browse collections" less intuitive (it already was unintuitive to me).

Also, "Searches>browse files" might not be the most intuitive. I think of it more as "browse shared?" It's not just files, it's the structure that (ideally) would be the map to the files, locating what's interesting. ("Browse directory?" "Browse member?"). "Browse files" sounds flat, and the way everything's shown expanded gives it that flat impression too. I think the real value of this feature is the organization (and helping sharers see the potential for that). But, I think the more that becomes seen/recognized, the less value "Collections" have?

[zlatinb]

You make several points, I'll try to address them individually:

• tree collapsed by default
• replacing collections functionality with browse
• tools for editing the library

It is trivial to add a GUI setting whether to display the tree collapsed or expanded by default. Also adding a right-click option to collapse/expand is easy too. But fetching on demand is very difficult as described in my comment above.

I don't have stats on how popular the collections functionality is, but I know some people use it. It was implemented before the showing of paths in search results and for a while it was the only way to associate different files together. It still achieves that purpose without writing outside .config/MuWire.

Which leads us to the topic of editing the library - my position from the beginning has been that for variety of reasons MuWire should only write in its settings directory. (I know some users mount their library read-only before trying MuWire, which is a prudent thing to do.) Creating tools to edit the library is inherently risky, and I'm reluctant to do it myself.

[someguy2013]

my position from the beginning has been that for variety of reasons MuWire should only write in its settings directory.

I would think of "tools for editing the shared library (i.e., 'collections on the disk')" as giving the user a front-end for them to edit their own shared structure. You wouldn't be operating on the user's non-settings disk yourself. You'd just give an interface to manage the shared structure via gui. That's the user doing it, not you. (It's not like muwire will occasionally "oh, I think I'll write this outside the settings directory." You'd still be locked into that, unless the user straps themselves into the gui, and says "make a directory here. Symbolically link this here." You'd just make that input happen.).

I'm not trying to convince you. I just see another way that could be reasonbable, I think. "Collections" can be done with symlinks. It seems clean and consistent (with "browse user"). If people using "collections" were steered to creating that structure on disk, I think it would be better than maintaining both ways to the same thing?

Maybe "collections" isn't the same thing as managing a shared structure(s)? Maybe "collections" implies more than mere organization? I might have a lot of shared structure that doesn't add up to a "collection?" And then some things are collections (and collections within collections?). Like, I might share my /util directory. That's one thing compared to my Joni Mitchell anthology. The latter would be a collection.

Maybe "collection" is metadata to the structure of the shared files? Maybe a directory should be markable "collection?" (not merely "organization" implied in the directory structures?). If marked, it's displayed differently in "browse user?" Maybe a toggle to say "show only collections?"

I'm just thinking out loud. Something seems duplicative between browse user and collections. (I might want to mark one of my shared structures a collection without having to go into MuWire's "make a collection" interface, and people finding it a different way than the more basic ftp'ish "browse user" way.).

[someguy2013]

I wrote:

Maybe "collection" is metadata to the structure of the shared files? Maybe a directory should be markable "collection?" (not merely "organization" implied in the directory structures?).

I hope my rambling wasn't too unwanted or inappropriate for github (maybe better suited as a group conversation at reddit?). I just wanted to add: a ".collection" file could be used for the metadata (to denote a disk branch is a collection, not merely an organization. Something more significant than just structure. The content of the .collection file could contain the "description."). That would keep everything about the shared environment on the disk, not internal to (proprietary to) muwire.

The more I think about this, the more elegant it sounds to me. To my thinking the disk should be the "end all, be all" of what muwire shares. Just one user-defined share directory (containing everything). The user can either

• Use a "share management" tool in muwire to 1) move/copy items into the share, 2) create symbolic links to items outside the share directory (if moving/copying items isn't ideal. I think it wouldn't usually be ideal.). 3) move branches & leaves (whether real dirs/files, or links) around within the share directory (create the meaningful structure if desired). 4) Mark branches as collections (create the .collection file containing description, perhaps other metadata would be useful).

• Do all the above manually from the command line.

If there were a "manage share" front-end (to perform the manual activities for the user), it could offer to spit out the commands to re-create what exists in the share directory(?). I.e., anyone relying upon the front-end would be able to recreate their work easily without going through all the UI activities again. They'd have a "backup" of that shared creation. (This would educate people about how to use the command line to do it themselves.).

I don't know how much effort it would take to develop something like that. But, I think it would be very clean/elegant. I just wanted to add that the notion of "collection" (and "sub-collections" within collections) could exist external to muwire too. (And yet, not really be external if the "manage share" front-end existed.).

[zlatinb]

A collection is already managed in a file. You can find the specification in the doc/collections.md file in the source tree. On disk, they are stored in $HOME/.config/MuWire/collections. In short, the file contains the name of the collection, timestamp, who created it and description of the collection, optionally a description of each file too.

Regarding the tools as I said I'm reluctant to do it myself. It is a lot of duplicated effort and the risk that a bug in my code will damage someone's library is too high for my liking. But if someone wishes to contribute such code I will consider it.

I see we are diverging from the original topic of this ticket so I encourage you to start a discussion in the "discussions" section here. If you prefer reddit that's fine too, my username there is zab_ and the sub is r/i2p.

[zlatinb]

I'm happy to let you know that the original feature request in this ticket is now implemented in git. If you can build from source please give it a try, otherwise I expect to release a beta version in the next few days.

Both the browsing and the responding side need to run the new code in order for this to work.