[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Subject: Re: On Plasmate's recent project list
From: Yuen Hoe Lim <yuenhoe86 () gmail ! com>
Date: 2010-01-25 16:11:17
Message-ID: 26362f481001250811s697055edq6b9d62d12249162c () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> IMO, the import/export tarball feature will be used only for backup and
> restore purposes. In that case, forcing an overwrite *will* make sense, and
> that is what I originally meant. We aren't aiming for a per-project export
> feature. Think of it as 'Backup All Projects' and 'Restore All Projects'. I
> hope I'm able to explain what I originally meant.
>
> I understood what you originally meant, but why restrict it so? I don't
personally think it's great to force overwrite and I don't think a conflict
scenario is all too unlikely - 'Backup All Projects' means I'm saving all
current my work and bringing it with me. There is no guarantee that I won't
create some projects and import a couple more in my new location before I
decide to bring in my old work. You can say that the 'correct' way to backup
all and restore all is to do the restore first thing, but users will do what
they want - and then complain when they have a problem. And no matter how
rare a conflict scenario is, forcing overwrite is serious business. We're
talking about forcing the user to choose between losing whole existing
projects, and not being able to import groups of projects. Either choice
could mean losing contact with a lot of the user's previous work. Also not
forgetting that folder names are not exposed to the user, so folder name
conflicts are not visible to the user, and he will probably be quite
bewildered if we suddenly pop up and say "hey you have a conflict!" when he
sees none.
IMO we should avoid force-overwrite if we can at all, and if Diego is right
(he probably is :P ) then it's pretty trivial to just get PlasMate to do
some under-the-hood renaming and circumvent all the possible problems.
----
Jason "moofang" Lim Yuen Hoe
http://yuenhoe.co.cc/
[Attachment #5 (text/html)]
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div \
class="gmail_quote"><div>IMO, the import/export tarball feature will be used only for \
backup and restore purposes. In that case, forcing an overwrite *will* make sense, \
and that is what I originally meant. We aren't aiming for a per-project export \
feature. Think of it as 'Backup All Projects' and 'Restore All \
Projects'. I hope I'm able to explain what I originally meant.<br> \
<br></div></div></blockquote><div>I understood what you originally meant, but why \
restrict it so? I don't personally think it's great to force overwrite and I \
don't think a conflict scenario is all too unlikely - 'Backup All \
Projects' means I'm saving all current my work and bringing it with me. There \
is no guarantee that I won't create some projects and import a couple more in my \
new location before I decide to bring in my old work. You can say that the \
'correct' way to backup all and restore all is to do the restore first thing, \
but users will do what they want - and then complain when they have a problem. And no \
matter how rare a conflict scenario is, forcing overwrite is serious business. \
We're talking about forcing the user to choose between losing whole existing \
projects, and not being able to import groups of projects. Either choice could mean \
losing contact with a lot of the user's previous work. Also not forgetting that \
folder names are not exposed to the user, so folder name conflicts are not visible to \
the user, and he will probably be quite bewildered if we suddenly pop up and say \
"hey you have a conflict!" when he sees none.<br> <br>IMO we should avoid \
force-overwrite if we can at all, and if Diego is right (he probably is :P ) then \
it's pretty trivial to just get PlasMate to do some under-the-hood renaming and \
circumvent all the possible problems.<br> <br clear="all">----<br>Jason \
"moofang" Lim Yuen Hoe<br><a \
href="http://yuenhoe.co.cc/">http://yuenhoe.co.cc/</a><br><br></div></div>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic