<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: Wed, 27 Jan 2010 12:45:58 +0800<br>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>Correct, the project <---> folder naming convention is suggested, not required ( even though I wouldn't break that :P ).<br>
</div></div></blockquote><div><br>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<br>
<ul><li>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).</li>
<li>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..)</li>
<li>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.</li>
</ul>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? :)<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>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 ?<br>
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.<br>
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 ?<br>
</div></div></blockquote><div><br>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.</div>
</div></blockquote><div><br>+1 for me :) <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> 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).<br>
<br>Any other ideas? :)<br><br clear="all"></div></div></blockquote><div>Yours is good and, since its not a vital component in our app, we could change its behaviour later, referring on users feedbacks :)<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>----<br>Jason "moofang" Lim Yuen Hoe<br><a href="http://yuenhoe.co.cc/" target="_blank">http://yuenhoe.co.cc/</a><br></div></div></blockquote></div>