Re: Subject: Re: Subject: Re: On Plasmate's recent project list
> > Er, there will be a folder name conflict only if there is a project name > conflict, right? Only If I already have a project "abcd" and I import which > already contains "abcd", there will be a conflict. Correct me if i'm wrong. > No, there is no hard link between the two (project and folder names), and they can be different. Plasmate's current state allows you to have two projects with the same name, but folder names obviously must be unique. Allowing duplicate names and hiding folder names has actually spared me a slew of other potentially sticky conflict situations. 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
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
On Tue, Jan 26, 2010 at 6:57 PM, Yuen Hoe Lim wrote:
> What about giving the user a choice when a duplicate is found? As a user, I
>> wouldn't like the software to create two copies of the same project (maybe
>> different versions of it) and then me having to delete one of them. Lets
>> just give a "Overwrite, Rename, Skip" option.
>> What do you guys think ?
>>
>
> My vote is against, for the following reasons:
>
>- True duplicates (the kind we don't want to have) will only occur in
>one of two scenarios.
>a) I export all projects, then import all projects on the same PlasMate
>instance, which is a senseless thing to do. Or I import twice onto the same
>instance, again senseless.
>b) I export my projects and then go to another computer where someone
>else has imported one of my projects (from online, say). This is gonna be
>rare, and isn't really a true duplicate. You may actually want to keep
> both.
>The vast majority of conflicts are likely going to be the kind where
>you unintentionally name two different things with the same name.
>
>- Even in the rare case that true duplicates occur, the remedy is
>trivial. One button-click away.
>
>- Prompting with "Overwrite, Rename, Skip" is bad because, as I have
>repeatedly reiterated, folder names are invisible to the user. ie, when
>there is a folder name conflict - **the user cannot see it**! If the
>user doesn't see a conflict but PlasMate prompts and insists that there is
> a
>conflict, we are definitely going to confuse the user. Furthermore if he
>decides to rename but doesn't see any visible effect from the renaming
>(because folder names are not visible!), he is going to become even more
>confused. And worse - he will probably report it as a bug.
>
> Er, there will be a folder name conflict only if there is a project name
conflict, right? Only If I already have a project "abcd" and I import which
already contains "abcd", there will be a conflict. Correct me if i'm wrong.
>
>
>
> If you guys insist I guess we could use a hash check to ignore "pure" true
> duplicates, so the algorithm reads something like this:
>
>
> for each folder f in import archive {
> for each folder g in the target location {
>if hash(f) == hash(g) { // a "pure" duplicate
> delete f from archive;
> goto end;
>
>}
> }
> while f also exists in the target location {
>generate a new name for f and rename f in the archive;
> }
> end:
>
> }
> extract archive to target location;
>
> But particularly for the third reason above, I really don't like the idea
> of prompting.
>
>
>
> 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
>
>
--
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
>
> What about giving the user a choice when a duplicate is found? As a user, I
> wouldn't like the software to create two copies of the same project (maybe
> different versions of it) and then me having to delete one of them. Lets
> just give a "Overwrite, Rename, Skip" option.
> What do you guys think ?
>
My vote is against, for the following reasons:
- True duplicates (the kind we don't want to have) will only occur in one
of two scenarios.
a) I export all projects, then import all projects on the same PlasMate
instance, which is a senseless thing to do. Or I import twice onto the same
instance, again senseless.
b) I export my projects and then go to another computer where someone
else has imported one of my projects (from online, say). This is gonna be
rare, and isn't really a true duplicate. You may actually want to keep both.
The vast majority of conflicts are likely going to be the kind where you
unintentionally name two different things with the same name.
- Even in the rare case that true duplicates occur, the remedy is
trivial. One button-click away.
- Prompting with "Overwrite, Rename, Skip" is bad because, as I have
repeatedly reiterated, folder names are invisible to the user. ie, when
there is a folder name conflict - **the user cannot see it**! If the user
doesn't see a conflict but PlasMate prompts and insists that there is a
conflict, we are definitely going to confuse the user. Furthermore if he
decides to rename but doesn't see any visible effect from the renaming
(because folder names are not visible!), he is going to become even more
confused. And worse - he will probably report it as a bug.
If you guys insist I guess we could use a hash check to ignore "pure" true
duplicates, so the algorithm reads something like this:
for each folder f in import archive {
for each folder g in the target location {
if hash(f) == hash(g) { // a "pure" duplicate
delete f from archive;
goto end;
}
}
while f also exists in the target location {
generate a new name for f and rename f in the archive;
}
end:
}
extract archive to target location;
But particularly for the third reason above, I really don't like the idea of
prompting.
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
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
On Tue, Jan 26, 2010 at 5:31 PM, Yuen Hoe Lim wrote:
> 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?)
>>
>
> Nonono I don't think we need anything half as complicated as that. Like I
> said, folder names are not visible to the user so we can rename it to
> anything we want. The following simple algorithm should work:
>
> for each folder f in import archive {
> while f also exists in the target location {
>generate a new name for f and rename f in the archive;
> }
> }
> extract archive to target location;
>
What about giving the user a choice when a duplicate is found? As a user, I
wouldn't like the software to create two copies of the same project (maybe
different versions of it) and then me having to delete one of them. Lets
just give a "Overwrite, Rename, Skip" option.
What do you guys think ?
> The user won't know (and doesn't need to know anyway) that any renaming has
> occurred, he will always end up with exactly all his current projects plus
> all the projects in the import archive at the end of the process. If this
> happens to create any duplicates (it shouldn't if he uses it right, but in
> case he doesn't), he could easily delete one of them off. Nice and clean.
>
> I think this is easier and also more elegant and non-intrusive :) I did
> something similar for importing individual projects, so I can implement this
> if you guys don't have objections.
>
>
>
> 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
>
>
--
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
>
> 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?)
>
Nonono I don't think we need anything half as complicated as that. Like I
said, folder names are not visible to the user so we can rename it to
anything we want. The following simple algorithm should work:
for each folder f in import archive {
while f also exists in the target location {
generate a new name for f and rename f in the archive;
}
}
extract archive to target location;
The user won't know (and doesn't need to know anyway) that any renaming has
occurred, he will always end up with exactly all his current projects plus
all the projects in the import archive at the end of the process. If this
happens to create any duplicates (it shouldn't if he uses it right, but in
case he doesn't), he could easily delete one of them off. Nice and clean.
I think this is easier and also more elegant and non-intrusive :) I did
something similar for importing individual projects, so I can implement this
if you guys don't have objections.
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
Subject: Re: Subject: Re: On Plasmate's recent project list
> > -- Messaggio inoltrato -- > From: Yuen Hoe Lim > 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 > > 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
Re: Subject: Re: Subject: Re: On Plasmate's recent project list
On Mon, Jan 25, 2010 at 10:44 PM, Diego Casella ([Po]lentino) < polentino...@gmail.com> wrote: > -- Messaggio inoltrato -- >> From: Yuen Hoe Lim >> 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
Subject: Re: Subject: Re: On Plasmate's recent project list
> > -- Messaggio inoltrato -- > From: Yuen Hoe Lim > 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 :) 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@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
