Annoyances and a wishlist

[morkork]

First of all, I really love TC and I have used it for many years now. But since there is a new version comming up I want to add my 2ct:

1. the black connection lines in the tree views are to 'heavy' and disturb overview and readability. Why not use dotted lines like in Explorer or at least grey lines, if dotted are not possible

2. It really was about time for menu icons since this is standard in any newer program and really enhances usability. However, why is there that much padding left and right when configured with IconsInMenus=17 (which is the configuration that is closest to standards)? It just looks strange and different from what's commonly seen.

3. If I set the icon-size in the toolbar to e.g. 22 pixels it still takes the nearest standard resolution icon (24 pixels) and resizes it even if there is a 22 pixel icon in a .ico file and there is no reason to resize. This still makes icons blurry.

4. Since I work with FTP servers a lot it is really very annoying to always confirm a reconnect if a connection is lost. The possibility of an automatic reconnect should be available.

5. On a multi-monitor setup all dialogs should be centered on the screen where TC is or within the TC window, not on the primary or somewhere else. This is very annoying to always find the dialog somewhere else and move the mouse over there. Example: copy dialog is centered within TC, but overwrite confirmation then pops up on primary screen, which in my configuration is 2 monitor widths away...

6. Treeviews should work like everyone expects them to work - like an Explorer tree. It misses common functionality like drag and drop and opening a dir but not selecting it if you click on the + or -.

7. With the introduction of external trees some new configurations got necessary: a) disable directory-brackets [] only in treeview - they help to spot dirs in listviews, but worsen readability in treeviews. b) disable display of directories in listviews if tree is visible - if the tree is implemented in the correct way there should be no need to also display dirs in the listviews.


I know some of my wishes are not easy to implement due to legacy restrictions. But I think usability and a modern interface are very, very important and I'd rather wait for another couple of months until the final release of version 7 than have half-baked elements that annoy me every time I try to use them. TC has always been feature-rich but should also get a state-of-the-art interface following modern guidelines. I love the new icons and some of the new looks but I think there is still a long way to go.

[wanderer]

Hello and welcome to the forum.

1. the black connection lines in the tree views are to 'heavy' and disturb overview and readability. Why not use dotted lines like in Explorer or at least grey lines, if dotted are not possible

I agree. That might be nice.

2. It really was about time for menu icons since this is standard in any newer program and really enhances usability. However, why is there that much padding left and right when configured with IconsInMenus=17 (which is the configuration that is closest to standards)? It just looks strange and different from what's commonly seen.

Indeed it does not look very nice. I too hope it can be altered.

4. Since I work with FTP servers a lot it is really very annoying to always confirm a reconnect if a connection is lost. The possibility of an automatic reconnect should be available.

That has been requested by other users too (in this forum i think). It would also be nice.

6. Treeviews should work like everyone expects them to work - like an Explorer tree. It misses common functionality like drag and drop

Not true. It may not support drag but it supports drop!

and opening a dir but not selecting it if you click on the + or -.

Also requested by other users and i support i too.

7. With the introduction of external trees some new configurations got necessary: a) disable directory-brackets [] only in treeview - they help to spot dirs in listviews, but worsen readability in treeviews.

Nice one. I think it's better that way.

b) disable display of directories in listviews if tree is visible - if the tree is implemented in the correct way there should be no need to also display dirs in the listviews.

As an option perhaps. I think that at least for backwards compatibility, dirs should always be visible in the listviews. Personally i prefer them to be there.

I know some of my wishes are not easy to implement due to legacy restrictions. But I think usability and a modern interface are very, very important and I'd rather wait for another couple of months until the final release of version 7 than have half-baked elements that annoy me every time I try to use them. TC has always been feature-rich but should also get a state-of-the-art interface following modern guidelines. I love the new icons and some of the new looks but I think there is still a long way to go.

