[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: On Plasmate's recent project list
From: "Diego Casella \(\[Po\]lentino\)" <polentino911 () gmail ! com>
Date: 2010-01-27 20:31:43
Message-ID: e6aee9e1001271231o54612650y721bb12d13d067d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>
> ---------- Messaggio inoltrato ----------
> From: Yuen Hoe Lim <yuenhoe86@gmail.com>
> 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/
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic