Review Request: save/restore containments

[Chani Armitage]

> On 2010-01-24 15:13:41, Marco Martin wrote:
> > the code for me is ok, and yes, i think an optional parameter with the filename in close would make a nice simmetry (depending on the ui maybe we could want also some way to "export! it?)
> >
> 
> Marco Martin wrote:
>     for thumbnails, yes, a must have, and yes in the same folder.
>     i thnk even if ugly the nly way to save them would be create a dummy qgraohicsview on it and make it render on a pixmap...

doesn't sound ugly to me :)
the harder questions are: what size should the thumbnail be? should the thumbnail be a real thumbnail or just use the wallpaper?
also, if we use thumbnails of the currently-running activities in the activity manager UI, how do we nicely handle keeping them up-to-date with changes (especially animated wallpapers)?


> On 2010-01-24 15:13:41, Marco Martin wrote:
> > /trunk/KDE/kdelibs/plasma/corona.h, line 245
> > <http://reviewboard.kde.org/r/2713/diff/1/?file=17641#file17641line245>
> >
> >     listSavedContainments()?
> >     otherwise would make the impression that would list also the deleted ones
> 
> Marco Martin wrote:
>     thinking about it don't like curent method names that much, they seem unrelated. what about
>     importContainment(qstring)
>     exportContainment(qstring)
>     listExportedContainments()?
>     
>     the catch would be that export does export -and- close...
>     could be worth for clarity don't make it actually close the containment?

yeah, I need to pick a metaphor and stick with it. open/close, save/restore, import/export..?
right now I'm leaning towards open/close with remove defaulting to true. I think that normally, activities will be more like objects, unique, not something you copy on a whim, but easily turned off for a while. "export" sounds too much like something that takes effort and isn't done regularly, like exporting your email archive.
99% of the time, the user should just be closing or opening one of their regular activities and not caring about the details. only 1% of the time are they likely to want to open an activity from elsewhere (say, one from their other computer or that someone else sent them), or save one to something they can send out.

However, there is a disadvantage to plasma's tendency to make things like the real world... being able to copy things and make them appear in >1 place can be useful at times. I'd like it to be possible to clone applets and/or containments at some point, and it'd probably end up sharing code with this. hmm.


- Chani


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2713/#review3830
-----------------------------------------------------------


On 2010-01-24 07:29:31, Chani Armitage wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2713/
> -----------------------------------------------------------
> 
> (Updated 2010-01-24 07:29:31)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> as expected, the libplasma side of closing & opening containments is pretty simple.
> getting hte right API and UI will be harder.
> there's no UI in this patch; I have a really ugly UI locally that basically just adds buttons to the activity bar to call these functions. I'm reluctant to commit bad UI; I'd rather someone take the API and make something pretty with it.
> 
> the API, though... hrm. well, tbh I'll probably need to redo it at tokamak to make it activity-centric instead of containment-centric. maybe have functions like openActivity and closeActivity?
> 
> maybe I should make Containment::close() take an optional filename... not something I personally would use, but the loading API leaves open hte option to pass it an arbitrary filename instead of one from the area containments are saved to.
> 
> I'd also like to add thumbnails to the saved containments in the future. I guess I could store them in the same folder under a related filename..? right now the containments are saved to $appdata/activities/$activityname but at some point nepomuk will give us UIDs to use instead (and then we'll need to extract the associated name to display in the UI, and deal with multi-monitor systems having >1 containment, and so on..)
> ok, I'm rambling now. I just don't want this code hiding on my laptop until tokamak :)
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/plasma/containment.h 1077904 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.h 1077904 
>   /trunk/KDE/kdelibs/plasma/corona.cpp 1077904 
> 
> Diff: http://reviewboard.kde.org/r/2713/diff
> 
> 
> Testing
> -------
> 
> works surprisingly well, haven't been able to cause anything bad to happen
> 
> 
> Thanks,
> 
> Chani
> 
>