On Plasmate's recent project list

Yuen Hoe Lim yuenhoe86 at gmail.com
Wed Jan 27 05:45:58 CET 2010


> 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. 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? :)

----
Jason "moofang" Lim Yuen Hoe
http://yuenhoe.co.cc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100127/b3d031b0/attachment.htm 


More information about the Plasma-devel mailing list