[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Subject: Re: Subject: Re: On Plasmate's recent project list
From: Shantanu Tushar Jha <jhahoneyk () gmail ! com>
Date: 2010-01-26 5:54:10
Message-ID: ec556b641001252153l7db298a6k76469ef8145bdc78 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella ([Po]lentino) <
polentino911@gmail.com> wrote:
> ---------- 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 :)
>
Oh yes, then we have to have a conflict resolution method anyway.
>
> 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.
>>
>
Ok, then lets design some generic method for this. When someone gets an
outline of a method, mail to the list and we can discuss. :)
>
>> ----
>> 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
>>
>>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
--
Shantanu Tushar (UTC +0530)
http://www.shantanutushar.com
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella \
([Po]lentino) <span dir="ltr"><<a \
href="mailto:polentino911@gmail.com">polentino911@gmail.com</a>></span> \
wrote:<br><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"><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" target="_blank">yuenhoe86@gmail.com</a>><br>
To: <a href="mailto:plasma-devel@kde.org" \
target="_blank">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></div></div></blockquote><div><br>Oh yes, \
then we have to have a conflict resolution method anyway. <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><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> \
</div></div></blockquote></div></blockquote><div><br>Ok, then lets design some \
generic method for this. When someone gets an outline of a method, mail to the list \
and we can discuss. :) <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"><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>
<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" target="_blank">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> <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><br clear="all"><br>-- <br>Shantanu Tushar (UTC \
+0530)<br><a href="http://www.shantanutushar.com">http://www.shantanutushar.com</a><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