| Project: | Mori |
| Version: | 1.2 |
| Component: | User interface |
| Category: | bug |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
Create an alias to an entry and each has an arrow on its icon. Delete the second entry and the icon for the original entry retains the arrow suggesting that it is an alias.
Updates
Did you empty the trash? Technically, that alias still exists in the trash directory until you empty it, so the icon is valid. Some people have suggested that entries in the trash shouldn't have this behavior; you might see if there's a request about it.
Hmm. That could cause problems, couldn't it? Sure it might be all right for a few days, but what if you re-visit the file a year later. How are you going to remember if an alias is the last existing copy (outside of the trash) or not? Not everyone likes to dump the trash every other second (otherwise why even have it?) Additionally, that is just about as far away from inuitive as it could be. I came here about the same thing, to report a bug in the icon not reverting. While I knew clones go into the trash like everything else, it did not even cross my mind that this would be the problem. When I think of items in the trash, I think of them as being non-functional. This is the way the Finder itself works.
Please make sure to vote on this issue if you think it's important to fix. I do understand the argument here, and it seems valid, but no one has actually voted on this issue, so later when I'm trying to decide what to do for the next version this issue isn't likely to get my attention without more votes.
Understood. Perhaps a solution would be to just not have clones go in the trash. Arguably, the only purpose of a clone is to make an item multi-positional. There is functionally no difference between any of them. So if you delete a clone, you are removing the sole purpose of its exists -- its position in the heirarchy. Buried as this is on page 5,000 or whatever, I doubt it will get any votes, pity that.
OK, emptying the trash removed the alias link. As mentioned above it simply didn't occur to me to check the trash.
As an aside, the trash should really have a warning: "Really empty trash? [cancel] [ok]" or some such.
As an aside, the trash should really have a warning: "Really empty trash? [cancel] [ok]" or some such.
Except that unlike the finder, Mori can undo a trash empty. So if you made a mistake, you can just take it back.
Veering way off topic, I think that the ability to undo the empty-trash command breaks the compact with the user and is at variance with expectation. The usual behaviour would be that items can be put into the trash and removed again at any time until they are permanently deleted by explicitly emptying the trash. Before the empty-trash command is invoked, any items in the trash remain accessible even after a quit and re-launch and across system start-up cycles. Once the command is given to delete trashed items this should happen immediately. Leaving things in an undo buffer creates an unprecedented limbo with uncertainty as to whether or not trashed items have actually gone. Do they survive the closure of the notebook? You and I would know that they don't (just as we know that files deleted from the Finder's trash are actually still there on the HD), but for the average user it is the solidity and consistency of such behaviours which make the UI hallucination convincing.