BUG (or design flaw?) - L 5.0a SR-2: Create new folder in Favorites creates sibling not child
Right click on a folder in Favorites and select Create new folder
It creates a new sibling folder rather than a new child of that folder.
This is utterly useless and unnecessary. There is no way to create a new child folder, so every time, you have to drag the newly created folder one a level to become a child folder. However there would be a perfectly good other way to create a new sibling of this folder if the feature were changed to create child folders. You'd create another child of the parent of this folder.
This is also totally unexpected. Every other "Create new folder" behavior I can think of in other software that has folder hierarchies (e.g., Outlook, Windows Explorer) creates a child in such circumstances, not a sibling. Even software that does allow you to create a sibling (e.g., Treepad) also has an option to create a child, and it creates the sibling right below the selected folder, not at the end of the other siblings in that level the way Logos does.
Logos's way of doing it is wrong wrong wrong. Please fix it in a future version. I don't care how many users have gotten "used to it" this way. It's just wrong.
Comments
-
[Y]
0 -
There's been a case for this since June: BUG and annoyances: Logos' bad memory (first dot under e)). (As you can see I actually reported it in February, but they're not exactly fast in noticing bug reports...)
As you can also read there, the Wiki proves it once worked as it should, at least on Windows.
Mac Pro (late 2013) OS 12.6.2
0 -
fgh said:
There's been a case for this since June: BUG and annoyances: Logos' bad memory (first dot under e)). (As you can see I actually reported it in February, but they're not exactly fast in noticing bug reports...)
As you can also read there, the Wiki proves it once worked as it should, at least on Windows.
I don't recall this ever working correctly on Windows, but I suppose someone must have created those wiki images at some point. It could have been faked, though. [:)]
0 -
Rosie Perera said:
I don't recall this ever working correctly on Windows, but I suppose someone must have created those wiki images at some point. It could have been faked, though.
The wiki shows that a sibling of Folder B is created when clicked on. Point 1 is a little misleading but the arrow clearly points at Folder B and the new folder becomes a child of A as intended.
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:Rosie Perera said:
I don't recall this ever working correctly on Windows, but I suppose someone must have created those wiki images at some point. It could have been faked, though.
The wiki shows that a sibling of Folder B is created when clicked on. Point 1 is a little misleading but the arrow clearly points at Folder B and the new folder becomes a child of A as intended.
Yes, I was a bit confused by the wiki as well, but the arrow pointing to B is merely the markup; it doesn't represent where the mouse was pointing when the right button was clicked. The mouse had to have been pointing to Folder A, because it's the one that is highlighted. So a new folder is created as a child of A, and a sibling of B. However that is not how it presently works in the software.
The wiki seems to be incorrect. If you right-click on A, you get a sibling of A. Either the markup is misleading, pointing to the wrong folder; or the descriptive text is wrong. In any event, since Folder A is highlighted when the menu came up, and a new child of Folder A was created, it does appear that it used to work correctly when that wiki screenshot was captured.
0 -
Rosie Perera said:
since Folder A is highlighted when the menu came up, and a new child of Folder A was created, it does appear that it used to work correctly when that wiki screenshot was captured.
Ok, so I didn't fool you[:$]
Looks like you have a regression.
Dave
===Windows 11 & Android 13
0
