Subject: Re: Subject: Re: On Plasmate's recent project list

[Shantanu Tushar Jha]

On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella ([Po]lentino) <
polentino911 at gmail.com> wrote:

> ---------- Messaggio inoltrato ----------
>> From: Yuen Hoe Lim <yuenhoe86 at gmail.com>
>> To: plasma-devel at 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 at kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>


-- 
Shantanu Tushar    (UTC +0530)
http://www.shantanutushar.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100126/49ef4075/attachment-0001.htm