Tough words about GUI

[lukescammell]

I'm always pro removal.

As you are pro removal, could you please remove the pre-setup message about purchasing a license? At least from the beta versions as betas are largely intended for people who already have a license and, until recently, betas were only available from our License Lounges. I appreciate it's only one extra click, but as someone who is a Lifetime Pro licensee and keeps up-to-date with betas, those clicks are certainly adding up

Thanks for considering!

Fixed --> http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=2886

Then you don't even have to run the installer...

[zer0]

Fixed --> http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=2886

Then you don't even have to run the installer...

It's not a solution, but a workaround. It relies on using a portable version that does not register itself on the system, which is no good for me.

I have decided to go with a scripted workaround that uses a silent switch to keep things quiet. That GUI wish was more for mouse-lovers like myself, but I don't mind rolling up my sleeves and doing some scripting

[lukescammell]

Picky, picky bastard

Care to release your solution in the scripting area of the site? Even if it's not an XYS script it'll be nice to have around

As I use a portable version, (combined with Dropbox it's fantastic) and Jacky's excellent update script to keep myself up-to-date and informed of all the latest changes, would you please explain to me why you need it to register itself on the system every time you update? I would have thought that once it's registered that would be it? I'm just curious.

[zer0]

Picky, picky bastard

Care to release your solution in the scripting area of the site? Even if it's not an XYS script it'll be nice to have around

As I use a portable version, (combined with Dropbox it's fantastic) and Jacky's excellent update script to keep myself up-to-date and informed of all the latest changes, would you please explain to me why you need it to register itself on the system every time you update? I would have thought that once it's registered that would be it? I'm just curious.

Yep, I will of course post it once I find the time to actually put it together -- end-of-quarter dealings are taking up most of my time this week

And as for install vs portable, I use the information that XYplorer inserts into the registry (version, uninstaller location, etc) for software inventories and verifying successful image deployments. I do use a portable version, but only on a USB stick for my laptop.

Anyway, back onto the GUI discussion

[zer0]

I wish Background Jobs dialogue box showed the full path of the initial file location when it is wide enough to provide available space. What's even more inconvenient (read: wrong) is that copying an item (or all) from that dialogue box copies ellipsed path(s), not the full one(s)

bg_jobs.PNG (39.29 KiB) Viewed 2937 times

[admin]

I wish Background Jobs dialogue box showed the full path of the initial file location when it is wide enough to provide available space. What's even more inconvenient (read: wrong) is that copying an item (or all) from that dialogue box copies ellipsed path(s), not the full one(s)

bg_jobs.PNG

It's not possible to make that dependent on the width, at least not on the way that the captions would be auto-shrinked using ellipses when the width of the dialog is changed.

But I could simply skip the whole ellipsing, after all we have a horizontal scrollbar...

[zer0]

A couple of niggles about Mini Tree I have discovered today:

a) in View / Mini Tree, the caption to toggle it is "Mini Tree" -- can we at least have "Enable Mini Tree"? Just "Mini Tree" is meaningless and we already have "Enable Folder View Settings" as a precedent of an appropriate caption.
b) in View / Mini Tree, "Minimize Tree" is not greyed out when Mini Tree is disabled. This does not appear logical as enabling Mini Tree should be a pre-requisite to any further action that is applied to it. As in a), FVS' menu is a good precedent -- we can't do anything with specific views until we enable FVS.

P.S. Sorry to start your weekend on a moaning note

[admin]

A couple of niggles about Mini Tree I have discovered today:

a) in View / Mini Tree, the caption to toggle it is "Mini Tree" -- can we at least have "Enable Mini Tree"? Just "Mini Tree" is meaningless and we already have "Enable Folder View Settings" as a precedent of an appropriate caption.
b) in View / Mini Tree, "Minimize Tree" is not greyed out when Mini Tree is disabled. This does not appear logical as enabling Mini Tree should be a pre-requisite to any further action that is applied to it. As in a), FVS' menu is a good precedent -- we can't do anything with specific views until we enable FVS.

P.S. Sorry to start your weekend on a moaning note

a) I agree that attaching a verb would not harm, but I'm not sure if "enable" is the right one. The Mini Tree is not so much enabled but rather used, applied, activated, employed, chosen, shown, etc... just my feeling... but I'm no english speaker....

b) no, this is practical like this.

[zer0]

a) I agree that attaching a verb would not harm, but I'm not sure if "enable" is the right one. The Mini Tree is not so much enabled but rather used, applied, activated, employed, chosen, shown, etc... just my feeling... but I'm no english speaker....

b) no, this is practical like this.

