Review Request: an overlay effect element for framesvg
Marco Martin
notmart at gmail.com
Tue Jan 13 18:18:57 CET 2009
On Tuesday 13 January 2009, Marco Martin wrote:
> On Monday 12 January 2009, Aaron J. Seigo wrote:
> > On Monday 12 January 2009, Marco Martin wrote:
> > > if the possible positions are not that much (lets say something like on
> > > the 4 corners) maybe using a single pixmap for caching would still be
> > > possible? or maybe just if the position is consistent across instances
> > > the impact on cache would still be acceptable hmm
> >
> > as long as this is cool with Pinheiro and his artistic vision, a limited
> > # of positions us the best way to go imho. whether that's 4, 6 or 10
> > probably doesn't matter too much.
> >
> > once its in, we can play with tweaking the parameters around.
> >
> > > for the randomness: i would say still indicize in the cache for the
> > > applet name but attach it to random numbers that controls the actual
> > > positioning. the correspondence saved in a config file? like the one
> > > for element rects?
> >
> > another approach is to use a single initially random seed and then just
> > use that always. a random sequence is predictable if you know the first
> > seed ;) or use that and a combination of the applet id and re-seed the
> > generator each time. then we have only two variables max per widget, one
> > of which is shared amongst all the widgets, so really only N+1 variables
> > in total with the N variables already known to us via applet->id(). by
> > reseeding with an initially random number + the id we get a constant set
> > of "random" settings even when widgets are deleted.
>
> hmm, what about simply use applet id as seed and take first 2 sequence
> number for the position?
> would be quite deterministic and prevedible (given an id always the same
> result) but i don't think it would be a problem and could keep things quite
> simple
>
> i'm also experimenting in saving the position on applet config, quite done
> also tthat patch(a bit bigger, changes also in applet.cpp) it would have a
> bit more entropy
and the latter approach is attached :D
(made applet friend of framesvg to avoid a pretty useless new api call)
> Cheers,
> Marco Martin
>
> > the random seed could be generated once and stored in corona->config() in
> > the top-level, in [General], in [Corona] or in [Containments].
> >
> > that means one more int read out of a file we already parse anyways.
> >
> > > (hmm the thing is becoming complex...)
> >
> > hehe.. KISS!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: framesvg-overlay3.diff
Type: text/x-patch
Size: 14497 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090113/7aa440d0/attachment-0001.diff
More information about the Plasma-devel
mailing list