On Plasmate's recent project list
Yuen Hoe Lim
yuenhoe86 at gmail.com
Sat Jan 23 17:40:33 CET 2010
Ok cool :) I'll start working on the mentioned changes then.
perhaps instead of "other projects" maybe "older projects", "older projects"
> or maybe even just "More projects..."? "other" sounds a bit like they
> belong
> to a different category.
>
Now that you mentioned it 'More Projects' sounds like a much better choice
(It's probably not 'older projects' since we're listing everything). Think
I'll just adopt 'More Projects' :)
But, there should be an option by which the user
> can 'save' all his/her projects to a file (an archive, maybe) so that
> it can be used after a system reinstall,
>
Agree, but I'll think about that a little later - I suspect it's not so
simple as it is not just a matter of files but also save points (ie the Git
local repositories) that need to be cleanly migrated. I've no idea how to do
that at the moment. I'm not even sure at the moment how to kill a project's
git repository when it is being deleted. Need to look into that in some time
(or insidiously arrow Diego to handle it :P ).
----
Jason "moofang" Lim Yuen Hoe
http://yuenhoe.co.cc/
On Sat, Jan 23, 2010 at 2:42 PM, Shantanu Tushar Jha <jhahoneyk at gmail.com>wrote:
> On Sat, Jan 23, 2010 at 11:57 AM, Yuen Hoe Lim <yuenhoe86 at gmail.com>
> wrote:
> > Hi guys,
> >
> > Would like some of your opinion on this :) There is a comment like this
> in
> > Plasmate's code regarding the 'recent projects list' on the start page:
> >
> > // Q: TODO Limit to 5?
> > // A: Before limiting, we need to provide an "Export" feature so
> > // the developer can save his projects and import it later for
> > review.
> >
> > I think there are problems with this:
> >
> > What happens if a user forgets to export? It doesn't make sense that you
> > never need to worry about saving files in plasmate but yet need to worry
> > about exporting your project every now and then or risk losing it forever
> > and ever (unless you dug into the folds of Plasmate's hidden folders,
> which
> > is ugly).
> > Even if you remember to export, Plasmate still maintains a (version
> > controlled!) copy of the project in it's own hidden folders. Then what
> > happens if you reimport the exported project? How does Plasmate know that
> > the project being imported is the same project as the one it maintains in
> > the hidden folder - especially since the exported project may have been
> > modified before being imported again? Name checking doesn't sound like a
> > sensible thing since you could very well be importing an external
> plasmoid
> > (via GHNS for eg when that starts working) that happens to have the same
> > name as a local project but is entirely different. If you always imported
> as
> > a new project, then you'll be creating tonnes of obsolete 'garbage
> projects'
> > in the hidden folder that never gets referenced again.
> >
> > What I suggest is we make it so that the export feature is only for
> creating
> > an installable that the user can distribute - he should not need to
> > re-import what was exported. Instead, Plasmate will be responsible for
> > managing all 'in-development' projects. What we could have is for there
> to
> > be ~5 recent projects that the user can quick-select from the start page,
> > and then we could have an 'other projects' button at the bottom that
> brings
> > up a project selection dialog, which should list all projects that have
> ever
> > been created in Plasmate (probably with quick-filter/search
> > functionalities). The user will be able to load any of his projects from
> > this dialog, and will also be able to delete off old projects he doesn't
> > need anymore.
>
> Yes, that is good. But, there should be an option by which the user
> can 'save' all his/her projects to a file (an archive, maybe) so that
> it can be used after a system reinstall, or say for backup purposes. I
> suggest-
>
> 1. User clicks on "Backup", chooses a location to save the archive.
> 2. Plasmate tars/zips the config dir (the plasmate dir in .kde) to the
> location.
> 3. Later, the user wants to "Restore", chooses an archive for the task.
> 4. Plasmate untars/unzips the archive, and if successful overwrites
> (after a warning/confirmation) the config with those from the archive.
>
> All this because not everyone is going to publish on an online repo.
> Or, is there some other way to accomplish this?
>
> >
> > This way we never need to worry about projects bouncing in and out of
> > Plasmate - all projects are always "in" Plasmate. At the same time the
> user
> > never needs to worry about exporting unless he wants an installable,
> never
> > needs to manage his Plasmate project files (since there are none), and
> > doesn't even need to care about how a project looks like or how Plasmate
> is
> > storing his projects - just that it does. It'll also allow the user to
> > explicitly decide if any project is no longer needed and allow us to
> delete
> > off stuff in the hidden folder to save space.
> >
> > What do you guys think, does this sound like a sensible solution?
> >
> > ----
> > Jason "moofang" Lim Yuen Hoe
> > http://yuenhoe.co.cc/
> >
> >
> > _______________________________________________
> > Plasma-devel mailing list
> > Plasma-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/plasma-devel
> >
> >
>
>
>
> --
> Shantanu Tushar (UTC +0530)
> http://www.shantanutushar.com
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100124/c175afec/attachment.htm
More information about the Plasma-devel
mailing list