Feature: Add TreeView

[rc1]

[!important] Current status: https://github.com/files-community/Files/issues/1928#issuecomment-1634584639

Is your feature request related to a problem? Please describe.

Typically, I work in a project folder. That folder might have multiple sub folders like: images, src, prints, presentations. With Windows Explorer and Files, I must keep navigating in and out of folders. I want a view of all my files and folders in one view. Much like how VS Code's 'Explorer' handles files display and navigation, or how Mac's Finder handles.

Describe the solution you'd like

In list view, I'd like a tree navigation component for files allowing me to expand a folder to list is child files and folders (which can be expanded too)

Describe alternatives you've considered None. I've tried for years now without this feature on Windows. Still miss it sorely from Mac.

Additional context There is discussion on Reddit where someone looks for this feature on Windows.

Here is a found image of Finder on Mac.

[mdtauk]

It is useful to remember that FIles will always exist alongside File Explorer - so if that offers something you prefer, you are still able to use it.

Files will always try to offer things that don't come with the default.

But this is all helpful feedback, and until we are able to overcome technical hurdles, work will be slower on this feature.

[dcadint]

Oh Please no. why would you want a tree view in the contents pane

Here is a simple multi-folder workflow with a **sidebar treeview ...

Here is that same exact multi-folder workflow with a ...

In short, contentpane treeview lets you see the contents of multiple folders simultaneously. Sidebar treeview does not; you must either click between folders/tabs, or open a new window for each folder.

What you have shown here is kind of a straw man. You put each folder in separate windows with a contracted navigation pane and overly large icons in the content pane. In windows 11 the navigation pain is contextualized to the tab and content. As far as having to click between folders/tabs to see both content there is the ability to add another pane to have something similar to a file commander view.

In the contents I just want to see the contents of what I'm focused on

What if you're focused on the contents of multiple folders?

Folders themselves are contents, depending on the context.

If you are focused on the contents of multiple folders usually its only 2 at a time any way so the file commander style previously mentioned makes more sense. But usually If I'm comparing two sets of files in two different locations its between two different drives which means you have to pick the other drive from the navigation pane and open another tab anyway because the tree view in the contents pane is only looking at one drive. Further folders are an organizational mechanism (they're really not content) and if I'm moving files its because I'm regrouping and don't necessarily care about the contents of other folders just the folder's name itself so I scroll the navigation pane to the folder I want to move them to and select them from the contents and drag and drop them to the folder in the navigation pane even across drives. With the tree in the content pane if you have a rather large tree structure you have to select your files and then drag and bump up against the top or bottom of the content pane until it scrolls to the place you want to move or copy them.

why would anyone want to see the tree there, just to add more clutter around the contents you are working on and want to focus on?

Because you can see more things in a single pane without additional navigation.

it should go in the navigation pane because that's what it is, a navigation tool.

It's great for top level navigation, which UI designers are starting to recognize as their preferred use of the sidebar. The prevailing belief is that the sidebar should be as static as possible, so you can always have quick access to entirely different parts of your computer.

Having a static sidebar and a treeview content pane gives them both very clear roles:

• sidebar = toplevel nav
• contentpane = sublevel nav

But if you introduce expanding folders in the sidebar, it stops being that. Both sidebar and contentpane become sublevel nav. which is redundant, splits the functionality unnecessarily, and almost completely removes toplevel nav.

Again, folders are an organizational mechanism not content and are something navigated. It really isn't content; you could say its meta data about the content, the group, sub-groups, sub-sub-group categorization of the content. In a library there are floors and sections on each floor and aisles in each section and bookcases in each aisle and shelves in each bookcase but no one would call these books.

There are many valid reasons to prefer the sidebar treeview, but they are above all a preference—do not mistake it for universal truth.

Yes, I see that some people may like it locked to a top level but others might like to open up those levels and drill down in the navigation side bar. So why not make both possible?

[rc1]

Worth noting this UX is opt in.

Taking Finder as an example:

1. The feature offers value (productivity gain) to you, expand folder in the content view.
2. the feature doesn’t offer value to you, don’t expand the folder in the content view.

It’s not a radical idea. Lots of IDSs have folder and files together in a tree view.

Opinions are interesting. Attempting to persuade others of its value or lack of seems peculiar.

[0x5bfa]

there are some technical hurdles to work out with it, especially with the detail view columns.

