b949 Tree double-spaced

[coyote]

With today's "FreeCommander XE 2026 Build 949 64-bit non public" my tree pane's spacing changed from (what looked like) single to double spacing, which is highly inefficient. I guess this might just be a change I dislike instead of a bug.

Incidentally, I use an atypical 'File Explorer' config which I posted details about at viewtopic.php?p=44044

[Free4all]

I, too, noticed that the tree line spacing is much greater in v949, and this regression causes significantly fewer folders to fit in the tree pane. Hopefully this can be fixed.

[ralfso]

You can adjust it in freecommander.ini
in section [Form] with

TreeItemHeight=12

or another number you prefer.

Changes in freecommander.ini need a closed FreeCommander.

[coyote]

Wow Ralf thank you for that. I'm loving TreeItemHeight=6 more than I liked whatever it was before it increased to 18!

[Marek]

The TreeItemHeight Option exists under Settings->View->Tree: Color/Font/Icons: Item height.
Currently it is not possible to set the value to 12 - changed for the next release.

A value modified directly in freecommander.ini may be overwritten if the dialog for saving settings is used.

[Free4all]

The TreeItemHeight Option exists under Settings->View->Tree: Color/Font/Icons: Item height.
Currently it is not possible to set the value to 12 - changed for the next release.

A value modified directly in freecommander.ini may be overwritten if the dialog for saving settings is used.

Thanks. Are you going to allow it to accept any reasonable integer?

[dsperber]

So the item height of 18 in FCXE 948 is 18 and displays "normally, i.e. single-spaced". But the same item height of 18 in FCXE 949 now results in "double-spaced"?

So we have to now change it to 12 in order to restore the old single-spaced presentation, except that the UI for item height does not permit reducing the value to anything smaller than 16. So we must manually update INI to manually set the value to 12, in order to get it to look the way it previously has always looked, i.e. single-spaced.

And this will be updated in 950 to allow entering values smaller than 16. Fine. I've manually set 12 in INI in order to get things to look as they always have, so I'm OK with this new issue.

However...

If a Tree contains one or more folders which are "expanded" prior to closing the program, and then the program is closed, when the program is re-launched ALL OF THE PREVIOUSLY EXPANDED FOLDERS are initially presented just as they looked previously, i.e. expanded, but then instantly any/all expanded folders in the Tree immediately AUTOMATICALLY "COMPACTED" and closed up. So there is "animation" you might say, in the Tree pane, in order to achieve all folders compacted.

I find this annoying. The Tree pane "flickers" (i.e. is animated). I would like the re-launched Tree presentation TO BE EXACTLY WHAT IT WAS when the program was previously closed, with any/all expanded folders remaining expanded exactly as they last were presented. No reason at all to compact up any/all folders which were previously expanded.

I don't see the point of compacting all folders as the opening initial presentation, thus requiring me to re-expand them again just as they last appeared in the previous program instance.

I would at least like the option of requesting this "keep expanded folders expanded on FCXE re-launch" behavior in Settings (or INI).

(1) Tree before FCXE CLOSE, with two folders "expanded":



(2) Tree after FCXE CLOSE, and then FCXE RE-LAUNCH, with all folders initially shown still expanded but then instantly "compacted" to be closed:

[horst.epp]

,I don't see the point of compacting all folders as the opening initial presentation, thus requiring me to re-expand them again just as they last appeared in the previous program instance.

I would at least like the option of requesting this "keep expanded folders expanded on FCXE re-launch" behavior in Settings (or INI).
/quote]
You don't see the point because you may not have large deep nested network folders.
Those may take a very long time to expand and delay the start-up.

[Marek]

So the item height of 18 in FCXE 948 is 18 and displays "normally, i.e. single-spaced". But the same item height of 18 in FCXE 949 now results in "double-spaced"?

I use for the tree third party component. Unfortunately, I didn't notice that the spacing in the new version of the component had changed.

[dsperber]

You don't see the point because you may not have large deep nested network folders.
Those may take a very long time to expand and delay the start-up.

Having a network location as the last location in either left/right (or top/bottom) pane has always been something that slows down re-launch startup time. Similarly, if you had "0 Desktop" as the currently active location at close, and then re-launch. Of course "0 Desktop" is quite time consuming even within a current FCXE instance.

But these are all known and expected behaviors. If it takes a significant time, I'm aware of it and prepared for it.

In my above example screenshots the folders are on LOCAL DRIVE LETTERS, internal to the PC. And if you watch what happens, it actually does re-launch with the last expanded folders still expanded in Tree pane, exactly as it last looked! But that expansion only lasts momentarily, quickly dynamically compacting onscreen (as if you are seeing an animation) and then the Tree pane is re-painted (e.g. to populate additional folders in the now available space at the bottom of the pane if appropriate).

I'm just saying all that is currently going on is unnecessary and undesirable for me. I'm perfectly happy just seeing at FCXE re-launch whatever was last on the Tree at previous FCXE instance close, no matter what it was and no matter if it does involve a network location or "0 Desktop". It may encourage me to change current pane content to always be a local location before closing FCXE just so that re-launch is quick.

Certainly offering this behavior as a Settings option seems reasonable. It should be up to me to weigh the value of (a) perhaps, but not always, slower FCXE re-launch time, vs. (b) annoying and time-consuming personal time spent during FCXE re-launch just to re-navigate down to all of the previously open folders where I was last involved before I can even begin to be productive again.