[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: On Plasmate's recent project list
From: Shantanu Tushar Jha <jhahoneyk () gmail ! com>
Date: 2010-02-04 14:28:16
Message-ID: ec556b641002040616x689eff83kee36f0d6b04a3e8a () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
So on a whole I think we will not be forcing project and folder names to
be identical. So, how are we going to implement this? I tried creating a new
project "Hello" and changed it to "Hello1" in the metadata. Now, when I
again tried to create a project "Hello", it overwrites the older "Hello"
(renamed now to Hello1 in metadata, but the directory is still Hello). So, I
think when the new project with the same name is created, we should create
another directory (say,Hello-2 which is not visible to the user). Correct me
if I got it wrong :)
Btw, nice to see Plasmate gaining shape, nice work guys !! Though I couldn't
help much not knowing any scripting languages correctly. Still, it feels
nice :)
Cheers,
On Thu, Jan 28, 2010 at 2:01 AM, Diego Casella ([Po]lentino) <
polentino911@gmail.com> wrote:
> ---------- 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/
>>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
--
Shantanu Tushar (UTC +0530)
http://www.shantanutushar.com
[Attachment #5 (text/html)]
Hi,<br> So on a whole I think we will not be forcing project and folder names to \
be identical. So, how are we going to implement this? I tried creating a new project \
"Hello" and changed it to "Hello1" in the metadata. Now, when I \
again tried to create a project "Hello", it overwrites the older \
"Hello" (renamed now to Hello1 in metadata, but the directory is still \
Hello). So, I think when the new project with the same name is created, we should \
create another directory (say,Hello-2 which is not visible to the user). Correct me \
if I got it wrong :)<br> <br>Btw, nice to see Plasmate gaining shape, nice work guys \
!! Though I couldn't help much not knowing any scripting languages correctly. \
Still, it feels nice :)<br><br>Cheers,<br><br><div class="gmail_quote">On Thu, Jan \
28, 2010 at 2:01 AM, Diego Casella ([Po]lentino) <span dir="ltr"><<a \
href="mailto:polentino911@gmail.com">polentino911@gmail.com</a>></span> wrote:<br> \
<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"><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" target="_blank">yuenhoe86@gmail.com</a>><br>
To: <a href="mailto:plasma-devel@kde.org" \
target="_blank">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> \
<br>_______________________________________________<br> Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br><br clear="all"><br>-- <br>Shantanu Tushar (UTC \
+0530)<br><a href="http://www.shantanutushar.com">http://www.shantanutushar.com</a><br>
_______________________________________________
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