[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Review Request: save/restore containments
From:       "Aaron Seigo" <aseigo () kde ! org>
Date:       2010-01-27 16:45:53
Message-ID: 20100127164553.16879.42589 () localhost
[Download RAW message or body]



> 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?
> 
> Chani Armitage wrote:
> 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.

save/restore is for runtime saving/restoring. this is more import/export, i think. \
open/close doesn't say too much about storage imo.

'"export" sounds too much like something that takes effort and isn't done regularly'

remember that this isn't what the user will see, but what the API tells the developer \
it will do.


- Aaron


-----------------------------------------------------------
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
> 
> 

_______________________________________________
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]