Unintended node relocation (drag and drop)

[jonathonmckay]

For Cherry Tree 1.1.2, running on Windows 10.

Due to the large size (at least, I think its large) of my CherryTree note book, the application can sometimes shudder/lag/hesitate when switching between nodes. When this happens, the node tree may misinterpret slight mouse movements and click/release timings as me wanting to drag and drop the node elsewhere. I will then loose a node and have to go looking for what ever random place it ended up.

I propose menu item / tool bar button to toggle locking node drag/drop, maybe something like "Lock Tree Node Order". When enabled, drag and drop on the node tree simply won't happen (perhaps allowing node relocation through more deliberate means like keyboard shortcuts or menu options). When disabled, drag and drop on the node tree would operate as normal. The state of this should be recalled between sessions of the application.

[BileDemon]

I know exactly what you mean. This sometimes happens to me when using Firefox. I use a tab sidebar addon with hundreds of opened tabs - which looks a lot like the CherryTree node tree and also utilizes drag & drop for reordering. Sometimes when the browser is very busy, it registers a simple short mouse click as dragging, and the corresponding tab ends up in some random place where I moved the mouse after clicking.

Luckily I have not encountered this problem in CherryTree, but I would also appreciate some kind of simple locking mechanism for the node tree. This could be very useful when dealing with bigger CTB files.

[gitvectors]

My approach now in a revamped workflow is avoid having hundreds of browser tabs (each consuming RAM) avoid having hundreds of CherryTree nodes in a single instance of CherryTree

Instead of browser tabs use Zotero. A GUI and Connector are installed. Zotero libraryURL's can be linked to CherryTree documents. And other documents.

Instead of large CherryTree documents break them down to smaller CherryTree documents of limited scope. Use an indexing engine such as Recoll to give in one GUI a view of all CherryTree documents with Query: ext:ctd (show in Recoll all documents with extension *.ctd). Recoll GUI then acts as "Tree Explorer" of all CherryTree documents indexed.

In Recoll map MIME type application/xml to command: cherrytree %f BUT note that other applications/files use MIME type application/xml so next stage of thinking is to map to different applications. Recoll works great in Linux but the creator requests a small donation from Windows users because of the hassle of maintaining Recoll cross-platform.

[jonathonmckay]

@gitvectors , I see your point. CherryTree is less likely to stutter if the files are smaller. I could break up my one large notebook into several smaller ones: one for daily logs, one for projects, one for system maintenance, etc. It's not a bad idea.

However, where is that limit? I'd expect it likely depends quite a bit on the computer you're running it on. (Also, does CherryTree have any hard limits on the number or depth of nodes?) I could break up my notebook, but eventually the new smaller notebooks could also cross that limit of "too big", and I'd have to find new ways of breaking it down further. I'd then also have to somehow keep track of where certain types of notes are. With one big file, I can just say "It's in CherryTree."

I also make heavy use of the "Copy Link to Node" feature, with nodes referring to each other for related topics or cross references. I'm pretty sure all those links would break if I were to split up the file.

So, I would prefer not to break the file up.

[gitvectors]

You have not thought through how to build this "Internet of Things". With Insert Link you can point to: WebSite File Folder Node

So you can link to Folders or Files containing CT files (things). Study concept of "vector database". Next germ of idea is to link to Obsidian.

If you try Recoll it becomes your "Tree Explorer".

You should be minimising the depth of nodes rather than increasing, surely?

There could be an automated alarm if any CherryTree document is becoming unwieldy. Just monitor Tree Info.

And you have not considered Zotero to link files.

[P.S.] My current count of *.ctd documents as indexed on one GUI page by recoll is 514. They go back 10 years.

I can just say "It's in Recoll index."

[jonathonmckay]

I am experimenting with running CherryTree's priority at "Realtime" in Windows to hopefully reduce the amount of time the lags/stutters take to reduce the chance of this issue happening. Preliminary results (after using for 5 minutes just jumping between nodes) are promising.

[jonathonmckay]

Update: The "Realtime" priority thing does not help. It turns out the act of closing and restarting CherryTree is what makes it so much faster and more responsive. Seems that it gets more and more bogged down the longer it runs.

[gitvectors]

Have you tried using Recoll in Ubuntu as I suggested. https://www.recoll.org/ Don't break up your CherryTree at this test stage (if you have one huge file). Just setup the indexing experiment. You can test with indexing other MIME types such as doc, md, txt, pdf etc. to get the gist of how Recoll indexes any number of distributed files. Indexing first time takes a while so be patient. When you get to the point where you see your *.ctd (XML) file (not SQL) then we can explore breaking it up into multiple CT files to test performance and cross referencing strategy. As a reminder, to find CherryTree documents, run Query Language - ext:ctd i.e. Show documents with extension .ctd type.