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

[Diego Casella ([Po]lentino)]

>
> ---------- 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 :)

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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100125/89ff12a7/attachment.htm