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