Review Request: save/restore containments

[Chani]

On January 24, 2010 14:23:55 you wrote:
> On Sunday 24 January 2010, Chani Armitage wrote:
> > > 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
> 
> well, probably the full big ass image would be a bit excessive? maybe
> sething with a 512x512 boundary?

512 should be enough for anybody? ;)
actually that sounds pretty big, I was thinking more like 100.

> 
> > thumbnail be a real thumbnail or just use the wallpaper? also, if we use
> 
> yes, full thumbnail is better, you could have 2 containments with the same
> wallpaper (even if randomizing wallpaper upon creation as we talked sounds
> a good idea)

true.

> 
> for running containments, this will be a problem, it will need to
> periodically (some seconds? one minute?) redo the snapshot, that could be
> heavy, or see if using actual tiny views would work, but probably will end
> up with the same performance problems of the  zui..

hey... if compositing is on could you use that? how would the performance be?

> 
> > 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.
> 
> snapshot/restoresnapshot? can't think about better terminology.. anyways
> what's important is that they use the same verb/action and make sense from
> a developer pov, then it hasn't to be necessarily connected to wat there
> is in the ui :)

true. :) it'll probably be clearer once I have a clearer idea of everything 
the API will do.

> 
> > 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.
> 
> could it justify to move at least part of the code down in Applet?

hmmm. maybe.
it's actually very little code, I just want to make sure that stuff like 
strings are duplicated as little as possible.

> 
> btw, would applet clones have to be "syncronized? i don't think so?

no. you'd have two separate things with their own UIDs but the exact same 
config values.

it's something I wanted to bring up at tokamak...

one approach would be to add a "clone" action to applets (and therefore 
containments) that would just make an instant copy right there beside it.
then if you want a new note you can easily just clone it off an existing one, 
and not have to fiddle with the colour and font settings every damn time (I do 
*not* like the defaults and I use notes a lot).

another approach would be to offer templates... so instead of just creating 
shiny new applets/containments from defaults, you could turn your existing 
applet into a template and then load that as many times as you want. the 
advantage is the template doesn't have to be running (I'd create a generic 
"school activity" template with the widgets and mouse actions I always use for 
courses - that's not something I actually want to have running).
the disadvantage is that you need some UI then to create and load the 
templates. probably in the widget explorer and the activity manager.

another tricky thing about that: while an applet is always just an applet, a 
containment could be either a panel or part of an activity. I only have one 
containment per activity, but someone with 2 screens would have two 
containments per activity, and I'd prefer it if the UI acted on activities, 
not desktopcontainments.
and of course it has to behave gracefully if the number of screens changes...

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100124/3b487a33/attachment-0001.sig