On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella ([Po]lentino) < polentino...@gmail.com> wrote:
> ---------- Messaggio inoltrato ---------- >> From: Yuen Hoe Lim <yuenho...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel