--===============1464918728== Content-Type: multipart/alternative; boundary=001636498ccd927828047e2b4bab --001636498ccd927828047e2b4bab Content-Type: text/plain; charset=ISO-8859-1 > > ---------- Messaggio inoltrato ---------- > From: Yuen Hoe Lim > To: plasma-devel@kde.org > Date: Wed, 27 Jan 2010 12:45:58 +0800 > Subject: Re: On Plasmate's recent project list > > Correct, the project <---> folder naming convention is suggested, not >> required ( even though I wouldn't break that :P ). >> > > Hmm, okay so this brings up the greater question of whether we want to > force project and folder names to be identical (They don't have to be > technically, but we can force it programmatically). I'm personally not keen, > (I have in fact already broken that rule in the implementation) and here > again are my list of reasons :P > > - Forcing the names to be the same has the benefit of neatness, but I > don't think this is always desireable since we are allowing users to import > existing plasmoids as well as download them from GHNS (eventually), and the > user really has no control over the names of these external projects. It'd > be pretty troublesome, at least if it was me, if I was blocked from > importing just because I have a project locally with the same name (note > that if we force project and folder names to be identical, name conflicts > will occur even if I have a plasmoid and a runner, for example, with the > same name, and those are clearly different). > - I think importing existing plasmoids and stuff will be a fairly > common use-case, and the project name == folder name rule is not widely > enforced in existing plasmoids (my own plasmoid doesn't keep this rule..) > - For the above reasons I'm not convinced that there is a significant > advantage of forcing project and folder names to be identical, and yet > forcing them to be identical will make a lot of other sticky > conflict-resolution dialogs necessary, not just in this 'import-all' > feature. Examples: the regular project import, import from GHNS or even the > desktop if we implement that, and when the user changes the project name in > the metadata editor. > > In short, I think forcing the names to be identical will create a lot of > extra work without really adding any significant benefit. It still can be > done though if you guys really think it's better. What do you guys think? :) > > So,if we bump into a conflict situation, we rename one of the two folder, >> good. Now, my question is: how the user will be able to distinguish the >> "current" and "backup" version of his/her project ? >> I mean, in the project list we can't show the directories name because >> they must be hidden, so an appropriate way is to pick up the project name >> from the "Name" field metadata.desktop file, and surprisingly this will be >> 99% times the same, since previously there was a conflict, so most likely >> the user will fill a bug report because he/she can't distingiush between the >> two projects, and he/she is forced to look to the sources in order to find >> the correct one. >> So, what about showing the "Remove,overwrite,ignore" buttons, or adding >> more informations in the project list (for example adding the date of last >> modification could be enough to distinguish between and old backup and the >> current project, at least when there are few projects). Any other ideas ? >> > > I maintain that the former only makes sense if we force project names to be > == folder names (in which case we'd need to add that kind of options/dialogs > all over the place). If we keep the current status though (project names != > folder names), then I agree that we need distinguishers in the list. I was > thinking adding the author name and version, because it should be relatively > uncommon for the same guy to create two projects with the same name, so > showing author should eliminate the larger class of duplicate names that > result from external imports. > +1 for me :) For people who actually want to maintain two projects of the same name and > both by me, version number I think is a sensible way for me to distinguish > between the two (so instead of doing the somewhat uncool thing of having to > name my projects coolplasmoid_1 and coolplasmoid_2, I could have > coolplasmoid v1 and coolplasmoid v2. Nicer IMO). Slipups that create same > plasmoid name and same author and same version can STILL occur, but that > would hopefully be rare, and again the fix is trivial - the user just needs > to load either one and check his code, then flip to the metadata editor and > key in an appropriate version number (or change the name if that's what he > prefers). > > Any other ideas? :) > > Yours is good and, since its not a vital component in our app, we could change its behaviour later, referring on users feedbacks :) > ---- > Jason "moofang" Lim Yuen Hoe > http://yuenhoe.co.cc/ > --001636498ccd927828047e2b4bab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Messaggio inoltrato ----------
From:=A0Yuen Hoe Lim= <yuenhoe86@gmail.com>
To:=A0plasma-devel@kde.org
D= ate:=A0Wed, 27 Jan 2010 12:45:58 +0800
Subject:=A0Re: On Plasmate's = recent project list

Correct, the project <---> folder nam= ing convention is suggested, not required ( even though I wouldn't brea= k that :P ).

Hmm, okay so this brings up the greater q= uestion of whether we want to force project and folder names to be identica= l (They don't have to be technically, but we can force it programmatica= lly). I'm personally not keen, (I have in fact already broken that rule= in the implementation) and here again are my list of reasons :P
  • Forcing the names to be the same has the benefit of neatness, but I= don't think this is always desireable since we are allowing users to i= mport existing plasmoids as well as download them from GHNS (eventually), a= nd the user really has no control over the names of these external projects= . It'd be pretty troublesome, at least if it was me, if I was blocked f= rom importing just because I have a project locally with the same name (not= e that if we force project and folder names to be identical, name conflicts= will occur even if I have a plasmoid and a runner, for example, with the s= ame name, and those are clearly different).
  • I think importing existing plasmoids and stuff will be a fairly common = use-case, and the project name =3D=3D folder name rule is not widely enforc= ed in existing plasmoids (my own plasmoid doesn't keep this rule..)
  • For the above reasons I'm not convinced that there is a significant= advantage of forcing project and folder names to be identical, and yet for= cing them to be identical will make a lot of other sticky conflict-resoluti= on dialogs necessary, not just in this 'import-all' feature. Exampl= es: the regular project import, import from GHNS or even the desktop if we = implement that, and when the user changes the project name in the metadata = editor.
In short, I think forcing the names to be identical will create a lot = of extra work without really adding any significant benefit. It still can b= e done though if you guys really think it's better. What do you guys th= ink? :)

So,if we bump into a conflict situation, we rename= one of the two folder, good. Now, my question is: how the user will be abl= e to distinguish the "current" and "backup" version of = his/her project ?
I mean, in the project list we can't show the directories name because = they must be hidden, so an appropriate way is to pick up the project name f= rom the "Name" field metadata.desktop file, and surprisingly this= will be 99% times the same, since previously there was a conflict, so most= likely the user will fill a bug report because he/she can't distingius= h between the two projects, and he/she is forced to look to the sources in = order to find the correct one.
So, what about showing the "Remove,overwrite,ignore" buttons, or = adding more informations in the project list (for example adding the date o= f last modification could be enough to distinguish between and old backup a= nd the current project, at least when there are few projects). Any other id= eas ?

I maintain that the former only makes sen= se if we force project names to be =3D=3D folder names (in which case we= 9;d need to add that kind of options/dialogs all over the place). If we kee= p the current status though (project names !=3D folder names), then I agree= that we need distinguishers in the list. I was thinking adding the author = name and version, because it should be relatively uncommon for the same guy= to create two projects with the same name, so showing author should elimin= ate the larger class of duplicate names that result from external imports.<= /div>

+1 for me :)

For = people who actually want to maintain two projects of the same name and both= by me, version number I think is a sensible way for me to distinguish betw= een the two (so instead of doing the somewhat uncool thing of having to nam= e my projects coolplasmoid_1 and coolplasmoid_2, I could have coolplasmoid = v1 and coolplasmoid v2. Nicer IMO). Slipups that create same plasmoid name = and same author and same version can STILL occur, but that would hopefully = be rare, and again the fix is trivial - the user just needs to load either = one and check his code, then flip to the metadata editor and key in an appr= opriate version number (or change the name if that's what he prefers).<= br>
Any other ideas? :)

= Yours is good and, since its not a vital component in our app, we could cha= nge its behaviour later, referring on users feedbacks :)
=A0
----
Jason "moofang" Lim Yuen = Hoe
http://yuenhoe.c= o.cc/
--001636498ccd927828047e2b4bab-- --===============1464918728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============1464918728==--