a) From my understanding of what Mini Tree is, it is a history-based filter that is applied to the tree. While this may make one think that "Apply" is an appropriate verb to use, it isn't as typically it is an action that is applied. "Mini Tree" isn't an action. Thus, "Enable [a feature]" is a more suitable verb.

b) Practicality aside, this menu entry is called "Minimize Tree", so that is what it should do and no more. Cramming additional functionality into it is being too clever. What happened to KISS? "Minimize Tree" is a sub-option of Mini Tree, so it's on a level below enabling Mini Tree. Therefore, a user must either consent to enabling of Mini Tree or enable it themselves. Metaphorically speaking, if you ask me to re-arrange furniture in your house, I'm not going to knock your door off its hinges. I will either ask for a key or ring a bell when I arrive We already have functionality -- UDCs & CTBs -- that enable us to combine multiple actions into one click/KS. Doing so via a menu entry is redundant and inconsistent with how similar features work in XYplorer.

[admin]

Remember that selecting the "Mini Tree" command not just sets the tree in "Mini Tree mode" but also restores the last used Mini Tree. It's a form and a content.

[zer0]

Remember that selecting the "Mini Tree" command not just sets the tree in "Mini Tree mode" but also restores the last used Mini Tree. It's a form and a content.

Granted and that's not a bad thing as the expected outcome of enabling Mini Tree is a display of a Mini Tree. However, "Minimize Tree" not only enables "Mini Tree mode", restores the last used Mini Tree and collapses it to the current node. That's form, content and content's modifier applied in one go through a menu entry titled only to do the last of those three. That's definitely not KISS. Of what advantage is there to have such combo-action menu entry when a user can easily furnish a UDC/CTB that is able to achieve the same?

[admin]

Remember that selecting the "Mini Tree" command not just sets the tree in "Mini Tree mode" but also restores the last used Mini Tree. It's a form and a content.

Granted and that's not a bad thing as the expected outcome of enabling Mini Tree is a display of a Mini Tree. However, "Minimize Tree" not only enables "Mini Tree mode", restores the last used Mini Tree and collapses it to the current node. That's form, content and content's modifier applied in one go through a menu entry titled only to do the last of those three. That's definitely not KISS. Of what advantage is there to have such combo-action menu entry when a user can easily furnish a UDC/CTB that is able to achieve the same?

"Minimize Tree" does what it says -- I don't see a problem in that. I find this discussion a bit on the theoretical side since nobody ever complained. Usage is usage. Interface guidelines should be derived from usage, not vice versa.

[zer0]

"Minimize Tree" does what it says -- I don't see a problem in that. I find this discussion a bit on the theoretical side since nobody ever complained. Usage is usage. Interface guidelines should be derived from usage, not vice versa.

Yes, "Minimize Tree" does what it says...and more. To apply an action to Mini Tree, it should be enabled. Otherwise, there is an algorithmic conflict. Enabling Mini Tree must be a stepping stone to collapsing it to the current node. I suppose it is a matter of principle -- we can't edit folder views without enabling FVS, we can't have CTBs if Scripting is disabled, we can't paste an image into a new PNG file is no image is on clipboard. As far as complaints are concerned, by the same token, I see no-one objecting to exclusion of Mini Tree's enablement in "Minimize Tree"

[admin]

As far as complaints are concerned, by the same token, I see no-one objecting to exclusion of Mini Tree's enablement in "Minimize Tree"

Well, the current way has been reality for some years, so somebody could have objected to it...

[zer0]

As far as complaints are concerned, by the same token, I see no-one objecting to exclusion of Mini Tree's enablement in "Minimize Tree"

Well, the current way has been reality for some years, so somebody could have objected to it...

Just because somebody did not object to it for all this time -- that command has only been there for 1 & 1/2 year -- is not indicative of correct behaviour. I remember unearthing this bug and you said it never ever worked correctly. Further, the changelog is also confusing:

v7.90.0060 - 2009-01-19 14:43
* Menu View | Mini Tree: Replaced the rather useless command
"Convert to Mini Tree" by "Minimize Tree" which will reduce the tree
to show just the current node.

But (note the part in bold)

v7.80.0030 - 2008-11-28 20:41
+ Toolbar | Mini Tree: Added the following commands to the context
menu.
- "Convert to Mini Tree"
Converts the current Maxi Tree to a Mini Tree, but does not
minimize the tree (which is what command/toggle "Mini Tree"
does) but just sets it to "mini mode": From now on only used
paths are added to the tree.

So, during transition from the toolbar to menu system, this command magically inherited Mini Tree enabling powers, while simply enabling Mini Tree collapses the branches anyway Wouldn't it be easier if enabling "Mini Tree" just set it to "mini mode", while "Minimize Tree" just collapse to the current node with the latter only possible if the former is invoked separately?