Re: Changing the name of a file in the temporary items folder
Re: Changing the name of a file in the temporary items folder
- Subject: Re: Changing the name of a file in the temporary items folder
- From: Michelle Steiner <email@hidden>
- Date: Mon, 10 Dec 2007 09:49:33 -0700
On Dec 10, 2007, at 9:37 AM, Skeeve wrote:
It isn't. Of course you can move it to the trash. But then it's
not deleted it's just in the trash.
So? They didn't create it; they didn't even know it existed, so
what is the problem?
They see: "Oops! There is something in my trash I always keep empty
and clean. Where does it come from?"
Oh, I see; they keep a constant eye on the trash icon to see whether
it bulges. Maybe they should be more concerned with whatever they're
doing than in worrying about the state of their trash.
You shouldn't surprise the user.
Even worse: Some users might have moved some things to trash and
by the time they noticed, your code already emptied the trash.
What is bad about that? The purpose of the trash is to be emptied.
There are users out there who don't enpty the trash every day. So
don't think that everyone handles it as you do. After all: The trash
keeps files until the user empties it. So I wouldn't like a program
to empty it without being asked...
It is a trash bin, not a holding bin. They are not using it for its
intended purpose.
And they are just the opposite of the first type of person you
mentioned.
Yes, that is a minor problem, but it certainly is not the mountain
you're trying to make it into.
Hmmm... I didn't. At least I'm not feeling I did. There were posts
telling me that there are workarounds and I just told them why *I
think* those are no true solutions *to me*.
By piling on more artificial constraints to the original constraint,
which appears to most of us to be artificial to begin with.
You have been given a number of alternatives that satisfy your
original complaint (which seems to have artificial constraints at
the outset), but you have chosen to add more and more constraints
as each is addressed.
No. The constraints were given right at the start.
And, as I and others have mentioned, they appear to be artificial.
Perhaps if you explained why those constraints exist, it would help us
understand.
All myother objections were to side effects the workarounds have and
which I don't like.
And to me--and apparently to others--they appear nit picky and
artificial.
I predict that if you continue with this attitude, you will find
fewer and fewer people who will be willing to help you.
To be honest: There is not much help here yet :-(
Oh, there's plenty of help here. The fact that you do not like the
answers does not mean that they aren't valid. I, and at least some of
the other contributers here, agree with you that move and duplicate
should allow renaming on the fly, so that's not the issue. And I
disagree with the person (I'm too lazy to look up who wrote it) that
because the UI of the Finder does not allow deletion of a file without
putting it in the trash, Applescript should not be able to do it
either. I think that it should be added to System Events.
--
I am only one, but still I am one. I cannot do everything, but still I
can do something; and because I cannot do everything, I will not
refuse to do something I can do. --Edward Everett Hale
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden