> > ---------- Messaggio inoltrato ---------- > From: Yuen Hoe Lim <yuenho...@gmail.com> > To: plasma-devel@kde.org > Date: Tue, 26 Jan 2010 13:16:50 +0800 > Subject: Re: Subject: Re: On Plasmate's recent project list > >> 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 :) >> > > Yeah I was planning to add that, that's why I was asking if all we needed > to do to kill a project + git repo is to delete the whole folder :) You > probably already know this, but in the meantime you could just kill all the > stuff in ~/.kde4/share/apps/plasmate/ and kill the config files in > ~/.kde4/share/config/plasmate* to start with a clean slate again :) > > Yep, that's why I need something more easy to accomplish that :)
> ---- > Jason "moofang" Lim Yuen Hoe > http://yuenhoe.co.cc/ > > From: Shantanu Tushar Jha <jhahon...@gmail.com> > > 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. > Of course we have :) The coolness I was talking is about having version controlled backup system over gitorious, so you can access it from every pc with an internet connection, without worrying about in what folder/pendrive/external drive you put it before formatting the pc. One click, and you backup all your projects online; an other click ( + cool anti-conflict method ), and you'll get them back :) > >> 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. :) > What about performing a sort of sha1sum for each project file, and use it to perform a check when restoring a backup ? So, if we find two identical packages names with different hashes, we could prompt a dialog with the name of the package with an "overwrite" checkbox and a "details" button to give more infos about the projects. ( That's reptty rough I know, so what about your opinion?) Well, I'm going to take my DC examinations, bye >.< > >>> ---- >>> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
