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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel