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 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 <jhahoneyk at 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 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
>
> _______________________________________________
> 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/20100126/149e0527/attachment.htm