Yes the UI is very important and as you can see Christian has finally decided to deal with it seriously. Up until now, he had loaded TC with many terrific options but the UI had been left behind. Not any more. I think all of us hope he can improve it even more.

Have fun.

[astrotzky]

2. It really was about time for menu icons since this is standard in any newer program and really enhances usability. However, why is there that much padding left and right when configured with IconsInMenus=17 (which is the configuration that is closest to standards)? It just looks strange and different from what's commonly seen.

Totally agree. I use IconsInMenu=17 too and the padding in very annoying.
I was going to post about this but search told me you were first

[ghisler(Author)]

hy is there that much padding left and right when configured with IconsInMenus=17

This is because of a bug in WindowBlinds not respecting the requested width. I was looking for a configuration option which looks OK both with and without WindowBlinds.

and opening a dir but not selecting it if you click on the + or -.

I had already partly implemented it for beta 2, but had to remove it because it was causing many problems, e.g. when the user clicked on [-] of a parent of the current directory. How should the tree react then? Refuse the close? Change the current directory?

[wanderer]

I had already partly implemented it for beta 2, but had to remove it because it was causing many problems, e.g. when the user clicked on [-] of a parent of the current directory. How should the tree react then? Refuse the close? Change the current directory?

One would expect it to work like in explorer: close the tree up to the "parent" and then change the selected dir to "parent".

[ghisler(Author)]

OK, I will try that.

[JohnFredC]

That is very good news!

By the way, many tree implementations include a configuration option to toggle "auto-collapse" so that a user can 1) choose to leave all expanded subtrees open (until deliberately collapsed) or 2) expand only the current subtree (automatically collapsing the previous subtree). I prefer the first method.

[JohnFredC]

Sorry for the dual post... something funky going on with my network.

[astrotzky]

hy is there that much padding left and right when configured with IconsInMenus=17

This is because of a bug in WindowBlinds not respecting the requested width. I was looking for a configuration option which looks OK both with and without WindowBlinds.

Why punish the rest of us who do not use WindowBlinds?
If you want to properly support WindowBlinds - or workaround it's bugs - (I personally don't care) you could detect if it's running (e.g. the process xxxxxxx.exe is running) and only then widen the space allocated to the icon.
This is how it looks now and this is how it should look (the last screenshot is taken from a little program made by Lefteous and published here.
The menu is just too wide for me (using IconsInMenus=17) and if this remains as it is I would be forced to remove the icons from the menu (and I wouldn't like that because I really like them).

[djorge]

I tottaly agree with astrotzky. TC should detect or provide a option via the INI file.

The menu with all the padding is ugly.

[ghisler(Author)]

Does anyone know the proper way to detect the presence of WindowBlinds?

Currently I'm looking for its registry key, but this will be present even if the user disabled WindowBlinds...

[astrotzky]

@ghisler: I think the best way is to see if the WindowBlinds executable (whatever its name) it's loaded. IIRC WindowBlinds executable needs to be running to be able to skin Windows.
The detection should not be so difficult as you already did it in the installer (detect if totalcmd.exe is running).

EDIT:
Of course, whatever your detection method is, the menu will look ugly if:
1. the user started TotalCmd while WindowBlinds was running and then he unloaded WindowBlinds
2. the user started TotalCmd and then loaded WindowBlinds.

[djorge]

The detection should not be so difficult as you already did it in the installer (detect if totalcmd.exe is running).

Since registry seems not to work, maybe an option via ini file to set the process name of window blinds. This is better because if WB has its name changed in future, one would have only to change the ini file with correct name.

[ghisler(Author)]

The problem is that the WindowBlinds EXE is just for configuration, not for showing the effects...

[StickyNomad]

2ghisler(Author)

The problem is that the WindowBlinds EXE is just for configuration, not for showing the effects...

Hm, it's just an assumption, but if the main EXE is not responsible for for showing the effects, I think there must be some other Windowblinds-process running in the background to enable skinning...

Just a blind guess of course, a WB-user could perhaps verify it...