XYplorer Beta Club

grindax wrote:Perhaps it would be possible to instead make the rebuild command (Ctrl+Shift+F4) not collapse a locked tree?

grindax wrote:

admin wrote:Hmm, now that you ask for it, and since we now have Remember Tree State that would be possible indeed. Only I'm not sure if everybody would be happy with that change... Rebuild Tree has its behavior for many years now.

What I've been thinking about recently is: now that the tree expansion can be controlled separately, why not merge the functionality of Refresh Tree and Rebuild Tree, making one robust way to make sure that the tree is fully up-to-date? Having two completely separate functions is a bit difficult to understand (especially with regards to how their functionality overlaps).

While I'm mentioning this, maybe even the functionality of Shift+F4 could be folded into this as well. To this day, I still don't understand what that does that's different.

grindax wrote:

admin wrote:The easiest way would be to combine Rebuild Tree and Tree State, but it would be notably slower than Refresh Tree.

I believe that would be a good approach for now.

But longer-term, thinking through the use cases for where I've wished to refresh the tree...

Since most of the time the tree is already current, there are only (relatively) occasional times where I see something that is out-of-date. In those cases I find that it's almost always necessary to do a rebuild to get the problem corrected.

Perhaps the set of functions concerning the tree could be changed to something like this:

• Refresh Tree (which means do a rebuild as well. Usually I expect that doing a 'refresh' means that it will be fully current afterwards, just like I expect this for F5 on the file list)
• Reset/Collapse Tree (either as separate options or combined. Could potentially just do the quick stuff that F4 currently does, plus collapses the tree. I myself don't fully understand where the quick version helps since I usually have to resort to rebuild, but maybe this is still required in some scenarios)

grindax wrote:I think the argument that something can't/won't be improved primarily because it's very old is a weak one.

And if no-one can explain or remember why Refresh (F4) doesn't actually do a full refresh, or why the pseudo-refresh in it's current form is more useful, then I don't see how you can say that it's good the way it is.

Sometimes things that have been designed and developed in the past can be improved upon.

grindax wrote:I do still wonder who would have a need for Refresh Tree (F4) now. It seems that between Auto-refresh and Rebuild Tree all bases are covered. Maybe someone not using auto-refresh and/or is using some other combination of settings. Anyway, I'll take your word for it that there is a use case somewhere that is helped by it.