Dual Pane - Formal Proposal Thread

[Mesh]

I just tried out Build 414, and I have to say that I absolutely detest the new 4 pixel splitter. When it was 3 pixels wide, it looked streamlined. At 4 pixels wide, it looks chunky - like something from the 80's.

I'm extremely thankful that Don put in the ability to set it back, but I think XY should have the original 3 pixel splitter as the default, and if people want it wider, they can still make it that way. But that's just my opinion.

[admin]

I just tried out Build 414, and I have to say that I absolutely detest the new 4 pixel splitter. When it was 3 pixels wide, it looked streamlined. At 4 pixels wide, it looks chunky - like something from the 80's.

I'm extremely thankful that Don put in the ability to set it back, but I think XY should have the original 3 pixel splitter as the default, and if people want it wider, they can still make it that way. But that's just my opinion.

What a difference a pixel makes!

I don't dare to make a poll about this -- I fear 2 men in white will come to take me away...

[admin]

Don, any chance the Type 31 message dealing with the Tree refresh issue has anything to do with the Type 31 message we are seeing with the 2 pane internal refresh issue?

I'm just curious.

Does this mean, this ZIP issue is still there?? I thought I had fixed it.

I don't see a possible relation here.

[Mesh]

Does this mean, this ZIP issue is still there?? I thought I had fixed it.

Nope, the problem never went away. Just for the sake of making sure we're on the same page, I've attached a test RAR file - it just contains a few directories and a couple of empty text files.

And I'll reiterate the test steps as well. Also, I'm using WinRAR 3.80, for the sake of consistency.



1. Create two empty folders - let's say C:\Test1 and C:\Test2.

2. Copy Test.rar into C:\Test1.

3. Go into C:\Test1, and extract Test.rar into C:\Test2. This bug exists regardless of whether you extract it via right-click, or via bringing up the entire app - but use the right click method for the sake of consistency (i.e. Right Click >> WinRar >> Extract Files...).

4. As soon as it's done, without doing anything, you should see that on the tree, C:\Test2 does not show a plus sign next to it indicating that there are subfolders.

5. Click on C:\Test2 to make it active. You should now see the contents in the list, but even now that you're in C:\Test2, the tree still doesn't show the plus sign reflecting that there are subdirectories.

6. If you refresh the tree manually, then XY acknowledges the subdirectories by showing the plus sign.



---------------------
Alternate Test

As a way of viewing a slightly different facet of this issue, modify the above directions in the following way:


When you create C:\Test1 and C:\Test2, create a child directory in the second directory - for example, C:\Test2\Experiment. Then, expand C:\Test2 so that you see C:\Test2\Experiment in the tree while you're in C:\Test1.

You'll see that after extracting the RAR file, the tree doesn't show the new folders, even though the folder is already expanded.

[TheQwerty]

Does this mean, this ZIP issue is still there?? I thought I had fixed it.

Nope, the problem never went away. Just for the sake of making sure we're on the same page, I've attached a test RAR file - it just contains a few directories and a couple of empty text files.

And I'll reiterate the test steps as well. Also, I'm using WinRAR 3.80, for the sake of consistency.

...

Yep, using WinRAR 3.71, XP SP3, XY v7.90.0414. Following those steps with Single Pane (@Test1) it works correctly, but with Dual Pane (@Test1 & Test2) it doesn't.

[Mesh]

Yep, using WinRAR 3.71, XP SP3, XY v7.90.0414. Following those steps with Single Pane (@Test1) it works correctly, but with Dual Pane (@Test1 & Test2) it doesn't.

Now that's interesting. I never even checked this with dual pane - I've always run into this problem while in single pane mode. I find it interesting that you're not seeing it in single pane.

I wonder if it's a difference in how you have XY configured...

[Demset]

Now that's interesting. I never even checked this with dual pane - I've always run into this problem while in single pane mode. I find it interesting that you're not seeing it in single pane.

I wonder if it's a difference in how you have XY configured...

Well, I see the problem in both single and dual pane. Build 414, XP SP3.

[TheQwerty]

Yep, using WinRAR 3.71, XP SP3, XY v7.90.0414. Following those steps with Single Pane (@Test1) it works correctly, but with Dual Pane (@Test1 & Test2) it doesn't.

Now that's interesting. I never even checked this with dual pane - I've always run into this problem while in single pane mode. I find it interesting that you're not seeing it in single pane.

I wonder if it's a difference in how you have XY configured...

That was with a fresh copy of XY. I just tested it again, and now it didn't work in Single Pane either. No idea... maybe I just imagined it worked.

[Mesh]

That was with a fresh copy of XY. I just tested it again, and now it didn't work in Single Pane either. No idea... maybe I just imagined it worked.

Well, for what it's worth, I'm always testing on a fresh copy of XY. I never upgrade one beta on top of another, I always start from scratch with a completely fresh install.

[admin]

I just tried out Build 414, and I have to say that I absolutely detest the new 4 pixel splitter. When it was 3 pixels wide, it looked streamlined. At 4 pixels wide, it looks chunky - like something from the 80's.

I'm extremely thankful that Don put in the ability to set it back, but I think XY should have the original 3 pixel splitter as the default, and if people want it wider, they can still make it that way. But that's just my opinion.

What a difference a pixel makes!

I don't dare to make a poll about this -- I fear 2 men in white will come to take me away...

I suddenly thought of the million screenshots I would have to change just because of the splitters. And also that each pixel increased splitter width can cost several thousand pixels (!) depending on your screen size -- that's a lot of toolbar icons (256 pixels per piece).

So I took it back to 3.

[admin]

Does this mean, this ZIP issue is still there?? I thought I had fixed it.

Nope, the problem never went away. Just for the sake of making sure we're on the same page, I've attached a test RAR file - it just contains a few directories and a couple of empty text files.....

OK, I could repro it when right-dragging from pane 1 to pane 2 and using the shell menu for the extraction. I also could fix it. So let's see who still gets a bug with the next version...

[Mesh]

OK, I could repro it when right-dragging from pane 1 to pane 2 and using the shell menu for the extraction. I also could fix it. So let's see who still gets a bug with the next version...

Interesting, I never involved dragging in any of this - I wonder how that affects what's going on. Were you not able to reproduce it without dragging?

And in any case, I eagerly look forward to testing this in the next beta!


<F5>...<F5>...<F5>...

[Mesh]

OK, I could repro it when right-dragging from pane 1 to pane 2 and using the shell menu for the extraction. I also could fix it. So let's see who still gets a bug with the next version...

Wow, you're fast! Okay, I tried out Build 415. I've got good news and bad news.

The good news is that you're definitely on the right track - it first appeared as if the bug had been nailed completely.


The bad news (which isn't very bad, as I'm sure it's a really quick fix) is that the bug is still there if the target directory has spaces in its name.

So, attempting the test with "C:\Test" will now work perfectly. But attempting it with "C:\Test 2" will still show the bug.

[admin]

OK, I could repro it when right-dragging from pane 1 to pane 2 and using the shell menu for the extraction. I also could fix it. So let's see who still gets a bug with the next version...

Wow, you're fast! Okay, I tried out Build 415. I've got good news and bad news.

The good news is that you're definitely on the right track - it first appeared as if the bug had been nailed completely.


The bad news (which isn't very bad, as I'm sure it's a really quick fix) is that the bug is still there if the target directory has spaces in its name.

So, attempting the test with "C:\Test" will now work perfectly. But attempting it with "C:\Test 2" will still show the bug.

Uaah, another mystery. Come on, this must be a WinRAR 3.80 bug (I did not try it with this version). First of all, XYplorer does not care about blanks in filenames of course. Nevertheless, I tried it with WinZIP, IZArc, 7-zip, and WinRAR 3.00 -- all perfect. I noted that WinRAR and IZArc cannot handle a hardspace (Alt+0160) in filenames.

[Mesh]

Uaah, another mystery. Come on, this must be a WinRAR 3.80 bug (I did not try it with this version). First of all, XYplorer does not care about blanks in filenames of course. Nevertheless, I tried it with WinZIP, IZArc, 7-zip, and WinRAR 3.00 -- all perfect. I noted that WinRAR and IZArc cannot handle a hardspace (Alt+0160) in filenames.

It's not a bug with WinRAR. First of all, it doesn't make sense, as the files extract perfectly. And second - the exact same issue occurs when using WinZip as well.


*However*, I did further testing, and as it turns out, I was mistaken. It's not directories with spaces that cause problems.

As far as I'm able to see, this bug occurs in *every* directory, EXCEPT directories named "Test".