Not really. I have something like this in my project. Sidebar is using ListView with constom style. We can add this into either sidebar or details view. On windows, I have never seen such a functionality in the details view in any app, and I think it's nice to have it in sidebar and, leftside tree borders and chevrons could be mess if we add it into the details view.

https://github.com/0x5bfa/RegistryValley

[mdtauk]

there are some technical hurdles to work out with it, especially with the detail view columns.

Not really. I have something like this in my project. Sidebar is using ListView with constom style. We can add this into either sidebar or details view. On windows, I have never seen such a functionality in the details view in any app, and I think it's nice to have it in sidebar and, leftside tree borders and chevrons could be mess if we add it into the details view.

I think the technical issues come from how the app handles storage and it's various icon/list views.

We have designs being worked on for when implementing TreeView is figured out. We probably wont be able to implement both options at the same time, but if we can figure out some of the technical issues - we can get something.

If we can figure out the issues with both of these options, we could always add a toggle when someone chooses to use a tree view.

This is not a promise that the feature will come at all - only that we are looking at how to do it - and I am designing how these would look in the app.

[mdtauk]

Here is what we are currently thinking of as a design for adding TreeView as an option some time in the future

We appreciate any comments and feedback you may have, before we begin planning for, and building the feature.

[gdsa32]

Here is what we are currently thinking of as a design for adding TreeView as an option some time in the future ... We appreciate any comments and feedback you may have, before we begin planning for, and building the feature.

The absence of a Treeview is the sole reason I still didn't fully migrate from File Explorer to Files app. I don't care if it's located in the left side pane or in content pane, as long as there is one.

At first, I thought it was a little odd to have this additional column solely for the Treeview. But I kept imagining the various ways this could work in my workflow, and it started to make sense.

[jordan-msftfan]

Here is what we are currently thinking of as a design for adding TreeView as an option some time in the future

We appreciate any comments and feedback you may have, before we begin planning for, and building the feature.

This design takes up too much space on the left side of the screen, and breaks the logic of Windows' native file management sidebar, I don't think most people will like it unless they're using a 21:9 or 32:9 monitor.

I personally use a small sized laptop and I'm skeptical about the information density of this design when it implemented.

[mdtauk]

At present, when the window becomes narrow, the sidebar enters its overlay mode

The sidebar also supports a collapsed mode, which can also free up space

[stoph88]

It doesn't really seem like much of an improvement from the regular explorer to be honest. My biggest gripe with File Explorer is that, as a video editor, assets and files are organised into folders and subfolders with no way to view them all at once while still seeing the folder heirarchy. Mac OS Finder and the project panel of Premiere Pro manages this quite well

---

