xplorer2 v1.72 final

[DavidSalahi]

I just built a system with the new core i7 processor and I had to go 64-bit to be able to access all my memory. But after installing xplorer2 I was wondering where all my shell menu items were. Checked this forum and found out there's a 64-bit version.

Thanks!!
David Salahi

[Robert2]

does the new compromise 1721 work for everybody?

Hi Nikos,
I have been testing v.1.7.2.1, the List View mode and color coding extensively.

First, if I set “Max list column width” to “2”, I get a pop-up message saying that I should be using a value “between 50 and 1000”.
But if I set “Max list column width” to “1500”, I don’t get any pop-up message and the value is recorded by xplorer2. What's more, the columns are resized so that the filenames which were truncated with a value of “1000” are now displaying entirely.
Now if I close xplorer2 and relaunch it, the “Tools | Options…” dialog still shows “Max list column width” at “1500” but the filenames are truncated again! As if the “1500” column width would not really stick…

I am stuck in a Catch-22 here. I use the List View mode almost exclusively. I also use color coding on some files in various folders, some with many, many files and subfolders. So if I want screen rendering to be reasonably fast with both the List View mode and color coding, I need to set the “Max list column width” to something other than “0”. But if I set it to the “max value” of “1000”, plenty of filenames get truncated, including filenames with fairly short names… If I set the “Max list column width” to “1500” or more, it works so long as I remain in the active xplorer2 session (the filenames are no longer truncated). But this does not stick. As soon as xplorer2 has been closed, it relaunches with truncated filenames…

So as far as I am concerned, this latest version is no improvement at all!

I would very much appreciate if there was an option to have both the List View mode and the “Max list column width” set to “0”, or failing this, a “Max list column width” that could be set to any maximum value.

[nikos]

the only trade off you have is slow rendering vs some truncation for bold font items. Also this max width setting constrains the maximum only if it exceeds eg 1500. It won't make all columns 1500 pixels wide!

if it annoys you that much then don't use bold in your color rules

[Robert2]

if it annoys you that much then don't use bold in your color rules

No problem. I actually never use bolding in my “color-coding” rules, and  never will. It looks ugly on my screen. I only use italics on their own. Or “color-coding” per se (e.g. bright yellow against dark green background or aqua against navy blue).

[Robert2]

Hi Nikos,
I hate to be such a spoilsport but I still have issues with the latest version.
You introduced this latest version with this:

“it turns off optimizations in list mode but only if you leave max list column width setting (Tools > Options > WIndow > View) unconstrained. If you set it to a value, even big one, then you should have the best of both worlds.”

So as I understand things with v.1.7.2.1, I can get fast list building if I set “Max list column width” to something other than 0. Now if I set “Max list column width” to 999 which seems the upper limit, the longer filenames get truncated on my system even though I am not using bold face as a color coding rule. Things get better if I set “Max list column width” to 9999 for example but some filenames are still truncated and the good effect does not last beyond the current xplorer session. When xplorer is relaunched, the longer filenames are again truncated as if “Max list column width” was set to 999. The bigger numbers won’t “stick”.

Now if I set “Max list column width” to 0, v.1.7.2.1 displays the file lists with no truncation, but list building is 2 to 3 times slower.

As far as I am concerned, v.1.7.2.1 only made matters worse. I have reverted to v.1.7.2.0 and I hope the next release can offer something better than a trade off between slow rendering and no truncation on the one hand, and speedy rendering with truncation for all longer filenames on the other hand, irrespective of wether bold face is used or not.

You wrote “the only trade off you have is slow rendering vs some truncation for bold font items.” The trade off I am actually getting is speedy rendering with truncation for all longer filenames vs slow rendering but no truncation. As far as I am concerned, this is no improvement at all over v.1.7.2.0. I repeat, I am not using  bold face as a color coding rule, but I use the List View mode almost exclusively.

With v.1.7.2.1 (“Max list column width” set to 0), opening and displaying a dual pane window with a folder group in each pane takes 05 seconds 15 (no truncation). With v.1.7.2.0 (“Max list column width” set to 0), it takes 03 seconds 30 to create the same (non-truncated) display.

Now if I use v.1.7.2.1 and set “Max list column width” to 999, creating the same display also takes about 03 seconds 30 but quite a number of filenames are truncated even though I am not using bold face as a color coding rule.

On the other hand, if I use v.1.7.2.0 with “Max list column width” set to 0, I get speedy rendering and no truncation (I am not using bold face).

Maybe there is something I don’t understand but I feel trapped in a Catch-22.

[nikos]

ok we'll revert to how things were back in 1720 and just keep a bold beware term

[Robert2]

Thanks a lot Nikos!

As I already explained, there are plenty of ways other than bold face to "color-code" files. I personally find simple italics quite satisfactory. Otherwise, there are plenty of possible foreground colors, with or without a different background.

Also bolded filenames are less truncated when the font size is reduced.