Review Request: an overlay effect element for framesvg

Aaron J. Seigo aseigo at kde.org
Tue Jan 13 18:37:22 CET 2009


On Tuesday 13 January 2009, Marco Martin wrote:
> 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)

cool; and with this approach and a small number of possible positions, we can 
then tackle:

//FIXME: composing with overlay each time makes it way slower, also caching 
another image isn't sooo good...

huzzah for banging our (your? ;) heads against the wall until we get it 
"right". 

nice work ...

-- 
Aaron J. Seigo, The Wall
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090113/4fb007fc/attachment.sig 


More information about the Plasma-devel mailing list