[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Major data-destroying usability bugs
|
If people have concrete suggestions for improvements, or have bugs, they
should submit them to bugzilla, or better yet submit a patch. For
conversations, the newsgroup is a better place, and further discussion on
this thread is best moved there. This is the wrong forum for this
discussion and thus won't get you anywhere.
Some comments below, at the risk of continuing the conversation here.
Kevin
========================
>> Just because I don't want a file in my project doesn't mean
>> that I want it deleted from my file system.
Just a note: we need to distinguish in this discussion:
a) files that are considered part of the project but aren't displayed to
the user
b) files that happen to be in the project's directory tree but should be
excluded from the project's builders, etc.
These are very different things (I suspect the former was intended). This
second more complicated one means for example that even though you have a
.java file in the project, it won't get compiled.
>>Perhaps now deleting a file is now considered to be enough of a change to
warrant a backup in local history. I certainly hope so.
It now should, and if it doesn't pls enter a bug report.
>>If you are going to claim compatibility with an operating system you
ought to obey the behavioral conventions of that operating system.
Its the JDK that provides compatibility with the operating system. So by
your argument the JDK should put things in the trash folder on deletion of
java.io.File's.
However, putting things in the trash folder has some merit (we've actually
discussed this before). Feel free to check Core for a similar bug report
and if there is none add an enhancement request.
Note that the strength of local history over the trash can is that you
don't just have the deleted items, you have the modification history of
items, which is way more useful. Putting items in both would be space
innefficient, and in general I would rather have the edit history (eclipse)
than just deletion (windows). Note that there are various configuration
settings for local history that determine how much space it uses and when
that space gets reclaimed, so there is no guarantee that an item will be
there. This is of course also true of Win trash can which also has a fixed
space allocated.
Phil Goodwin
<phil.goodwin@sfba To: eclipse-dev@xxxxxxxxxxx
y.sun.com> cc:
Sent by: Subject: Re: [eclipse-dev] Major data-destroying usability bugs
eclipse-dev-admin@
eclipse.org
16/08/2002 04:24
PM
Please respond to
eclipse-dev
Comments inline. This is an important issue and should not be overlooked.
leon j breedt wrote:
hi,
1) Eclipse has no distinction between "delete from project" and
"delete file
from disk". Just because I don't want a file in my project
doesn't mean
that I want it deleted from my file system. Often, there are
project-related files that are kept in project folders with
code, such as
design documents, that Eclipse does not need to know about. I
certainly
don't want that stuff cluttering up my Package Explorer when
I'm trying to
get work done. In addition, many other dev tools make this
distinction, so
the expectations of many developers will be that these are not
the same
thing.
in the package explorer, if you click the downwards-pointing arrow,
and
select Filters... you can specify name patterns you wish to hide from
view.
if thats too sweeping (it applies across all projects), click the
same
arrow,
and select "Select Working Set..." where you can select the exact
files
you want to see. nothing as drastic as delete required.
Perhaps there should be "Hide File" and "Delete File" options that are
co-located in order to reduce confusion.
2) Eclipse does not make it clear that it will actually be
deleting the
files from the disk when it pops up a panel. You see, when an
app has an
action "do X" and the alert panel says "really do X" then in
the user's
mind, they are confirming that they issued the command. If
there is a
conceptual error about what X really means, then this panel
does not leave
the user any better informed, such that they really *can* be
sure
that X is
what they want to do. This panel should say, "Really destroy
the files on
your hard disk?" and the buttons should be labeled "Destroy
forever" and
"No".
i think its less confusing to to actually delete the file from the
filesystem
than to leave it hanging around. and the file isn't really gone
(although it
isn't in the recycle bin). select the project, right-click, and
select
"Restore from Local History". your deleted files should be there.
this is
documented in the (extensive) online help (search for "deleted",
it'll be
there somewhere).
When this happened to me (quite some time ago) the files were not in local
history. I had just created the project and was trying to un-clutter it.
Since I had never changed any of the files none of them were in local
history. Perhaps now deleting a file is now considered to be enough of a
change to warrant a backup in local history. I certainly hope so.
3) Eclipse puts a window up during deletion, but the cancel
button is not
responsive. What a cruel trick on the user. Once I realized
what it was
doing, I wasted crucial seconds hammering on the cancel button,
when I
should have been killing the app.
see my response to (2).
That response does not address this issue: The cancel button doesn't work
-- it ought to either be fixed or removed. Frantically clicking on an
inoperable control is not a user error (except maybe after the first couple
of clicks).
4) Eclipse does not place the files it is deleting into the
recycle bin,
like a well-behaved application, it just wipes them off your
disk. In
combination with the above usability problems, this is deadly.
There is
simply no excuse for this.
see my response to (2).
There really isn't any reason to erase a file from disk on operation
systems that provide a trash can or similar mechanism. This follows the
principal of least surprise. If you are going to claim compatibility with
an operating system you ought to obey the behavioral conventions of that
operating system. This goes way beyond being a look-and-feel issue -- this
behavior silently circumvents protection mechanisms and permanently
destroys user data. Most development organizations consider that kind of
thing to be among the highest priority bugs.
--
-----------------------------------------------------------------------
Phil Goodwin, Java Software, Sun Microsystems, 408.276.7090, or x17090
For a bowl of water give a goodly meal;
For a kindly greeting bow thou down with zeal;
For a simple penny pay thou back with gold;
If thy life be rescued, life do not withhold.
Thus the words and actions of the wise regard;
Every little service tenfold they reward.
But the truly noble know all men as one,
And return with gladness good for evil done.