From: Martin Anderson @.> Sent: 11 July 2023 05:19 To: files-community/Files @.> Cc: stoph88 @.>; Mention @.> Subject: Re: [files-community/Files] Feature: Add TreeView Item Layout (#1928)

At present, when the window becomes narrow, the sidebar enters its overlay mode

[image]https://user-images.githubusercontent.com/7389110/252558653-a58a192e-80c3-4fb2-bc0a-9a1ed08536de.png [image]https://user-images.githubusercontent.com/7389110/252558729-e1ab41da-e496-49ce-8aec-3419a3dc7017.png

The sidebar also supports a collapsed mode, which can also free up space [image]https://user-images.githubusercontent.com/7389110/252558857-fac042c0-d00a-4b2b-8f58-90b747440dee.png

— Reply to this email directly, view it on GitHubhttps://github.com/files-community/Files/issues/1928#issuecomment-1630146322, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4STDNAGLYSNDEQFZP7L7S3XPTO47ANCNFSM4RM3XBLQ. You are receiving this because you were mentioned.Message ID: @.***>

[theophanemayaud]

Same here as @stoph88 i really like the ability to view all files at once even when the structure is nested and not controlled by me (either corp rule or software managed)

[SgtSweetieBelle]

@dcadint

In a library there are floors and sections on each floor and aisles in each section and bookcases in each aisle and shelves in each bookcase but no one would call these books.

I think a better analogy is sorting screws into compartments. You can use a cabinet of drawers like this, where you can only really see into one at a time, unless you pull out all the drawers you need and put them on your desk, which takes up space: Or you can use a drawer with compartments, which gives you access to all the screws at once. Yes, the singular drawer holds less in totality. But it's so much easier to view and access the contents of a single large drawer than a gigantic cabinet of smaller drawers.

Again, folders are an organizational mechanism not content and are something navigated. It really isn't content; you could say its meta data about the content, the group, sub-groups, sub-sub-group categorization of the content.

This is fair. But then there's a question of how the metadata divides the content, and how much of that content can be made visible to you at a time based on how the metadata is shown.

If, for example, we think of folders as "tags", and assume a UX where clicking on a tag makes its files visible, then being able to expand multiple folders at once is equivalent to being able to ctrl+click multiple tags and see every file that falls under one or more of those tags.

With the tree in the content pane if you have a rather large tree structure you have to select your files and then drag and bump up against the top or bottom of the content pane until it scrolls to the place you want to move or copy them.

I think this makes a lot of sense, and in this case, the content treeview is less useful than the navbar treeview.

What you have shown here is kind of a straw man. You put each folder in separate windows with a contracted navigation pane and overly large icons in the content pane. In windows 11 the navigation pain is contextualized to the tab and content. As far as having to click between folders/tabs to see both content there is the ability to add another pane to have something similar to a file commander view.

It's not a strawman because it's just what I have to do to meet my use case. Each folder is in separate windows because I want to see in all of the folders at once. The nav pane is contracted because I'm not navigating. I am already where I want to be.

Let me try again with your issues addressed: The icons are small and the nav bar is big. And yet, the problem persists: I need 4 extra windows to see into all four subfolders at once.

Mind you, this is just ONE of my video projects. Other projects have WAY more subfolders, which requires MORE windows to see into all of them at once:

And look fam, I was writing up a really comprehensive point-by-point response to the rest of your post, but as I kept writing I realized that there's a really consistent pattern to all of your counterpoints: you're only considering your use cases and not mine.

I have outlined my use case multiple times: accessing multiple files split between multiple subfolders in one folder. This is something I spend 80% of my workday doing. And yet you keep saying "usually it's two folders" and "different drives" and "moving files" and things like that. Those are your situations, not mine, and your "usually" is not my "usually". I usually need more than 2 folders open at a time, they're usually all on one drive, I'm usually not moving files, because I'm already done organizing and now I just need to access them.

So why are you ignoring all of this in your replies? Why are you asserting things that don't apply to me? I don't understand.

[SgtSweetieBelle]

@mdtauk

At present, when the window becomes narrow, the sidebar enters its overlay mode

The sidebar also supports a collapsed mode, which can also free up space

This looks fantastic so far! I'm really digging the idea of collapsing the static navpane when it's not immediately needed. I'm wondering if maybe it's even possible to add an option to "pin" or "unpin" it, OneNote-style?

@stoph88 @theophanemayaud

It doesn't really seem like much of an improvement from the regular explorer to be honest. My biggest gripe with File Explorer is that, as a video editor, assets and files are organised into folders and subfolders with no way to view them all at once while still seeing the folder heirarchy. Mac OS Finder and the project panel of Premiere Pro manages this quite well

Same here as @stoph88 i really like the ability to view all files at once even when the structure is nested and not controlled by me (either corp rule or software managed)

In all fairness, the contributors have already said quite a few times that they do plan on adding Treeview to the Filepane, but it's going to take a lot of extra work and won't be out for a while, so in the meantime they'll be working on Treeview in the Navbar because that's easier to implement.

So if they're asking for feedback on their implementation of the Navbar Tree, I'm not really sure it's productive to criticize it for not being the Filepane Tree, since that's not the focus at the moment.

That being said, I'm starting to wonder if maybe these issues should be split into two, to make it clear that both are being worked on, while avoiding getting caught up in debates about which one is better. It can't be productive or encouraging if every time someone posts an update or a concept of the Navbar, it gets dismissed for not being the Filepane.

[yaira2]

This thread contains a lot of helpful feedback, and we appreciate everyone's willingness to consider the differing viewpoints on how this should be done. It's clear that there are two different workflows and it's hard to say one is better than the other. The plan is to start with the TreeView Layout because it's something that File Explorer doesn't currently offer, but we're certainly considering a left side TreeView as well.

We're aware that many of you are eagerly waiting for this feature so we want to be as transparent as possible. As it stands today, the codebase isn't ready for us to implement this feature. We need to make some more gains in the performance area as well as refactor and reduce duplicate code between the different layouts. There has been a lot of progress over the last few months, but we still have a lot of work ahead of us before we can implement this feature. In the meantime, we're reading all your comments and taking the differing viewpoints into consideration.

[NeArnold]

Last month I entered a feature request that was soon merged into this discussion: https://github.com/files-community/Files/issues/12653

While I did not articulate it well, I was calling for the implementation of an existing Windows 10/11 Explorer navigation pane feature "Expand to open folder" (see figure below). Clearly some in this discussion - 0x5bfa and dcadint for example - have been thinking similarly to me, while a number of others are looking for more MAC-like features that incorporate treeview info into the content panes of the Files UI.

While it looks like I may be a "day late and a dollar short" - per yaira2 comments yesterday - I'm not writing to enter the debate but rather to suggest that it may be time to split this conversation back into two (or more - as I can't say I fully understand all the points of view) threads. My expectation - I may be wrong - is that these two different approaches - i.e., NavBar vs. FilePane - involve quite different code infrastructure, in spite of having a Treeview in common. Further, implementing the messaging that executes the navigation pane "Expand . . ." option seems to be a significantly easier task (that might even yield benefits for the larger task).

[SgtSweetieBelle]

@NeArnold

it may be time to split this conversation back into two (or more - as I can't say I fully understand all the points of view) threads

Yep, this was my suggestion as well in my most recent post:

I'm starting to wonder if maybe these issues should be split into two, to make it clear that both are being worked on, while avoiding getting caught up in debates about which one is better. It can't be productive or encouraging if every time someone posts an update or a concept of the Navbar, it gets dismissed for not being the Filepane.

I'm in favor of Filepane Tree, but they already said so many times that they're working on it later, and it stinks that they showed off something really cool from Navpane Tree and then suddenly get shut down by a bunch of people complaining that "i don't like it because it's not FilePane Tree"

Splitting this into two issues would mean each thing gets the attention it deserves without being run over by people who want the other thing.

[drandarov-io]

A Tree View in the content area, where you can even potentially switch between "Details" or "Icons" view of subitems is the single feature that would replace any other File Manager for me. I hope the technical challenges can be solved.

[ketonik]

In case this is looked at again, here is a mock-up for how it could be implemented

The drop down would allow the picking of a drive

No not in the sidebar. We are wanting this in Details view in the main window pane to view contents of folders, their sub folders and their files, absolutely no need for this in the sidebar like old skool Windows, that was a disaster because it forced user to constantly resize horizontal width of sidebar to be as wide as the window pane, that was just plain stupid logic and implementation.

[Josh65-2201]

That is just a concept, It hasn't been decided on how it will be implemented

[ketonik]

Yea well, don’t be distracted and have the request completely twisted into something that’s not originally what is asked.

I don’t want the request be misdirected by an million old skool windows users here wanting that silly old sidebar tree view, evidently, they have taken over dialogue of the conversation and we want to avoid them skewing development into something that ends up giving us a File manager with a implementation that reverts back to ancient ideas.

As mentioned that old sidebar tree view ended up being used as its own dedicated window pane and still created problems with usability.

[ketonik]

@NeArnold

it may be time to split this conversation back into two (or more - as I can't say I fully understand all the points of view) threads

Yep, this was my suggestion as well in my most recent post:

I'm starting to wonder if maybe these issues should be split into two, to make it clear that both are being worked on, while avoiding getting caught up in debates about which one is better. It can't be productive or encouraging if every time someone posts an update or a concept of the Navbar, it gets dismissed for not being the Filepane.

I'm in favor of Filepane Tree, but they already said so many times that they're working on it later, and it stinks that they showed off something really cool from Navpane Tree and then suddenly get shut down by a bunch of people complaining that "i don't like it because it's not FilePane Tree"

Splitting this into two issues would mean each thing gets the attention it deserves without being run over by people who want the other thing.

But guys like you and your cheerleaders are the ones coming into this request, hijacking it almost and start asking for something different.

Side bar, or nav bar whatever you call it is basically a place for favourite locations, the main work area is the window pane on the right, that’s where the action is, that’s where the space is and that’s where we want disclosure triangles on the folders to work with in them.

[ketonik]

Here is what we are currently thinking of as a design for adding TreeView as an option some time in the future

We appreciate any comments and feedback you may have, before we begin planning for, and building the feature.

No that’s definitely no what we want, your splitting the main window pane in two sections wasting space and you still can’t select multiple files from multiple sub folders.

Just look at the Finder List View, and make it the same, job done, so simple.

[ketonik]

Here I’ll crop the screenshot so people don’t have their attention diverted to the side bar

This is the implementation of Details view, so we can select files in any of the sub folders and move them to either the root of the directory or inside another renamed directory, of course it’s essential also to have folder sizes calculated because we’re often working on files with different versions and we can see if the same duplicate is in another folder, makes it easy to delete, move and rename stuff.

This in Windows has always been a pain.

[theophanemayaud]

I believe the original feature request from @rc1 was basically to copy the macOS style expanding of folders within the content pane :

Here is a found image of Finder on Mac.

Which is also what @ketonik is again requesting so nicely :

Here I’ll crop the screenshot so people don’t have their attention diverted to the side bar [...] This in Windows has always been a pain.

I agree with previous comments that this is functionally very different from implementing a navigation/exploration expanding left sidebar like in windows file explorer. Personally, I initially stumbled across this project while looking for a file explorer for windows that felt more like I was used to, coming from macOS. The tabs were so nice to have again, but I missed this "expanding of folders within the content pane".

I'm not going to split these issues because it seems you've (maintainers) merged them here, and I'm not sure it's really by choice or because you don't have the time. But if you prefer, I'll take the time to detail both again in two new, separate issues, so you (and other contributors) can track them properly and thus behave in a more proper manner...

[ketonik]

Few more screenshots of Finder's List View a.k.a Details View in Files: Notice how there's two different folder sizes can be set in List view, notice the path bar shows full path of selected file, see how a tag is a dot and doesn't take up much column space, notice view settings can have many different user defined font sizes, notice all the navigation controls, back forward buttons etc are contained within the view list pane area rather than how they seem to be disconnected in Windows by being over the far left on top of the side bar etc

[ketonik]

ElementaryOS has a GitHub project with source for their ‘Files’ check it out, it also has List view like macOS Finder

https://github.com/elementary/files

maybe there’s code you can use.

[etfz]

I'm confused. As far as I understand, mdtauk claims to be working on this design, and has presented mockups of a File Explorer looking view with a separate directory tree panel. This is very much what I am looking for in combination with dual panes (only with the current sidebar hidden) in order to get something resembling Total Commander. The OP and some other contributors seem to be talking about a macOS Finder single panel tree view, however. If the latter is not what is being worked on or considered, shouldn't this be a different issue or something? (and vice versa)

Actually, what I think might make more sense for the workflow I'm looking for is adding the following options:

• Replace the current sidebar with something resembling that of File Explorer
• Show side bar for each pane (in dual pane mode), independently of view mode

I don't know that the File Explorer view makes sense as a view mode option. You will still want to choose whether to display a list, thumbnails or something else. Would there then be two view mode settings?

[yaira2]

@etfz this comment explains where we're currently at with this feature request. https://github.com/files-community/Files/issues/1928#issuecomment-1634584639

[etfz]

Alright. So then a new issue should be opened regarding the navigation pane feature? Because that's clearly not the feature that was originally requested, either way. I found a few old issues that were closed in favor of this one, but those were created before the comment you're referring to, I guess.

[yaira2]

We're tracking everything here. It's true that there are two different requests, but we want to track all the tree view related feedback in a single issue.

[rickmanking]

no tree view on the left block could be the only possible reason for my not to recommend Files app to my friends. leaving out this issue, Files app is much better than Windows Explorer

[ketonik]

no tree view on the left block could be the only possible reason for my not to recommend Files app to my friends. leaving out this issue, Files app is much better than Windows Explorer

You're contradicting yourself. You say, Files is better than Explorer, you know neither have tree side bar, yet you won't recommend Files. No-one with half a clue is going to care about your recommendation with that kind of thinking.

Honestly, what is it with Windows users, their brains since forever seem to function only in 1 dimension and they resist and hate anything different to what they are used to despite every conceivable logical reason why other solutions are superior.

Open your minds, remove the blockers from you brains, you're like programmed mindless automatons.

[Josh65-2201]

@ketonik Please stop bullying people for how they like to use features. Not everyone dislike the tree view in the sidebar.

[SgtSweetieBelle]

@ketonik Not sure what you mean by “neither have tree side bar”, because Explorer has a tree sidebar, and Files does not. The person you’re replying to made a perfectly lucid point, especially compared to your unhinged ranting against Windows users.

[yaira2]

I'd like to remind everyone of the code of conduct.

[lolDayus]

no tree view on the left block could be the only possible reason for my not to recommend Files app to my friends. leaving out this issue, Files app is much better than Windows Explorer

after a day of constant File Explorer-related frustration, I said enough's enough and found this program, and thought I had hit the jackpot with the cause of most of those annoyances being solved all at once. I was stoked enough about what I was seeing that I was about to randomly text a friend and say, "hey, you need to try this" since he needs Explorer to function similarly to how I do.

But I didn't end up sending it because lo and behold I found the "too good to be true" caveat pretty quickly. Without the expanding directory view/"tree view" that even File Explorer has, what should be the Navigation Pane (if you don't actually call it that, fair enough, but it's what even the average user more-or-less expects it to be) ends up being a simple Bookmark/Favorites menu. Apologies for piggybacking off this comment but I just wanted to help emphasize the importance of this feature, or as of right now, non-feature

[yaira2]

@lolDayus thank you for your feedback, this is definitely one of the more popular requests and we're aware that it's a requirement for many users. If anything, this raises the expectations for the initial implementation and we want to make sure we do it properly.

[pascaljr]

I just purchased this App since I don't want to upgrade to Windows 11, but I want tabs, and the only huge disappointment is not having a tree view on the left block that opens the directories as I navigate them on the large panel. If I could, I would get my money back from the purchase, as this feature is so important for me. If it were implemented, I'd recommend it to several friends that, like me, don't want windows 11 but wants tabs

[yaira2]

@pascaljr thank you for your feedback, Store refunds can be received by contacting Microsoft support.

[Draise14]

Really looking forward to this feature! I will be using this to replace the default W11 explorer, but this feature will definitely make a faithful user of your work here.

[yaira2]

Unfortunately, performance remains the primary obstacle.

The core challenge lies in the tree view structure, where each tab can have a distinct state with its own set of expanded or collapsed folders. This requires individual tree view instances for each tab, which substantially raises the system’s resource consumption—this increase is proportional to the number of active tabs. In contrast, the current sidebar’s static nature permits the use of a single shared instance across all tabs.

I hope this comment provides a bit of a window into what's taking so long.

[Draise14]

Could a tree refresh/poll load on one tab once at a time? Instead of feature instance? Basically a redraw of the breadcrumb draw?

I'll trust you on it! I am sure the wait will be perfect.

[yaira2]

Could a tree refresh/poll load on one tab once at a time? Instead of feature instance? Basically a redraw of the breadcrumb draw?

I'll trust you on it! I am sure the wait will be perfect.

That's definitely an approach, the concern is that it won't happen fast enough but it could still be worth it to investigate this idea.

[schoenid]

Yes, I'm missing a treeview too. I'm using folder trees since over 40 years now and I'm lost without any optical orientation, where I am in a directory structure.

For the moment I'm using the Dolphin file manager for Windows (yes, this exists ...), but for some reason, only a part of it's famous posibilities were ported from Linux. Thats one reason why I'm working mostly on Linux. Unfortunately the stability of Linux is no more as good as of Windows.

I'm sure, Files would be a great tool without to let many wishes open, if this tree view for folders could be added.

[schoenid]

In Dolphin, there is only one tree view instance. The files views in tabs will then expand the treeview to the open location and pointing there to the actual position. If a tab is changed, simply the position in the tree view is updated, no need to handle a separate tree for every tab. This improves the performance with a little lack in navigation, but it might be a possibility for easier integration in Files too. (just only as possibility...)

[Tartarusome]

maybe there's a perfect plan，the disk's file system is NTFS or REFS on most of windows pc ,so you can use USN journal to build a database，instead of Iterating through all files on disks. the usn journal allow you to index the names and paths of all the files and folders on a disk storing hundreds GB of files in a few seconds. and this journal is sorted in reverse chronological order of when the files were modified, so it can update the database very quickly. So all you need to do is write an algorithm to filter out repetitive paths and split paths into treenodes. Or you can use everything sdk which is a ready-made method.

Translated with DeepL.com (free version)