[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Subject: Re: Subject: Re: On Plasmate's recent project list
From: "Diego Casella \(\[Po\]lentino\)" <polentino911 () gmail ! com>
Date: 2010-01-25 17:14:45
Message-ID: e6aee9e1001250914o2d71191elc51793cc5be3d5f8 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> ---------- Messaggio inoltrato ----------
> From: Yuen Hoe Lim <yuenhoe86@gmail.com>
> To: plasma-devel@kde.org
> Date: Tue, 26 Jan 2010 00:11:17 +0800
> Subject: Re: Subject: Re: On Plasmate's recent project list
>
> 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.
>
And there is even more, in my opinion. When the number of projects becomes
relevant, the user could forget how he/she properly named each of them, thus
it's easy to create a new project with a name already assigned. So a
conflict scenario is more plausible.
( I'm wondering if could be cool to implement a bacukp support over
gitorious, when my backend will be available :)
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.
>
I totally agree. We have to keep in mind that our target are
beginner/intermediate developers, thus we have to ease their development
cycle without forcing them on such drastic choices.
By the way, we should also add a "Remove project" button or whatever
because, in order to test python/ruby/js plasmoid/dataengine/runner, I
created a lot of projects that are no longer needed; so we need a button to
do some "spring-cleaning" IMO :)
> 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/
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
[Attachment #5 (text/html)]
<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;">---------- \
Messaggio inoltrato ----------<br>From: Yuen Hoe Lim <<a \
href="mailto:yuenhoe86@gmail.com">yuenhoe86@gmail.com</a>><br>
To: <a href="mailto:plasma-devel@kde.org">plasma-devel@kde.org</a><br>Date: Tue, 26 \
Jan 2010 00:11:17 +0800<br>Subject: Re: Subject: Re: On Plasmate's recent project \
list<br><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.</div>
</div></blockquote><div><br>And there is even more, in my opinion. When the number of \
projects becomes relevant, the user could forget how he/she properly named each of \
them, thus it's easy to create a new project with a name already assigned. So a \
conflict scenario is more plausible.<br>
( I'm wondering if could be cool to implement a bacukp support over gitorious, \
when my backend will be available :)<br><br></div><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>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.</div>
</div></blockquote><div><br>I totally agree. We have to keep in mind that our target \
are beginner/intermediate developers, thus we have to ease their development cycle \
without forcing them on such drastic choices.<br>By the way, we should also add a \
"Remove project" button or whatever because, in order to test \
python/ruby/js plasmoid/dataengine/runner, I created a lot of projects that are no \
longer needed; so we need a button to do some "spring-cleaning" IMO :)<br>
</div><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>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/" \
target="_blank">http://yuenhoe.co.cc/</a><br><br></div></div> \
<br>_______________________________________________<br> Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br>
_______________________________________________
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